Critical Error When Opening a WooCommerce Order? Causes & Fix
You click an order and WordPress replies “There has been a critical error on this website.” Here’s how to read the fatal behind that screen and get the order back — usually with a single plugin update.
Last updated: 17 Jul 2026 · ~6 min read
The cause that most often explains this in 2026 is a bug in WooCommerce PayPal Payments before version 4.1.0 — opening an order whose PayPal payer record contains a phone entry with no number throws a fatal TypeError and kills the page. Update the plugin to 4.1.0 or later and the order opens again. Can’t update this minute? Deactivating PayPal Payments briefly also unblocks the order screen.
What the critical error on an order page actually means
You open WooCommerce → Orders, click into one order — often a PayPal one — and instead of the edit screen you get WordPress’s generic “There has been a critical error on this website” page. Other orders may open fine, which makes it look like the order itself is corrupt. It isn’t.
The order edit screen runs code from every plugin that hooks into it while the page builds. If any of that code throws a PHP fatal, WordPress swallows the whole page and shows the generic error instead. It’s a display-time crash: the order, its line items and the customer’s completed payment are all still in the database, and the customer saw none of this.
The most common causes (most likely first)
- WooCommerce PayPal Payments before 4.1.0 — the payer-phone TypeErrorThe fatal in your log (or in the “technical issue” email WordPress sent the admin address) names
Entity/Phone.php: Phone::__construct(): Argument #1 ($national_number) must be of type string, null given. Opening the order makes the plugin re-fetch it from PayPal’s API, and a payer record that has a phone entry but no number crashes the parser — the pre-4.1.0 code checked that a phone object existed, not that it contained a number. Fixed in 4.1.0 (released June 2026); updating is the whole fix. - An older PayPal Payments crash on the same screenThe fatal path still contains
woocommerce-paypal-paymentsbut names a different class — reports of this symptom go back to 2025, for example a TypeError inRenderAuthorizeAction::render(). Same treatment: update the plugin to the current release, then re-open the order. - A different plugin is the one dying on the order screenThe first
PHP Fatal errorline names another directory underwp-content/plugins/. Whichever plugin’s file appears in that line is the one to update or deactivate — the order screen just happens to be where its code runs. - Every admin page crashes, not just one orderThen this isn’t an order-data bug at all — it’s a site-wide fatal, usually an extension incompatible with a recent WooCommerce or PHP update. Follow the general critical error guide instead.
- PHP ran out of memory building the screenThe log line says Allowed memory size of … bytes exhausted rather than a TypeError. A large order plus heavy plugins can cross the limit — raise
WP_MEMORY_LIMITinwp-config.phpor ask your host to lift the PHP memory limit.
Where to look first
- Get the real error text. Check the “technical issue” email WordPress sent the site admin address — the fatal is quoted at the bottom — or read the server’s PHP error log (or enable
WP_DEBUG_LOGand reload the order page). You want the line startingPHP Fatal error. - Does it name
Phone.php/$national_numberinside woocommerce-paypal-payments? → that’s cause 1. Update WooCommerce PayPal Payments to 4.1.0 or later (Plugins → Installed Plugins, or Dashboard → Updates), then re-open the order. - Can’t update right now? Deactivate WooCommerce PayPal Payments, open the order, do what you need, reactivate. Deactivating doesn’t delete orders or transaction data — but PayPal isn’t offered at checkout while it’s off, so keep the window short.
- Fatal names a different plugin? Update or deactivate that one instead — the file path in the first fatal line is the culprit’s confession.
- Re-open the exact order that crashed. A clean load, with no new fatal line in the log, is your confirmation.
Rather not read stack traces with orders waiting?
The fatal tells you which file died — not whether more of your PayPal orders will do the same, or which other extension is one update behind. DiagnosticIQ’s free dashboard checks WooCommerce and its extensions on a schedule, and its AI pinpoint diagnosis turns a fatal like this Phone::__construct() TypeError into a plain-English root cause and a safe fix. The steps above work perfectly well without it.
Made by Prima Digital — the team behind this guide. Free forever; no card to install.
How to know you fixed it
The order that previously crashed now opens normally after updating PayPal Payments to 4.1.0+, and no new PHP Fatal error line appears in the log when you load it.
Frequently asked
Is the order or the payment lost?
No. The crash happens while the admin page renders — the order, its line items and the completed PayPal payment are intact in the database. You just can’t view the screen until the fatal is cleared.
Why do only some orders crash?
Because the bug needs specific payer data. In versions before 4.1.0, orders whose PayPal record includes a phone entry without a number trigger the TypeError; every other order opens normally, which is why it looks random.
Is it safe to deactivate PayPal Payments to reach the order?
Yes — deactivating a plugin doesn’t delete orders or transaction data. While it’s off, PayPal isn’t offered at checkout, so do it in a quiet window and reactivate as soon as you’ve finished or updated.
Do I need to change anything on the PayPal side?
No. PayPal’s API response is legitimate — a phone number is simply an optional field the old plugin code didn’t handle. Updating the plugin on the WordPress side is the whole fix.