WORDPRESS AFTER A PHP UPDATE: REPAIR CHECKLIST
Turing Websites | 1 November 2026
https://turingwebsites.com/services/wordpress-php-update-repair

An editable worksheet for your website owner, host and developer.
Use the first section for an initial enquiry. Keep private technical evidence
and account access in your existing secure support channel.

1. DESCRIBE THE CHANGE
Website URL:
Hosting provider:
When the site last worked (include timezone):
When the problem first appeared:
PHP version before and after, if known:
Other theme/plugin/core changes made at the same time:
Affected action: page / wp-admin / form / booking / checkout / other:
What the customer expects:
What happens instead (short, sanitised description):

2. PRESERVE CURRENT RECORDS WITH YOUR HOST
Who is responsible for the current backup?
Backup time and location, held privately:
Does it include the database, code, uploads and configuration?
Are orders, bookings or accounts still being created?
Who will account for records created since the backup before any recovery?

3. GATHER PRIVATE ERROR EVIDENCE WITH YOUR HOST OR DEVELOPER
Recovery Mode email received: yes / no / unknown:
Affected component named by WordPress, if any:
Error category and time in private PHP logs:
Web-serving PHP runtime and host package confirmation:
Theme, child theme, plugins and custom code involved:

Keep recovery links, full logs, server paths, credentials and customer records
out of an initial enquiry. Recovery Mode can help in some fatal-error cases;
its email can fail to arrive. Your host can help obtain private error evidence.

4. AGREE AND CHECK THE REPAIR WITH YOUR DEVELOPER
Test environment or other recovery arrangement:
Current backup checked before changing code:
Staging separated from customer emails, live payments and production webhooks:
Component update, replacement or code repair needed:
Supported, patched PHP configuration to serve the repaired website:
Customer activity to preserve during deployment:

5. RECORD THE CUSTOMER-ACTION CHECKS
For each relevant action, record environment, time, result and who checked it.
Home page and the affected page:
Administrator sign-in:
Contact form -> expected inbox or saved record:
Booking -> appointment and confirmation:
WooCommerce test-mode payment -> order, payment result and receipt:
Relevant delivery and tax checks:
Account sign-in and the affected customer task:
Items still requiring attention:

A page loading does not establish that forms, bookings or payments work.
Use the payment provider's supported test mode with the developer responsible
for the shop. A database recovery must account for newer customer records.

GET HELP
https://turingwebsites.com/contact?enquiry=wordpress-php-repair#enquiry

PRIMARY REFERENCES
https://wordpress.org/documentation/article/recovery-mode/
https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
https://wordpress.org/support/update-php/