Website bug fixes

Fixing the cause, not the symptom

A contact form stops sending. The quick fix is to install a different form plugin, and the form works again for a while. The real cause, more often than not, is that the site sends email through the web server instead of a proper mail service, and receiving servers have started rejecting it. Swap the plugin and the problem returns in a month, now with two form plugins installed.

We look for that underlying cause first. Server error logs, the browser console and the list of recent updates usually point straight at it. Many website bugs turn out to have the same few roots: an update that changed how a plugin behaves, a caching layer serving an old version, a theme that was edited directly and then overwritten, or a hosting limit being hit.

Why we fix on a copy first

Changing a live site to find a bug is how a small problem becomes an outage. A setting toggled to test a theory can break checkout for every visitor while the test runs. So wherever the host allows, we make a staging copy, reproduce the bug there, and prove the fix before touching the live site.

Every job starts with a full backup and ends with a log: what was wrong, what caused it, what we changed and where. That log is useful long after we finish. When the same symptom returns after an update, whoever looks at it next starts from the answer rather than from scratch.

• Forms that do not send: usually mail delivery, not the form itself
• Layout broken after an update: usually a theme or builder version change
• Changes not showing: usually caching at the server, plugin or CDN level
• White screen or 500 error: usually a PHP version or memory limit