Not suitable as a shortcut: A successful PHP startup or a working homepage does not prove that checkout, payment callbacks, shipping, or order processing work reliably.
This guide is for teams launching a WooCommerce store for Japan or other East Asian markets, agencies integrating themes and payment services, and operators maintaining several independent stores on one server. It focuses on choosing the initial runtime for a new deployment, not upgrading an existing store.
Last updated October 29, 2026. PHP support and release details were checked against the PHP supported versions list and PHP 8.5 release information. WooCommerce’s published server requirements and PHP test coverage were also reviewed: server requirements and PHP version coverage. Recheck these pages before launch because official compatibility information can change.
Choose a runtime for the store’s actual components
The decision is not simply whether WooCommerce itself starts under a PHP release. A store is a chain of dependencies: WordPress core, WooCommerce, the active theme, extensions, payment processing, shipping and tax integrations, and any custom code. A gap in one component can affect the transaction even when the rest of the site appears healthy.
WooCommerce’s server-requirements page provides a baseline for supported server software, including PHP, database, and HTTPS conditions. WordPress publishes its own recommended runtime requirements. These pages help establish a baseline; they do not certify every third-party extension or a specific combination of components.
The key distinction is between a documented test range and a universal compatibility guarantee. WooCommerce’s developer coverage page currently lists testing through PHP 8.4. PHP’s official support page separately lists the supported PHP branches, including PHP 8.4 and PHP 8.5. That means PHP 8.5 is an available PHP branch, but the WooCommerce coverage page does not list it as tested. The omission is not an official declaration that WooCommerce is incompatible with PHP 8.5; it means teams should not treat that page as evidence of tested coverage for 8.5.
Can a new WooCommerce store use PHP 8.5 directly? It can be considered when every required component has credible compatibility evidence and the complete purchase flow has passed tests in a staging environment. If the evidence is incomplete, start on PHP 8.4 and schedule a separate review of PHP 8.5 after launch. This is a choice about reducing uncertainty, not a claim that 8.5 is inherently unsafe.
A new deployment is a useful time to make this decision deliberately. There may be fewer unknowns than in a long-running store, but the dependencies are still real. Selecting the newest runtime first and discovering a payment or shipping incompatibility during launch preparation can create avoidable rework.
Match the version to the deployment scenario
Use the store’s dependency profile to choose a starting point. The table compares common new-store situations; it does not claim that a particular PHP version is faster or slower.
| New-store scenario | Initial choice | Evidence needed before choosing PHP 8.5 |
|---|---|---|
| Standard store using maintained, well-documented components | PHP 8.4 is the safer default while WooCommerce’s published testing covers through 8.4 | Confirm current WordPress and WooCommerce requirements, then verify each theme and extension against its own compatibility information |
| Store with several payment, shipping, or tax integrations | Start with PHP 8.4 unless all critical vendors document support for PHP 8.5 | Check vendor release notes and test successful and failed transactions, callbacks, refunds, and order status changes |
| Store with a custom theme or in-house PHP code | Use PHP 8.4 for initial production unless the codebase has been reviewed and tested on 8.5 | Run the custom code through staging tests, inspect logs, and test administrative workflows and scheduled tasks |
| Project with a firm requirement to adopt PHP 8.5 early | PHP 8.5 is a candidate only after the full dependency set and rollback plan are verified | Require explicit compatibility evidence for critical components and end-to-end tests that represent actual store operations |
| Several stores hosted on one server | Decide per store; do not copy one store’s validation result to another | Maintain a separate runtime and dependency record for each site, including its own tested fallback |
Which version is a better fit for a new independent store, PHP 8.5 or PHP 8.4? PHP 8.4 is the more defensible initial choice when the objective is to follow the PHP range currently listed in WooCommerce’s test-coverage material. PHP 8.5 is reasonable when the project has a specific reason to use it and can verify the exact components and workflows involved. “Newer” alone is not a compatibility test.
A store with a short dependency list still needs verification. A theme can alter product and checkout pages; an extension can add fields or modify order handling; a payment integration may rely on a separate callback or webhook path. Testing only the storefront misses these failure points.
Verify the compatibility chain
Compatibility evidence should be collected component by component. The official requirements pages establish baseline conditions, while vendor documentation and release notes provide more specific information about extensions and integrations. A forum post can reveal a question or an individual problem, but it cannot establish compatibility for all stores.
The following matrix keeps the evidence type separate from the conclusion. It prevents an isolated “works for me” report from being mistaken for a formal support statement.
| Component or check | Evidence to collect | What that evidence can establish |
|---|---|---|
| PHP branch | PHP’s current supported-version information and release material | Whether the PHP branch is listed as supported by PHP itself; not whether WooCommerce extensions work |
| WordPress and WooCommerce | Official requirements and WooCommerce PHP test-coverage pages | The published baseline and stated testing scope; not a guarantee for every store configuration |
| Theme and extensions | Vendor compatibility notes, release history, and support documentation | Whether the publisher explicitly documents the relevant PHP version |
| Payment, shipping, and tax services | Integration documentation plus test-environment results | Whether the integration’s documented support and actual store flow align |
| Custom code | Code review, staging results, application logs, and repeatable tests | Whether the project’s own implementation works in the tested environment |
WordPress’s requirements page lists baseline server conditions such as PHP 7.4 or newer, MySQL 8.0 or newer, or MariaDB 10.6 or newer, and HTTPS. Those figures describe WordPress’s published requirements; they should not be read as a recommendation to deploy the oldest listed PHP version or as proof of compatibility for every WooCommerce component. Check the current pages before finalizing the environment.
How should a team check whether a WooCommerce plugin works with PHP 8.5? First look for a direct statement from the plugin publisher, ideally in its current documentation or release notes. Then check whether the supported range applies to the installed plugin version, not just a later release. If the publisher gives no answer, mark the plugin unverified and test it in staging. A community report is useful as a lead to investigate, but it is not a substitute for publisher documentation or a test of the store’s own configuration.
The same principle applies to payment systems. “The payment plugin is active” is not the same as “the payment flow is complete.” The storefront may submit an order while a callback fails to update its status. A payment provider may return a response that is handled by custom code or another extension. Shipping labels, tax calculations, emails, and refunds may involve separate paths. Those paths need their own tests.
Test the complete store before launch
A test environment should resemble the planned production environment closely enough to make the results useful. Use the intended PHP version and the same set of themes and extensions. Where an external service provides a sandbox, use it for payment or shipping tests. Avoid running experiments on a live store with real customer data.
How should PHP versions be tested before a WooCommerce launch? Build a staging copy or a clean test installation with the production component set, select the candidate PHP runtime, and run the same purchase and administration workflows that the store depends on. Record the result and any errors. If a required workflow fails on PHP 8.5, investigate the responsible dependency or return to PHP 8.4 for launch.
Use the following sequence:
- Record the baseline. List the WordPress and WooCommerce versions, PHP runtime, database choice, active theme, plugins, custom code, and external integrations. Record where each compatibility statement came from and when it was checked.
- Prepare a representative staging environment. Match the planned production runtime and application components. Keep test credentials separate from live credentials, and confirm that the environment does not send real orders or customer notifications unintentionally.
- Test storefront actions. Open product and category pages, use search and filters where present, add and remove products from the cart, and check that variations or other product options behave as expected.
- Test the transaction path. Submit a test order using the integration’s supported test process. Check the resulting order state, payment confirmation or failure handling, and any callback or webhook action that the integration requires.
- Test operational tasks. Review the order in the administration area, update its status, check shipping and tax behavior where applicable, and test refunds or cancellations if the store will use them.
- Inspect logs and repeat after changes. Look for PHP warnings, fatal errors, and application errors during the tested workflows. WordPress’s debugging documentation explains available debugging approaches. Disable diagnostic settings that could expose sensitive information before production.
- Document the decision and fallback. Record the chosen runtime, the tests completed, unresolved dependencies, and the exact steps for returning to the previously tested runtime if a critical failure appears.
WooCommerce provides guidance for testing orders. Use it alongside the payment provider’s own test procedure. A test order should confirm the behavior the store relies on, not merely demonstrate that a checkout button can be clicked.
A “pass” should also have a clear scope. It means that the documented component set passed the listed tests in the tested environment. It does not prove that an untested extension, a different theme release, or an altered production configuration will behave identically.
Manage separate stores as separate runtime decisions
When several independent stores share a server, avoid treating them as a single application. One store may use a payment extension that has been checked on PHP 8.5, while another relies on an older theme or custom code with no equivalent evidence. A result from the first store does not validate the second.
Maintain a per-site record with the runtime, theme, extensions, integration versions, compatibility evidence, test outcomes, and recovery plan. Before changing a site’s runtime, confirm how that particular site is configured to select PHP and how the change can be reversed. Panel features and runtime-selection methods vary; this guide does not assume that a particular server panel or managed service is available.
For a team managing multiple stores, isolate the deployment process as well as the application records. Make a change to one site in staging, test its workflows, then promote it according to the team’s change process. Do not bundle unrelated PHP changes across every site simply because they share one machine. If a shared host cannot provide the isolation or runtime controls the team needs, consider whether the deployment design should separate the sites.
Store customer and order data according to the team’s retention and access rules. Server selection does not replace application-level access controls, backups, or privacy review. XFP Cloud’s data-handling information can be reviewed as part of that separate hosting assessment, but it does not certify PHP or plugin compatibility.
Complete the launch decision checklist
Use this checklist to decide whether a new store is ready to use PHP 8.5 or should launch on PHP 8.4.
- [ ] The current WooCommerce server-requirements page has been checked for its published PHP, database, and HTTPS conditions.
- [ ] The current WooCommerce PHP test-coverage page has been checked; its listed coverage is not being mistaken for a guarantee about third-party components.
- [ ] The PHP branch’s official support information has been reviewed.
- [ ] The installed WordPress, WooCommerce, theme, and plugin versions are recorded.
- [ ] Every required payment, shipping, and tax integration has a documented compatibility status or is explicitly marked unverified.
- [ ] The staging environment uses the intended runtime and representative production components.
- [ ] Product browsing, cart actions, checkout, payment response handling, and order-status behavior have been tested.
- [ ] Logs have been reviewed after the test flows, and sensitive debug output will not be exposed in production.
- [ ] A failure in a critical dependency has a defined response: repair or replace the dependency, delay PHP 8.5, or launch on the previously tested PHP 8.4 environment.
- [ ] Each independent store has its own compatibility record and rollback procedure.
If all critical components have clear PHP 8.5 evidence and the staging tests pass, PHP 8.5 can be a considered launch option. If one critical dependency remains unknown, PHP 8.4 is the practical default while the team resolves that uncertainty. Revisit PHP 8.5 when WooCommerce updates its published testing scope, PHP publishes a new branch or relevant support information, or a critical vendor provides a compatibility statement.
Match server planning to the tested application
The PHP decision belongs to the application deployment plan; it should not be inferred from a server’s CPU or memory specifications. A physical server can provide dedicated resources, but that does not make an unverified theme compatible. Likewise, a server operating system does not by itself determine which PHP runtime the application will use. Confirm the operating system, installation method, access requirements, and resource needs against the actual product information before committing.
For a Japan-focused WooCommerce launch, the server location, database, storage, backup design, network requirements, and deployment process should be evaluated against the store’s own traffic pattern and operational responsibilities. Do not treat any provider’s general hardware description as evidence that PHP 8.5 is preinstalled or supported. The XFP Cloud server configuration page is the place to verify available server conditions; compare those details with the application requirements and the team’s tested installation plan.
A physical server is not the right fit for every new store. A small project with light, temporary demand may be better served by a lower-commitment shared or cloud environment. For sustained workloads, several stores, or a need for dedicated machine resources, shared hosting can introduce constraints such as competing workloads, limited control over system-level choices, or less predictable resource allocation. Those trade-offs should be compared with the actual operating cost and administration effort, not assumed away.
Once the application’s PHP version and integrations are verified, a dedicated AMD physical server from XFP Cloud may suit a store that needs its own machine resources and a stable environment for ongoing operation. The next step is to compare the current server options with the store’s operating system, access, storage, and network requirements, then deploy the runtime that passed staging tests. No server choice should be treated as a promise that a specific PHP version or WooCommerce component is preinstalled or compatible.
Build a Dedicated Server for Your WooCommerce Store
Choose XFP Cloud to run your store on a dedicated AMD EPYC 7543P server in Tokyo.
From $455 / month