Information checked: 23 October 2026. Use this WordPress PHP update testing checklist with your hosting provider and developer. It describes planning and verification, not instructions to change a live server without appropriate access and expertise.
An emergency PHP update can be technically complete while a business still has unanswered operational questions. Are enquiries arriving? Can customers sign in? Does the checkout still work? Did the updated runtime reach the website itself? A useful testing plan connects the hosting change to the customer journeys that keep the business running.
PHP2Shell makes that coordination particularly important. Our PHP2Shell overview explains the incident background. This article concentrates on testing a WordPress site around a PHP change, with a clear distinction between urgent security remediation and a broader upgrade project. Testing should support timely remediation rather than become an excuse to leave known exposure unresolved.
Define the change before defining the tests
Ask the host exactly what is changing. Installing a security fix within the current maintained PHP branch is different from moving the application to another branch. The latter can introduce additional compatibility work involving plugins, themes, custom code and extensions. Both deserve verification, but the scope and preparation may differ substantially.
Record the current runtime, target runtime or vendor package, affected sites, expected interruption and technical owner. Ask whether background jobs and command-line tasks use a separate runtime. A host may update the web workers while a scheduled import still uses another interpreter. Your test list should reflect the services actually involved.
The WordPress security notice confirms that the original vulnerabilities concern PHP rather than WordPress itself. Updating WordPress or a plugin does not automatically patch the host’s PHP runtime. Keep the hosting work and application maintenance separately described so that “updates completed” has an unambiguous meaning.
Agree responsibilities and an escalation route
Name the person performing the change, the person testing the website and the person deciding how to handle a business-impacting failure. On a small site, one developer may cover several roles. That is acceptable when the responsibilities are explicit. The business still needs to know whom to contact if enquiries stop arriving after the maintenance window.
Agree a contact route that remains available if the website fails. Do not rely solely on a contact form hosted on the system being changed. Identify the supplier’s established urgent-support channel, the internal decision maker and a backup contact. Keep account recovery details securely available to authorised people without copying passwords into the test document.
Define what counts as a release-blocking failure and who can approve the next step. An incorrect telephone number or broken payment flow has different consequences from a small spacing issue. Make the decision criteria specific to the business, while ensuring that any fallback plan also addresses the security problem.
Prepare backups that can support recovery
Confirm that the backup covers the database, uploads, relevant application files and configuration needed for restoration. Record when it was taken and where it can be recovered. A dashboard message saying “backup successful” is helpful, but the recovery owner should understand the restore procedure and any limits of the backup service.
For a busy shop, the database changes while testing is underway. Restoring an earlier copy can discard later orders, customer accounts or stock movements. Agree how those changes would be preserved or reconciled before maintenance begins. The person approving recovery needs to understand that a website restore can affect business records as well as page appearance.
If compromise is suspected, backup selection needs additional care. The newest backup may include unwanted changes, while an older one may omit legitimate transactions. Ask an appropriate specialist to assess the recovery point and preserve relevant evidence. Do not automatically overwrite the current environment merely because a backup is available.
Use staging that represents the live application
A staging site is valuable when its relevant conditions resemble production. Check the WordPress version, active plugins, theme, custom code, PHP extensions and important configuration. A clean demonstration site with different integrations cannot establish that the real business workflow will behave correctly after the change.
Protect staging access and handle personal data appropriately. Where possible, use representative test data instead of unnecessary customer records. Make sure test transactions do not send real customer notifications, trigger fulfilment, update live stock or overwrite production information. The developer should understand which external services remain connected and which use test modes.
Document differences that cannot be reproduced. For example, a payment provider’s sandbox may not behave exactly like its live service, and email delivery may use a different route. Those limitations should lead to carefully planned production checks after remediation, not a claim that staging has proved every part of the live system.
Establish a baseline before the change
Record the current behaviour of the most important journeys. If a form already fails before maintenance, discovering the same failure afterwards does not establish that the PHP update caused it. A baseline helps separate pre-existing issues from regressions and gives the technical team a clearer starting point.
Use a small test matrix with the journey, expected result, test account or data, person responsible and outcome. Include the actual destination of submitted information. “Thank-you page displayed” is not the same as “enquiry arrived in the correct inbox and CRM”. Choose evidence that matches the business outcome.
Keep the baseline proportionate. A five-page brochure site and a complex membership shop need different coverage. Start with functions that create enquiries, revenue, bookings or account access, then include representative content layouts. Avoid spending all the available time comparing decorative details while critical transactions remain untested.
Test enquiries from start to receipt
Open each important form on a phone-sized and desktop view. Check labels, required fields, validation messages and the confirmation step. Use clearly labelled test information so staff can identify the submission. Agree who will receive it and how the test record will be handled without confusing it with a genuine prospect.
Confirm delivery through the whole route. Does the intended mailbox receive the message? Does the CRM create the expected record? Are attachments handled correctly where authorised uploads are part of the journey? A visible success message can occur even when a later email or integration step fails.
Check error handling as well as success. A missing required field should produce understandable feedback without losing the rest of the form unnecessarily. Avoid uploading sensitive files or running aggressive inputs as part of ordinary functional testing. Security testing is a separate, specifically authorised activity with its own scope and safeguards.
Check login, sessions and account journeys
Use an authorised test account with permissions appropriate to the feature being checked. Confirm login, logout and access to the expected account pages. If the site has membership restrictions, check that the test account can reach its permitted content and that a logged-out visitor sees the intended access behaviour.
Do not use another customer’s account or reset a real customer’s password merely to test a workflow. Agree a controlled recovery test where that feature matters. Record any email dependencies and ensure the test does not lock out staff or invalidate credentials they need during maintenance.
The 23 October PHP notice concerns an unusual session-serializer and upload-progress combination, with a further advisory planned. Ask the host and developer to assess current applicability separately from the original fixes. Functional login tests alone cannot determine whether that particular condition exists or establish security status.
Test checkout and bookings without unwanted commitments
For an online shop, map the path from product selection to order confirmation. Include variations, delivery choices, tax presentation and coupon behaviour where relevant. Use the payment provider’s approved testing approach and coordinate with whoever handles fulfilment. A casual live purchase can create real charges, stock changes and administrative work.
For bookings, check availability, date selection, confirmation and any expected notification. Test data should not remove genuine customer capacity or create an appointment that staff mistakenly honour. Agree how test bookings are identified and safely cleared through the normal business process.
Confirm the downstream record, not only the screen. Does an order have the expected status? Did the booking reach the correct calendar or management system? If a process runs asynchronously, give the responsible person a defined verification step rather than assuming that the initial confirmation proves completion.
Include uploads, search and background work
Some important failures occur away from the homepage. Check authorised media uploads, document generation, site search, filters and customer downloads where the business uses them. Select representative file types and sizes within the normal supported workflow. Do not create unusually large or hostile test files as an improvised security exercise.
Ask the developer to review scheduled tasks such as product imports, renewal processing, report generation and integration queues. A job that runs overnight may not be exercised during a short daytime smoke test. Record when its next normal execution will be checked and who will look for failure evidence.
Where an integration depends on an external provider, distinguish the website’s output from the provider’s response. A temporary external outage can resemble a regression. Preserve useful error details and timestamps so the relevant teams can trace the request without sending unnecessary personal data around.
Review errors and confirm the active runtime
The technical owner should review relevant application and server errors around the change. A warning that does not appear to visitors may still reveal a compatibility issue worth resolving. Conversely, an old log entry should not be reported as a new regression without checking its timestamp and context.
Ask for confirmation that the target fixed package is active in the environment serving the website. A successful installation message is not the same as verification of every relevant running process. Where a vendor uses backports, retain the package and advisory reference instead of judging the installation from an abbreviated version string alone.
Keep the final record concise: change completed, runtime evidence, journeys tested, failures found, owners and follow-up dates. If a test was not performed, mark it as not tested. That is more useful than a blanket “all fine” statement which future staff cannot interpret or reproduce.
Plan recovery without restoring known exposure
A fallback plan should preserve the security objective. Do not respond to a compatibility problem by leaving a known vulnerable runtime publicly exposed indefinitely. Ask the host and developer to select an appropriate remedy, which may involve correcting the application, using another fixed supported package or temporarily isolating affected functionality.
The business owner should understand the trade-off between availability and exposure, while technical decisions remain with qualified people who know the environment. If temporary service interruption is necessary, agree a clear customer message and an established alternative contact route. Also define the evidence needed before normal operation resumes.
Avoid mixing unrelated redesign work into emergency maintenance. Keeping the change focused makes it easier to identify the cause of any failure. Broader improvements can follow through a separate plan, including the maintenance and support arrangements discussed through our web design services.
Close the task with evidence and ownership
Ask the tester to sign off the specific journeys checked, with a date and the environment used. Include unresolved issues and any staging limitations. The host’s remediation confirmation and the developer’s functional test record should support one another while remaining separate pieces of evidence.
Arrange a defined check of deferred tasks such as overnight imports or renewal jobs. This is a handover responsibility, not an assumption that someone will notice a problem. If monitoring or follow-up is outside the current maintenance agreement, make that gap visible so the business can arrange appropriate coverage.
Finally, retain the record where the next maintainer can find it. A future incident should not require reconstructing who changed PHP, which backup was available and why a temporary measure remains in place. Good documentation reduces that uncertainty without pretending that any test plan guarantees a problem-free website.
Frequently asked questions
Is a working homepage enough after a PHP update?
No. It does not establish whether enquiries, account access, payments, bookings or background tasks work. Choose representative tests based on the functions the business actually depends on and verify the destination of submitted information.
Should a branch upgrade be treated like a small patch?
No. A branch change may require broader compatibility work. Ask the technical owner to distinguish immediate security remediation from the supported-platform upgrade plan and explain the testing required for each.
Can staging prove the live site will work perfectly?
No. Its value depends on how closely relevant conditions match production. Record differences, particularly external integrations and payment modes, and plan proportionate live verification after the change.
Can I revert to vulnerable PHP if something breaks?
Do not use that as an unattended recovery strategy. Escalate to the host and developer for a remedy that addresses both the operational failure and the security exposure, with temporary controls where appropriate.
Do functional tests prove that a site was not compromised?
No. They check expected application behaviour. Historical compromise assessment requires a different evidence review and may need specialist support. Keep those conclusions separate in your maintenance report.
Who should keep the testing record?
The business should know where it is held, and authorised maintainers should be able to access it. Record the change owner, test results, outstanding work and recovery assumptions so that responsibility survives staff or supplier changes.
