WordPress Bug Fixing: 12 questions answered.

Ideally one of: wp-admin (administrator), SFTP/SSH to the files, and access to the hosting panel or database. For a locked-out wp-admin or a white screen we mainly need file + database access since the admin itself may be unreachable. Tell us what you can provide in the booking form and we’ll work with it, we can also guide you to create a temporary admin or staging snapshot.

Yes, this is one of the most common WordPress emergencies. A host bumps PHP from 7.4 to 8.1+ and an old plugin or theme throws a fatal like Uncaught Error: Call to undefined function or a deprecation that escalates. We identify every component that isn’t PHP-8-ready, update or patch what we can, and replace what we can’t, so you stay on the supported PHP version safely.

It means WordPress can’t talk to MySQL. The common causes are wrong credentials in wp-config.php, a crashed or overloaded database service, or a corrupt table. We verify the connection details, check the database server is up, repair corrupt tables, and bring the site back, then harden it (limits, caching, monitoring) so the connection doesn’t drop again under load.

Yes. We reproduce on a staging clone first wherever access allows, and take a full file + database snapshot before any change. The fix is verified on staging, then deployed to production in a low-traffic window. If anything regresses, one restore from the snapshot puts you back in seconds. Your live site stays up while we work.

Yes. Every fix targets the root cause, not the symptom, and comes with a 14-day re-fix guarantee: if the same bug returns within two weeks, we fix it again at no charge. You also get a short written root-cause note so you understand exactly what went wrong and how it was resolved. For ongoing peace of mind, the Emergency / Retainer plan adds proactive Site Health monitoring.

Emergency tickets, a white screen, a “critical error”, or a store losing money, get a first response in under four hours and are usually resolved the same day. A standard Quick Fix turns around in 24-48 hours. A multi-bug Sprint depends on scope, but you get a clear timeline at quote time. Pasting the exact error text in your report is the single biggest speed-up.

One well-defined WordPress bug is a flat $99 Quick Fix (~4h @ $25/hr), turned around in 24-48 hours. A batch of bugs or one deep root-cause, a fatal after a PHP bump, a broken update, a site that keeps falling over, is the $499 Bug-Fix Sprint (~20h @ $25/hr). Sites that cannot go down get a custom Emergency / Retainer plan with an under-4h SLA. No per-hour surprises: every bug is quoted upfront before work starts.

Yes. A login redirect loop (or ERR_TOO_MANY_REDIRECTS at wp-admin) usually comes from a mismatched siteurl/home setting, a stale cookie domain, an .htaccess rule, or an over-zealous security plugin. We fix it through wp-cli and direct database edits, no need for the broken admin to be reachable, and restore your access in minutes.

The fatal Allowed memory size of … bytes exhausted means a request hit the PHP memory ceiling. We raise WP_MEMORY_LIMIT in wp-config.php and the PHP memory_limit to a safe value, but the real fix is the cause: a runaway database query, a bloated import, an oversized image batch, or a plugin loop that leaks memory. We profile the request and fix the source so it doesn’t come back.

We bisect. On a staging clone we disable all plugins, confirm the error clears, then re-enable them in batches until the culprit reappears, switching to a default theme to rule the theme in or out. This finds the single offending component fast without guessing. Once isolated, we patch it, roll it back, or swap it for a maintained alternative, we don’t leave half your plugins disabled.

Staging first whenever possible. If you have a staging environment we use it; if not, we spin up a clone or work on a copy. For true emergencies where there is no staging and the site is down, we work on live with a snapshot taken first and changes kept minimal and reversible. Either way, nothing irreversible happens without a backup in place.

The White Screen of Death and the message “There has been a critical error on this website” are both WordPress hiding a fatal PHP error. The usual causes are a bad plugin or theme update, a function that no longer exists after a PHP version bump, or a memory exhaustion. We enable WP_DEBUG_LOG, read debug.log, and trace it to the exact line, then patch or roll back the single offender.