How to Update PHP Safely for WordPress + Free Update and Acceptance Checklist
Updating PHP is more than selecting a version in a hosting panel. For a business website, completion means the security fix is applied, the application remains compatible and customers can still enquire or order. Use this preparation-to-acceptance process with the maintainer who understands your site. Updated: 31 October 2026.
Updating WordPress is not the same as updating PHP
The host provides PHP; WordPress core, themes and plugins are another layer. An up-to-date WordPress dashboard does not prove that PHP has been patched. Record the full version under Tools → Site Health → Info → Server and confirm it with the host. Command-line PHP can also differ from the runtime handling web requests.
Separate urgent patching from a wider migration
Choose a patched, supported package using the latest PHP and hosting-vendor advisories. A broad recommendation such as PHP 8.3 or higher does not establish that a particular patch is installed: the point release and vendor backport evidence matter. A move between branches also requires compatibility checks for themes, plugins, custom code and extensions.
Before the update: six preparation checks
□ 1. Record PHP, WordPress, theme, plugin and extension versions and hosting configuration; name the operator and acceptance owner. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 2. Back up files and the database to an appropriate separate location; confirm timestamps and restoration access. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 3. Test restoration in an isolated staging environment. Restrict personal data access and disable real payments and automatic emails there. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 4. Identify unsupported plugins and custom features and check compatibility with their developers. A scanner does not replace functional tests. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 5. Prepare necessary core, theme and plugin updates in staging, recording changes at each stage rather than changing everything blindly. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 6. Agree the production window, customer notice, monitoring owner and containment/restoration plan if tests fail. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
During the update: validate staging before production
The host or developer should select the target package and confirm that required extensions, configuration and workers load correctly. Test the important journeys in staging before changing production. If a white screen or 500 error occurs, preserve logs and investigate compatibility or configuration. Reopening an unpatched older runtime to the public is not a completed remediation.
Free resource: WordPress PHP Update and Acceptance Checklist
The editable Word template contains six preparation checks, six post-update checks, a change record and failure-handover fields for internal IT or your host. Links are supplied by email. The request requires email, intended use and an initially unchecked subscription choice for occasional Allua marketing updates, with unsubscribe available at any time.
After the update: six business acceptance checks
□ 1. Read back the live PHP/package and advisory-specific patch status across the relevant nodes and workers. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 2. As a logged-out visitor, test the homepage, important services, articles, search and common mobile pages. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 3. Check login, membership permissions and administration editing without inadvertently widening access. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 4. With authorised test data, submit an enquiry and confirm the stored record, notification email and CRM receipt. A success screen alone is not delivery evidence. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 5. Where applicable, use test mode to check cart, totals, payment callbacks and booking confirmations without charging real money. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
□ 6. Review error logs and scheduled jobs. Record the observation period, remaining errors and owners before closing the change. Record: confirmed / action required / not applicable (reason), owner, date and evidence. If the evidence is unavailable, a check fails or the action requires server access, pass this item to the maintainer; suspected compromise goes to an incident-response professional.
Worked example: accepting a lead-generation site
Illustrative process: before the change, test service page → enquiry form → stored record → notification email. Repeat that same journey afterwards and record the time, result and record identifier. Checking only that the homepage loads can miss a broken form-delivery step that prevents the business from receiving enquiries.
Frequently asked questions
Q: Can a security plugin do this instead?
A: It does not replace the host's PHP patch.
Q: Is a successful backup sufficient?
A: You also need an owner and a verified restoration route in the intended environment.
Q: Is a plugin always responsible for failure?
A: Themes, custom code, missing extensions and hosting configuration can also be involved. Follow the logs.
Q: Will an update guarantee better speed or rankings?
A: No. Measure performance and search outcomes under comparable conditions. Security patching remains necessary independently of those outcomes.
Agree the acceptance scope before making changes
To discuss website maintenance with Allua, provide the URL, platform, important form or checkout journeys and current maintenance arrangements. Enquiries: https://www.alluatech.com/contact-us
Official references
WordPress PHP updates: https://wordpress.org/support/update-php/
WordPress debugging: https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
PHP announcements: https://www.php.net/
Hosting-provider example (provider-reported patch deployment; confirm your own service): https://www.siteground.com/blog/critical-php-vulnerabilities-october-2026
Disclaimer
This article is based on general scenarios and information available as of the stated update date. It is for general information only and does not replace a professional assessment of your individual system. Hosting environments, PHP versions, configurations, plugins and integrations vary. Before updating software, changing settings, restoring a system or taking other action, consult a professional web developer or hosting provider to assess your specific circumstances and determine the appropriate action. If you suspect a compromise, also seek help from a professional experienced in cybersecurity incident response.
Comments