Funio or 34SP for testing a PHP upgrade on WordPress without SSH?

Protect the form during a PHP upgrade

An association based in France receives volunteer applications through a WordPress form. The person responsible for the site has access to WordPress and the hosting panel. They must prepare a PHP version change without opening an SSH session. The journey to protect begins on the contact page and ends when the submission is accepted and the association can verify its arrival. The team first wants to reproduce this journey on a private copy, then decide whether the change can be applied to the public site.

The form can deteriorate while the homepage and administration remain accessible. Some code may load only when a submission occurs. A PHP extension missing from the new configuration can also affect an attachment, character processing or a validation function. For the association, a page that opens and an apparent confirmation banner provide little information if the message never reaches the correct destination.

Funio WordPress Starter and 34SP WordPress Hosting 1 Site document PHP-setting workflows. Their value to the association depends mainly on the scope of that setting. You need to know whether the change targets the copy or the public site, which versions are offered and how to restore the previous value. Being able to find a button in the panel matters less than being able to isolate the test and repeat the check.

Prepare a baseline in WordPress

Choose a fictional application you can recognise at every stage. Note the form path, required fields, expected response to an invalid field and intended destination for an accepted test. If the form uses spam protection or an external integration, check that it works on the test subdomain or prepare a separate configuration. A test blocked by the subdomain key cannot establish anything about PHP.

In the public site's administration, open Tools, Site Health, Info, then Server. Record the PHP version observed by WordPress and the settings relevant to the form. Identify active plugins and the theme, along with their versions. Then make the same record on the copy. Keep the date, exact address and useful screenshots in an acceptance-test document. The version displayed in a hosting menu is a configured value. The version observed in WordPress lets you verify what actually runs the site.

Prepare an independent file and database backup and check which point in time it represents. On the copy, keep the same initial PHP version and run the form once. Restrict access to the copy and verify in a private window that an anonymous visitor cannot open it. Replace the production destination with a dedicated test mailbox or log. A test submission must be recognisable and remain in this route. If the copy already fails before any change, correct or document that difference before continuing.

Check the scope of the setting before applying it

Ask who can change PHP on the private subdomain, which starting version remains available and how to tell whether the public site shares the same setting. Administrator access in WordPress provides the means to check the form. Hosting-panel access is used to change the engine. If two volunteers hold these roles, bring the two records together before the person responsible for the panel confirms the change.

Record the target name and the old setting value, including any inherited mode. Do the same for the modules and options actually required. A version label does not say which modules are enabled. A version change may therefore alter both the engine and its settings. If the association must modify a configuration file through the panel, back up that file separately and identify its folder before editing it.

When the provider does not confirm a separate setting or the panel shows only the public site, keep the copy outside this operation. Ask for a destination whose engine can be changed independently. Immediately after a test, reread Site Health on both the copy and the public site. If the public site has changed, restore the previous value and check the public form before resuming. Checking the scope provides more protection than merely planning a rollback in a document.

Reproduce a failure visible only on submission

The downloadable exercise runs four cases locally in PHP. It uses a fictional form and two processing files. The old code declares a string-typed parameter with a null default value without explicitly declaring it nullable. PHP 8.4 flags this form as deprecated. The test deliberately converts that warning into an exception to make the failure observable. A deprecation does not automatically stop every site that loads such code.

Opening the form displays success in the model because the old processing code loads only on submission. With the corrected code version, submission returns the test marker. The fourth case checks that an empty field is still rejected. The correction therefore goes beyond removing an error message. It must also preserve validation. The report statuses represent expected responses in the mock-up, and the PHP engine actually emits the warning.

The ZIP was checked under PHP 8.4.8 on the command line. All four cases run in that same engine. The exercise does not measure a version change in a hosting account. It shows why you must both open and submit the form and distinguish a PHP problem from a delivery problem. To check message delivery on your site, repeat the application from the browser and verify the test destination separately.

• Download the form's PHP acceptance test from “Further reading”, extract the ZIP and check the version with php -v.
• Run php recette.php from the folder. Compare the four statuses and the RECETTE-FRM-01 marker with attendu.json.

Funio Starter and cPanel's per-domain setting

Funio's guide specifies cPanel, Software, then Select PHP Version. It states that custom extensions and options depend on the selected version. On the copy, record useful modules before the change, such as the one handling characters or files in your form. Then check their presence in the new version. Enable only those needed by the form or its environment, and record any difference from the starting point.

For distinct versions across domains or subdomains in one account, the help page describes a PHP handler rule in the relevant folder's .htaccess file. The CloudLinux selector alone cannot directly assign a version to each subdomain. With permission and the handler confirmed by Funio, use File Manager in cPanel, open the copy's root folder, show hidden files and back up its .htaccess. Apply the documented block for the confirmed version and check the version served by the copy. Do not replace WordPress's rewrite block.

