Common CMS Issues: Finding the Fault Before You Start Fixing Things

Content management systems (CMS) problems are rarely kind enough to explain themselves. A page keeps showing the old version. Someone logs in and gets thrown straight back out. An image appears to upload, then disappears. Sometimes all you get is a 500 error and not much else.

Those are clues, but they are not diagnoses.

The first check does not need to be complicated. Which page was affected? What did the user actually see? Did anything change on the site recently, or has it been sitting untouched for weeks?

A few basic answers can remove a surprising number of possibilities before you start disabling plugins or changing server settings.

1. Get the error before changing anything

If there is an error message, copy it exactly and note roughly when it happened.

The time is useful because the site may be working normally again by the time you reach the logs. A 403 and a 500 can both be reported as “the website is broken,” but once you start investigating them, they lead in very different directions.

For application errors, check the CMS log as well as the relevant server logs from the same period. Depending on the stack, the useful message may be coming from PHP, the web server, or the CMS itself.

It is also worth checking what happened shortly before the first failure. Was there a deployment, update, restart, configuration change, or migration? If nothing changed, that is useful information too.

Before doing anything that might alter stored data, make sure there is a way back. Database repair is an obvious example, but plugin removal and configuration changes can create problems of their own.

Something harmless, such as opening an uncached version of a page, does not need the same level of preparation.

2. The editor shows the change, but the public page does not

If the new text is visible in the editor while visitors still see yesterday’s version, caching is one of the first places I would look. The stale copy might be coming from the CMS itself, but it could just as easily be sitting in a reverse proxy, CDN, or browser cache.

Avoid clearing every cache at once. Instead, try bypassing one layer and reload the page. If the updated version appears, you now know something about where the stale response was being served from.

A full cache purge may make the problem disappear, but it can also remove the evidence that would have told you what caused it. If the edit itself is missing from the CMS, caching is no longer the main question. At that point, check revision history, drafts, permissions, and database errors.

On a multi-node setup, there is another possibility: every node may not be reading from the same data source.

Pro Tip: Many CMS platforms offer the ability to set autosave functionality. Enable this feature to prevent losing edits in case of accidental page closure. You can reach out to “5 Best CMS Software in 2025” to better understand what best cms software provide to their clients.

3. Problems after a plugin or extension change

When a failure starts immediately after a plugin update, that plugin is an obvious place to investigate. It is still only a suspect.

Disabling every plugin on a production site may get the site working again, but it also makes the result much harder to interpret. You can easily introduce new problems that had nothing to do with the original complaint.

This is where staging becomes useful.

Reproduce the issue there, disable or roll back the component that actually changed, and see whether the behavior changes.

If the plugin handles security, caching, authentication, or another important part of the stack, simply getting the page to load after disabling it does not necessarily mean the investigation is finished.

Pro Tip:

• Make sure to create a backup before making any major changes to your website. This simplifies restoring a previous working state if a plugin malfunctions.
• Avoid installing too many plugins at once. Start with a minimal set of plugins you need and gradually add more as required, checking for conflicts after each addition.

4. When media uploads fail

First check whether the original file actually reached storage.

An upload can succeed and still fail afterward while the CMS is generating thumbnails, resizing images, or creating alternate formats. Large image files tend to expose this kind of failure more often.

If the file never appears in storage, check the upload size limit, available disk space, and the directory the CMS is trying to write to.

If the file exists but its URL returns a 403 or 404, that is a different problem. Follow the generated URL back to the location where the file is supposed to live.

When a CDN or object-storage service is involved, there is another layer where paths, permissions, or mappings can go wrong.

Pro Tip: Optimize your images before uploading them to your CMS. This will improve website loading speed and user experience.

5. When the database connection is the problem

Before assuming that the database server itself is down, check the connection details the CMS is actually using.

Old hostnames have a habit of surviving migrations. Wrong ports, database names, usernames, or credentials are easy to miss as well.

Be careful with credentials while troubleshooting. They should not end up in screenshots, tickets, or shared support notes.

Also remember that a database accepting connections does not necessarily mean it is healthy.

It may still be close to its connection limit, overloaded with queries, or spending most of its time waiting on storage.

What the database was doing during the incident matters more than a green status indicator five minutes later.

Migrations can introduce network problems too. DNS, private routing, firewall rules, and TLS requirements may all be different on the new host, even when the application files themselves look perfectly normal.

Configuration pointing to an old database endpoint can survive the move as well.

6. Users keep getting sent back to the login page

A login loop does not always mean the password was rejected.

Sometimes authentication succeeds, but the session that should be created afterward does not survive.

That makes cookies, HTTPS configuration, reverse-proxy headers, caching, and session storage worth checking.

Trying a clean browser session early is useful because it quickly removes some client-side causes from the investigation.

After that, the application logs should help show whether authentication actually succeeded or whether the request failed earlier in the process.

7. An update stopped halfway through

A failed CMS update is not always dramatic.

The disk may have filled up. A directory may no longer be writable. The new version may require a runtime version the server does not have. A plugin or theme may also be interfering with the update process.

The useful information is usually in whatever error the failed attempt left behind.

Read it before clicking Update again.

For major changes on a production site, there should also be a known way to roll back. A staging environment helps here not because it guarantees that the update will work, but because it gives you somewhere cheaper to discover that it will not.

8. When the site is slow

A slow page does not automatically mean the server needs more CPU.

The delay could be coming from MySQL, a plugin, an external API, a PHP worker queue, or something else entirely.

Cached pages may continue loading quickly while one uncached route becomes painfully slow.

It is also useful to separate server response time from what happens in the browser.

The server may answer quickly while the page still takes several seconds to finish loading because of large images, JavaScript, fonts, advertising scripts, analytics, or other third-party resources.

Treat those as separate problems until the evidence says otherwise.

When looking at server performance, check the graphs from the period when the slowdown actually happened.

If CPU, memory, disk I/O, and worker capacity all had plenty of headroom, adding more of the same resources is not a particularly convincing first solution.

9. Permission and ownership problems

CMS installations need write access in some places, but usually not everywhere.

Uploads, caches, temporary files, and updates may require writable directories. Giving too little access breaks those functions. Giving far too much access may hide the immediate error while creating a much larger writable surface than the application needs.

Permissions and ownership should match the way the CMS, PHP process, and web server actually run.

If every deployment breaks ownership again and someone has to fix it manually afterward, the real problem is probably in the deployment process.

Running the same chmod command after every release is a workaround, not much of a solution.

10. How I would narrow down a CMS problem

There is no single troubleshooting path that works for every CMS incident.

A stale page points toward caching. A 500 error sends me toward application and runtime logs. A site that becomes unstable only when traffic increases makes resource usage, workers, and database load much more interesting.

Start with the part of the stack that best matches the symptom. Then change direction when the evidence tells you to.

Once the cause is known, leave a short record of what happened.

“Plugin X started failing after version Y” is useful six months later.

“Site fixed” is not.

Troubleshooting a CMS on a Hostomize VPS

One advantage of running a CMS on a VPS is that troubleshooting does not have to stop at the CMS dashboard.

You can inspect web-server and PHP logs, check file ownership, watch memory or worker usage while a slow request is happening, and test the connection from the application server to the database directly.

That extra access matters most when the actual fault sits below the CMS.

If PHP workers or memory are genuinely exhausted, adding resources may solve the problem.

If a plugin is spending four seconds waiting for an external service to respond, another vCPU is unlikely to make that remote service answer any faster.