Critical errors and white screens after an update
Sites that show WordPress's critical error message, a blank page, or a 500 error after a plugin, theme or core update.
Engineering service / Ali Nawaz
When a plugin update breaks your site, the checkout stops taking orders, or a page shows a critical error, I find the plugin, theme or setting causing it and fix it. Send me what you see and when it started. You get a reply within 24 hours and a fixed quote before any work starts, from $100.
The approach
A plugin conflict is rarely about one bad plugin. It's usually two pieces of code that both work alone and fail together: a checkout extension written for the classic checkout on a store that now uses the Checkout block, a caching plugin serving an old script, or an update that needs a newer PHP version than the server runs. Guessing wastes your time. I reproduce the problem on a staging copy, switch things off one at a time, and only change the live site once I know the cause.
You work directly with me from requirements through launch. That keeps product context close to technical decisions and avoids the gaps that appear when strategy, interface, backend, and deployment are treated as separate problems.
What I can build
The scope is shaped around your users, operating reality, and the smallest responsible path to value.
Sites that show WordPress's critical error message, a blank page, or a 500 error after a plugin, theme or core update.
Checkouts that spin, show a generic error, refuse valid cards, or never send the order to the admin.
Payment, shipping and checkout field extensions that don't appear in the Checkout block, or that clash with each other.
Page builders and the block editor failing to open because another plugin breaks their scripts or the server blocks their requests.
Front-end features that stopped working because two plugins load conflicting scripts or a cache plugin serves stale files.
Plugins that need a newer PHP, WordPress or WooCommerce version, with the upgrade planned and tested so nothing else breaks.
Common problems
These are the problems I'm asked to fix most often, with the cause I check first. The real cause is confirmed on staging before anything changes on your live site.
| What you see | Where I look first |
|---|---|
| "There has been a critical error on this website" | The PHP fatal error in WordPress's recovery mode email and the server or debug log, which name the file and plugin that failed |
| Checkout spins, shows an error, or won't place the order | Browser console errors, WooCommerce's fatal-errors log, the payment gateway's own log, and extensions that only support the classic checkout |
| A payment or shipping option disappeared from checkout | Extensions without Checkout block support, which WooCommerce says usually won't be visible there, and rules plugins that hide methods |
| The site broke right after an update | Which plugin, theme or PHP version changed, and whether the new version needs a newer PHP, WordPress or WooCommerce than the site runs |
| Elementor or the block editor won't load | JavaScript errors in the editor, plugins that load scripts on every admin page, and memory or security rules on the server |
| Menus, sliders or forms stopped working | Two plugins loading different versions of the same script, and caching or minify settings that combine scripts in the wrong order |
The method
WooCommerce's own guide to finding a conflict gives the method I follow: switch to a default theme, such as Twenty Twenty-Five or Woo's Storefront theme, deactivate every plugin except WooCommerce and the extension that shows the problem, check whether the problem is gone, then turn plugins back on one at a time until it returns. The same guide reminds you about must-use plugins and drop-ins, which can't be switched off from the Plugins screen and are often installed by your host. Done on a live store, that test switches off features your customers are using. Done on staging, nobody notices.
So I start with a staging copy. Many hosts include one; if yours doesn't, I make a private copy for the job. There I turn on WordPress's debug log. WordPress's documentation says WP_DEBUG_LOG writes errors to a debug.log file in the wp-content folder, and that debugging tools shouldn't be used on a live site. I read that log, the browser console, and WooCommerce's System Status Report, which lists the versions of WordPress, WooCommerce, PHP, the theme and every active plugin, so the first guess is an informed one.
Once the cause is clear, I fix it in the least invasive way: a setting, a small compatibility fix in a custom plugin rather than an edit to someone else's code, a version rollback, or a replacement plugin. I test the fix on staging, apply it to the live site, and test again there.
WordPress tools
WordPress has some protection built in, and knowing what it does saves time. Since version 5.2, when a plugin or theme causes a fatal error, WordPress shows a short error message to visitors and emails the site's admin address a special link. That link opens recovery mode, which pauses the failing plugin only in your browser so you can log in and deal with it. If that email went to an old address nobody reads, that is the first thing I fix.
Since WordPress 6.6, when a plugin updates itself automatically, WordPress loads your homepage afterwards. If that request hits a fatal error, it puts the previous version back, logs the error and emails the admin. It only covers plugin auto-updates, and it only checks the homepage, so problems on other pages still need a person to find them.
Plugins can also declare the other plugins they need, a feature added in WordPress 6.5: a plugin with a Requires Plugins header can't be activated until those plugins are active. And WordPress's official Health Check & Troubleshooting plugin has a troubleshooting mode that disables plugins and switches themes only for your logged-in session. Its directory page warns that it hasn't been tested with the last three major WordPress releases, so I use staging as the main test and the plugin only as a quick check.
WooCommerce checkout
WooCommerce says that, starting with version 8.3 in November 2023, the Cart and Checkout blocks are the default for new installations. Many extensions were written for the older shortcode checkout. WooCommerce's developer FAQ says checkout extensions without block support usually won't be visible in the Checkout block, and that extensions declared incompatible are flagged with a notice in the block's settings sidebar. Extensions that declare nothing can simply disappear without a notice. That's why a delivery date field, a gift message or a payment method can quietly vanish after a redesign or a theme switch.
There are two honest fixes. One is to replace or rebuild the extension for the Checkout block, which I do with WooCommerce's Additional Checkout Fields API and Store API. The other is to switch the checkout page back to the classic shortcode, which WooCommerce still supports. Which one is right depends on how many of your extensions support blocks and what you plan for the store next. I explain the trade-off and you choose.
Checkout failures cost money by the hour, so they come first in my queue. If your checkout is down, say so in the first line of your message.
Before you send it
A few details save a lot of back and forth: the exact error message or a screenshot, the page where it happens, roughly when it started, and anything that changed just before, such as an update, a new plugin or a host move. If WordPress sent a recovery mode email, forward it. If you can open WooCommerce, go to WooCommerce, then Status, click Get system report, and paste it into your message.
Please don't send passwords. When we agree the quote, you create a separate administrator account for me, or give me access through your host's collaborator tools, and you remove it once the fix is confirmed.
Who fixes it
I have built WordPress sites, themes and plugins full time since 2017, and fourteen of my own plugins are open source, including WooCommerce plugins for checkout fields, deposits and delivery options. Writing plugins is the best training for fixing them: I know where hooks, script loading and version checks usually go wrong because I have had to get them right in my own code.
You deal with the person doing the work. I reply within 24 hours, explain the cause in plain words, and leave you a short note of what changed, so the next developer, or you, can understand it later. My prices are set well below typical agency rates, and every fix starts with a free look and a fixed quote, from $100.
What the work should create
Proof of work
All 14 are free and open source, so you can read the code before you hire me. See every plugin.
Client feedback
Reviews from clients I have worked with remotely, quoted as they wrote them.
“Working with Ali was a breeze from begining to end. He was super responsive, extremely knowellegable and was a pleasure to work with. … Hire him now, we already did all the research for you.”
“Ali is one of the best I have worked with. Great English, very smart, and knowledgeable alongside producing great results. Highly recommended.”
“Did an amazing job with my website. Very professional and patient with all my requests”
“Great experience with the Ali! He was very prompt and efficiently handled my request, like an expert! I would definitely recommend him and plan to reach out again for other services!”
“Ali is great to work with. Fully understood what I wanted and got the job completed in super-fast time.”
“Ali is very professional, as my first time working with him I as very happy with the way he handled the project. i would recommend him.”
04 / The process
You get a senior engineering partner—not a black box. The process stays direct, collaborative, and focused on outcomes.
Clarify the problem, users, constraints, and measure of success.
Shape the right product, technical plan, and delivery path.
Create in focused iterations with quality visible at every step.
Test, deploy, measure, and improve with confidence.
Common questions
Fixes start at $100. Every site is different, so I look at the problem first, for free, and then send a fixed quote in US dollars. You know the full price before I start, and nothing is charged for a quote you don't accept.
Within 24 hours. If your checkout is down, say so in the first line of your message and I'll look at that first.
No. Please don't send passwords by email or chat. Create a separate administrator account for me, or invite me through your host or a temporary login plugin, and delete that access once the job is done.
Only when I have to. I test on a staging copy whenever your host offers one, or on a private copy I make for the job. The live site changes once, when the fix is known and you have approved it.
Then I tell you which plugin, what triggers the bug, and what your options are: a setting that avoids it, a small compatibility fix, rolling back to the last working version, or a replacement plugin. If it's a plugin with active support, I write up the bug so you can send it to its developer.
Yes. The most common cause I see is an extension written for the classic shortcode checkout on a store whose checkout page now uses the Checkout block. I check which checkout you run, what the browser console and WooCommerce logs say, and which extension is involved, then fix it or move the page to the checkout your extensions support.
WooCommerce's support policy covers WooCommerce and the extensions sold on WooCommerce.com. It doesn't cover third-party plugins and themes it didn't sell you, may ask you to disable them before helping, and doesn't do customizations. A conflict between two third-party plugins usually needs a developer.
You'll hear that from me plainly, along with what I ruled out and what I'd try next, before any more time is spent, so you decide whether to go on.
Invoices are in US dollars: 50% to start and 50% when the fix is delivered and you have checked it. Every fix includes 15 days of free support in case the same problem comes back.
Start a conversation
Tell me what you’re building, where you are in the process, and what success looks like. I’ll get back to you with a clear next step within 24 hours.
Projects start at $500. The final quote follows the project details.
bealinawaz@gmail.com