Starter lists one site and 20 GB. Panel guides do not prove that this plan allows a second isolated installation or that every option is visible in the account. Confirm the copy's scope and permissions before choosing this approach. If the rule does not apply or causes a server error, restore the backed-up .htaccess in File Manager. If you changed the general selector, restore its initial value and check other affected sites before rerunning the test.

34SP and settings in the WordPress Hosting panel

34SP documents creating the copy through Manage Sites, then the site and the Staging tab. According to the guide, the copy does not count as an additional public site in the container. It consumes resources and space. In particular, it uses a single PHP process and different caching rules. These differences suit a functional form check, with a clear limitation for any speed comparison.

The official workflow for changing the site's engine goes through Manage Sites, the selected site or domain, Advanced, then PHP Version. The Version menu and Update PHP Version apply the documented setting. The two guides establish that the copy and selector exist. They do not confirm that the Staging tab exposes an independent selector in every account. Before touching the setting, ask which entry targets the copy and how to verify it. Keep the public selector at its recorded value during this test.

If 34SP confirms an independent setting, open Site Health on the copy, apply the proposed version and reread the value at both addresses. Then repeat the fictional application. If it fails, restore the initial value on the same target if it is still available, then repeat the check. The rollback button described in the staging help concerns files or a database pushed to the public site. Prepare the PHP version rollback in the selector or with support, depending on the account.

Compare first-month and subsequent prices

Funio's WordPress Starter card shows $3.18 for the first month and $12.71 per month as a crossed-out reference. The billing catalogue lists Starter at USD 12.71 per month. The currency of the $3.18 promotion remains to be confirmed in the summary, along with taxes and the next charge. If the first month is billed at USD 3.18 and the following eleven months at USD 12.71, the calculated total is USD 142.99 excluding taxes and any added options. This calculation estimates one scenario. The billed amount depends on the currency and contract.

34SP's one-site card shows £11.95 per month. The terms state that VAT is included unless otherwise specified, the period is paid in advance and renewal covers a period of the same length. The card does not distinguish an introductory price from a renewal price. Twelve periods at the same rate give £143.40. Tax treatment according to the registrant and the rate at the next renewal remain to be checked. The FAQ shows GBP 9.95 for one site, while the 1 Site card and offering summary show GBP 11.95. The calculation uses the 1 Site card. Confirm the summary amount before subscribing. The hosting programme offered to registered UK charities follows a separate process. The French scenario's budget uses the commercial card.

Calculate the cost for the scope you need. An included copy may avoid paying for a second offering, but its PHP independence must be established. If the association must reserve a separate destination or request intervention, obtain a price for that item and its duration. Put the end of the discount and renewal date on the same schedule as the acceptance test. Compare totals in a common currency only once currencies and fees are confirmed.

Validate the form after the change

After checking the version served by the copy, open the contact page as an authorised visitor would. First submit an application with a required field left empty. Check the displayed message and the absence of a new entry in the test mailbox or log. Then submit a valid application with your marker. If the form offers a file upload and that feature matters to the association, add a fictional attachment small enough to respect the documented limits.

Check three outcomes for the valid submission. The page must display the expected confirmation, the application must appear in the correct place with its marker, and one submission must produce only one entry. If confirmation appears without delivery, record the time and check the plugin log or sending queue. The outcome may stem from mail routing or the copy's configuration. A rejection before sending instead points towards validation, modules or code.

If diagnostics are needed, consult the logs available on the copy. WordPress documents enabling WP_DEBUG_LOG with WP_DEBUG and disabling error display. Use a protected location and record only the relevant error with its time and PHP version. Logs may contain an application's content or an internal path. Restore diagnostic settings to their initial state as soon as the check ends. If the panel hides the log, request the excerpt associated with your test rather than a complete export.

Return to the previous version and choose the offering

If a valid application no longer passes, record the symptom before changing another setting. Restore the initial version on the target and its associated modules. If a handler file was modified on the copy, restore its saved version. Check that WordPress again serves the expected engine, then repeat the application. Reverting the version after a simple PHP-setting change avoids overwriting recent form entries by restoring an entire database.

For Funio, the attraction is the cPanel workflow and documented per-folder method when the account accepts a distinct subdomain. For 34SP, the attraction is the copy accessible through the panel with a documented version selector for the site. The decision depends on confirmation of an independent setting for that copy. If a provider confirms only the public site's version, request a separate test destination before using its workflow for the association.

Once the test succeeds, record the target, chosen version, settings and person who can return to the previous configuration. Have the public form checked with an identifiable application if the association subsequently applies the same change. If the initial version is no longer offered, clarify the available rollback and plugin compatibility before modifying the site. The ability to restore the form, supported by evidence, provides a more concrete decision criterion than the number of versions advertised.

Further reading

• Read the Funio profile
• Read the 34SP profile
• Check WordPress PHP requirements
• Download the form’s PHP test procedure (ZIP)