PHP Version and Extension Compatibility Guide for WordPress, OpenCart, Magento and Corporate Apps

PHP version and extension choices silently decide whether your WordPress, OpenCart, Magento or in‑house corporate app will be fast and secure – or unstable and unmaintainable. When we review new projects moving to dchost.com, we often see the same pattern: great code deployed on the wrong PHP version, or missing a single critical extension like intl or sodium. The result is random white screens, broken payment modules, or admin panels that only work on one specific server. In this guide, we will walk through practical PHP version and extension compatibility rules for the most common stacks we see: WordPress (including WooCommerce), OpenCart, Magento 2 and custom corporate applications. You will see which PHP versions are safe to use today, which extensions are non‑negotiable, how to test upgrades on staging, and how we typically configure PHP environments on shared hosting, VPS and dedicated servers at dchost.com.

Why PHP Version and Extensions Matter So Much

Every PHP application is written and tested against a set of assumptions: a minimum PHP version and a list of required extensions. When you go below that, you hit fatal errors. When you go above it without testing, you can hit deprecated features and subtle bugs. On top of that, older PHP versions quickly stop receiving security fixes, which is a real risk for e‑commerce and corporate portals handling personal data.

Extensions matter just as much. WordPress core can technically run with a minimal extension set, but plugins and themes assume things like mbstring, intl, gd or imagick are there. Magento is even stricter: miss one of the required extensions and the installer or setup:upgrade simply fails. Understanding this compatibility matrix is the key to planning safe upgrades and choosing the right hosting plan.

PHP Version Compatibility for WordPress, OpenCart, Magento and Corporate Apps

PHP lifecycle at a glance

Before looking at individual apps, it helps to know where PHP itself stands (dates approximate):

• PHP 7.4: End of life, no security fixes. Only use if you are forced by legacy code and isolate it.
• PHP 8.0: Also end of life. Time to move away.
• PHP 8.1: Widely supported by major apps and plugins. Good choice for compatibility‑first setups.
• PHP 8.2: Current stable with security support and performance improvements. Great default if your stack supports it.
• PHP 8.3+: Very new; good for forward‑looking projects, but test carefully with all extensions and vendor code.

Our rule of thumb at dchost.com: use the newest PHP version that your application officially supports and you have tested on staging.

WordPress and WooCommerce: recommended PHP versions

WordPress itself is quite flexible, but the ecosystem (plugins, themes, WooCommerce) is what really drives PHP requirements.

• Minimum (WordPress core): 7.4, but this is only a theoretical baseline.
• Realistic minimum for 2024+: PHP 8.0 or 8.1, because many newer plugins assume 8.x features.
• Recommended today: PHP 8.1 for maximum compatibility or 8.2 if all your plugins/themes support it.

For WooCommerce stores, we strongly suggest 8.1 or 8.2. The performance difference versus 7.4 is very visible in checkout and search. If you are planning a version jump, our detailed PHP 8 upgrade guide on shared hosting and VPS walks through a safe migration path with staging and backups.

OpenCart: PHP compatibility by generation

OpenCart’s ecosystem is more fragmented, because many stores run heavily customized forks or old versions. Rough ranges you can use as a starting point (always check your exact version’s docs and extensions):

• OpenCart 1.5.x: Designed for old PHP 5; should be migrated. If you must run it, isolate it on a separate PHP version and server.
• OpenCart 2.3.x: Usually supports PHP 5.6–7.2; many production stores run it on 7.2 or 7.3 with compatibility patches.
• OpenCart 3.0.x: Commonly used with PHP 7.2–8.0; newer builds and patches can work on 8.1.
• OpenCart 4.x: Targeted at PHP 8.1+, with modern syntax and better security baseline.

Because extensions and themes may be encoded (ionCube) or use deprecated functions, we always recommend testing each OpenCart upgrade on a cloned staging store with the target PHP version before touching production.

Magento 2: strict PHP version matrix

Magento’s compatibility story is stricter and more formal. You must match your exact Magento 2 minor version with a specific PHP version. Examples (always confirm in Magento’s official devdocs):

• Magento 2.4.3: Typically PHP 7.4 only.
• Magento 2.4.4 / 2.4.5 / 2.4.6: PHP 8.1 is the main target.
• Magento 2.4.7 and above: Focus on PHP 8.2, dropping older versions.

Running Magento on a newer PHP version than officially supported can cause subtle issues in DI, type hints, and third‑party modules. On dchost.com we usually pin Magento projects to the officially supported PHP version for that Magento release, even if newer PHP versions exist, and upgrade Magento + PHP together in a controlled maintenance window.

If you need tuning recommendations for CPU, RAM and database alongside version choices, our hosting guide for Magento with CPU, RAM and Redis planning is a good companion read.

Corporate and custom PHP applications

Corporate apps (custom CRMs, intranets, partner portals) vary the most, but you can still use a structured approach:

• Check composer.json: Look for a php constraint (for example, "php": "^8.1" or "^7.4 || ^8.0").
• Check the framework: Laravel 9+ prefers 8.1+, Symfony 6 prefers 8.1+, older versions may support 7.4 but are nearing end of maintenance.
• Check vendor libraries: Some payment SDKs or SSO libraries have their own PHP minimums.
• Decide your floor: For anything new or actively developed, align on PHP 8.1/8.2. Only keep 7.4 for legacy apps you are actively planning to replace.

For complex corporate stacks, we often run multiple PHP versions side by side on a VPS or dedicated server and route each virtual host to the appropriate PHP‑FPM pool. Our article on managing multiple PHP versions per site on cPanel and DirectAdmin shows how we approach this in a multi‑site environment.

Core PHP Extensions Required by Popular Apps

Baseline extensions almost every app needs

Regardless of CMS or framework, most modern PHP applications assume this baseline:

• curl – HTTP requests to APIs (payment gateways, CRMs, email services).
• mbstring – Multibyte string handling for UTF‑8 content.
• json – JSON encoding/decoding (often built in since PHP 8.0).
• pdo_mysql (or mysqli) – MySQL/MariaDB database access.
• openssl – TLS/SSL operations, OAuth, encryption.
• zip – Plugin/module installs, backups and export features.
• fileinfo – MIME type detection for uploads.
• intl – Locales, number/date formatting, slug handling for non‑English content.

At dchost.com we consider these the default minimum. On custom VPS or dedicated servers we provision, we typically also enable bcmath, exif, soap and sodium unless there is a specific reason not to.

WordPress & WooCommerce: must‑have and nice‑to‑have extensions

WordPress core can run on a very small extension set, but in the real world you will want at least:

• curl – For automatic updates, remote requests, REST API integrations.
• mbstring – Essential for correct search, slugs and handling non‑ASCII content.
• pdo_mysql or mysqli – WordPress database access.
• gd or imagick – Image resizing, thumbnails, PDF previews.
• intl – Better locale handling, useful for multilingual sites.
• zip – Installing themes/plugins from ZIP files and backup plugins.
• exif – Image metadata (orientation, camera info).

For WooCommerce stores, additional extensions might be used by specific plugins:

• soap – Some payment and logistics integrations still use SOAP APIs.
• sodium / openssl – Token encryption, webhooks, secure callbacks.

If you are planning performance work, enabling and tuning OPcache is almost mandatory. Our PHP OPcache settings guide for WordPress and WooCommerce explains how we configure OPcache on shared hosting and VPS for a good balance of speed and memory usage.

OpenCart and Magento: stricter extension requirements

OpenCart typically assumes a similar set of extensions to WordPress (curl, mbstring, zip, gd, pdo_mysql/mysqli). Where we see problems is when server builds are too minimal and miss zip (extension installer fails) or fileinfo (file upload errors).

Magento 2 has a longer and more demanding list. A typical Magento 2.4.x installation requires or strongly recommends:

• bcmath – Arbitrary precision math; used in pricing and tax calculations.
• ctype, dom, xml, simplexml, xsl – XML manipulation, config parsing, layout rendering.
• curl – Remote API calls (payments, shipping, marketplace services).
• gd or imagick – Image processing for product images and thumbnails.
• intl – Localization and number formatting.
• mbstring – UTF‑8 safety.
• pdo_mysql – MySQL database access via PDO.
• soap – SOAP APIs (still used for some integrations).
• sodium / openssl – Encryption and secure tokens.
• zip – Component packaging and deployment scripts.

On Magento servers we deploy, we also enable and carefully size OPcache and often APCu (for local, in‑process cache) plus Redis for external cache and sessions. This combination significantly reduces PHP process load during peak traffic.

Extensions often missing on minimal or custom servers

When developers rent a raw VPS and install PHP with minimal options, we usually see the same missing extensions causing runtime errors later:

• intl – Multilingual slug/URL issues, crashes in certain plugins.
• fileinfo – File upload validations failing silently.
• exif – Images appearing rotated incorrectly after upload.
• zip – Cannot install plugins, cannot extract update packages.
• soap – Broken payment or shipping integrations.
• ionCube – Required by some commercial modules; we usually try to avoid this dependency long‑term, but sometimes you need it to keep legacy code alive.

If you are building your own stack on a VPS or dedicated server at dchost.com, it is worth defining a “standard extension profile” per project type (for example, one for WordPress/WooCommerce and another for Magento) and applying it consistently across environments.

How to Check Your Current PHP Version and Extensions

Checking via hosting control panels

On shared hosting or managed servers with a control panel, you can usually check your PHP details without shell access:

• cPanel: Look for “Select PHP Version” or “MultiPHP Manager”. These pages show the current version and enabled extensions per domain.
• DirectAdmin / Plesk: Similar sections exist under domain configuration; you can often switch PHP mode (CGI, FPM) and toggle extensions.
• phpinfo() page: As a fallback, create a file such as phpinfo.php with <?php phpinfo(); ?>, upload it to the site and open it in the browser. Remember to delete it afterwards for security.

On our shared hosting plans at dchost.com, customers can change PHP versions per site and enable/disable most common extensions directly from the control panel, which makes compatibility testing significantly easier.

Checking via SSH on a VPS or dedicated server

If you have shell access, the CLI tools are faster and scriptable:

• Check PHP version: php -v
• List loaded extensions: php -m
• Check a specific extension: php -r "var_dump(extension_loaded('intl'));"
• Find php.ini location: php --ini

Be aware that CLI PHP and web PHP are not always the same. On multi‑PHP setups, the CLI may run 8.2 while your site uses 8.1 via PHP‑FPM. Confirm the version shown in phpinfo() for the web context as well.

Composer, frameworks and automated checks

Modern frameworks and package managers already encode compatibility information that you can reuse:

• composer.json: The require section often contains a PHP version constraint and extension requirements such as ext-intl or ext-gd.
• composer check-platform-reqs: This command verifies that the current PHP runtime and extensions satisfy the package requirements.
• Framework commands: Symfony and Laravel commands often emit deprecation warnings when you run them on newer PHP versions, which is a signal to test carefully before upgrading production.

Using these tools as part of your CI/CD pipeline helps catch incompatibilities early, before they appear as 500 errors on your live store.

Upgrade Strategies Without Breaking Your Site

Always use a staging environment

The safest way to change PHP version or extension sets is to do it on a staging clone of your site first. For WordPress, that can be a subdomain with a copy of the files and database. For Magento and OpenCart, a separate virtual host with its own config and base URL is better.

We generally recommend:

• Clone production to staging (files + database).
• Update configuration (URLs, cache directories, mail settings).
• Switch staging to the target PHP version and extension set.
• Run application upgrade routines (for example, bin/magento setup:upgrade).
• Browse both frontend and backend, run through key flows (checkout, login, form submissions).

If you are not yet using staging, our articles on creating a WordPress staging environment on shared hosting and on noindex, password and IP restriction strategies for staging can help you set this up safely.

Dealing with outdated plugins, themes and modules

In practice, the biggest blockers to PHP upgrades are third‑party components:

• WordPress: Old premium themes, page builders or WooCommerce extensions that have not been updated for PHP 8.x.
• OpenCart: Encoded modules requiring an old ionCube loader that does not exist for newer PHP versions.
• Magento: Marketplace modules tied to specific Magento + PHP combinations.

Our usual approach is:

1. Identify problematic components on staging by enabling error logging and checking logs under load.
2. Check whether newer versions of those components support PHP 8.1/8.2.
3. If they are abandoned, replace them with actively maintained alternatives or custom code.
4. Only keep legacy PHP versions (7.4, 8.0) as a temporary bridge with a clear removal date.

This is where having control over your PHP environment helps: on a VPS or dedicated server at dchost.com, we can run a legacy PHP‑FPM pool on a separate port, route a single vhost to it, and keep the rest of your sites on modern PHP. That allows a gradual migration instead of a big‑bang upgrade.

Backups, rollbacks and time windows

Even with careful testing, you should plan for a clean rollback option during PHP version changes:

• Take full backups (files + database) just before the change and verify they can be restored.
• Note the previous PHP version and extensions, so you can revert quickly via your control panel or configuration management.
• Plan a maintenance window for major changes, especially with Magento or heavy WooCommerce stores.

We recommend aligning PHP changes with your existing backup strategy. If you are still designing that, our article on how to design a backup strategy with RPO/RTO in mind covers practical patterns for blogs, e‑commerce and SaaS apps on shared hosting, VPS and dedicated servers.

Recommended PHP Versions and Settings on dchost.com

WordPress and WooCommerce

For new WordPress and WooCommerce projects on dchost.com, our default recommendation today is:

• PHP version: 8.1 for maximum plugin compatibility, or 8.2 for new builds where you control the code.
• Extensions: curl, mbstring, pdo_mysql, openssl, intl, fileinfo, exif, gd or imagick, zip, json, sodium, bcmath.
• OPcache: Enabled with a reasonable memory size (for example, 128–256 MB depending on site size), proper revalidation settings and blacklist for auto‑generated files.

On shared hosting, we typically set conservative defaults for memory_limit, max_execution_time and upload limits, and then increase them for large WooCommerce stores or sites using heavy page builders. For precise values and rationale, see our guide on the best php.ini settings for WordPress and Laravel and our article on choosing the right PHP memory_limit and other limits.

OpenCart and Magento

For OpenCart and Magento, we treat each project individually, but some patterns are consistent:

• OpenCart 3.x: Aim for PHP 7.4–8.1 depending on extension compatibility, then plan a roadmap to OpenCart 4.x + PHP 8.1/8.2.
• OpenCart 4.x: Target PHP 8.1/8.2 with the standard e‑commerce extension set (curl, mbstring, intl, zip, fileinfo, gd, pdo_mysql, soap as needed).
• Magento 2.4.x: Pin to the officially supported PHP version (usually 8.1 or 8.2) and enable all required extensions as per Magento docs.

On VPS and dedicated Magento servers, we enable separate PHP‑FPM pools for admin and frontend, fine‑tune process counts, and integrate Redis and Elasticsearch/OpenSearch as required. PHP‑level tuning (OPcache, realpath cache, FPM process model) is combined with OS‑level tuning for best results.

Corporate and custom applications

For corporate stacks with multiple apps (marketing sites, portals, APIs, dashboards) sharing the same infrastructure, we usually propose:

• Standardizing on PHP 8.1 or 8.2 for new projects.
• Keeping a legacy pool (for example, PHP 7.4) only for specific apps with a clear replacement plan.
• Using per‑app php.ini overrides for settings that differ: memory_limit, max_execution_time, error_reporting.
• Documenting extension dependencies in each app’s repository (for example, ext‑intl, ext‑redis) so provisioning is repeatable.

On VPS and dedicated servers at dchost.com, we design PHP‑FPM pools, system users and directory structures so each corporate application is isolated but still easy to manage. That makes gradual migrations and version upgrades safer and more predictable.

Practical Compatibility Checklist Before You Change Anything

Here is a condensed checklist you can run through whenever you are planning a PHP version or extension change for WordPress, OpenCart, Magento or a corporate app:

1. Inventory your stack: List CMS/framework versions, plugins/modules, and any custom code repositories.
2. Find official requirements: Check the docs for WordPress/WooCommerce, OpenCart, Magento or your framework to see supported PHP versions and required extensions.
3. Scan composer.json: Note the PHP and ext-* requirements declared by your dependencies.
4. Check your current environment: Use phpinfo(), control panel or php -v / php -m to see the current PHP version and extensions.
5. Build or refresh staging: Clone your site/app and configure it to use the target PHP version.
6. Enable logging: Turn on PHP error logging and application logs; verify log files are being written.
7. Test critical flows: Logins, registrations, checkout, search, form submissions, cron jobs and integrations.
8. Fix and retest: Update or replace incompatible plugins/modules; refactor custom code if needed.
9. Plan backup and rollback: Ensure you have fresh, tested backups and a clear rollback path.
10. Schedule and communicate: Apply the PHP change during a low‑traffic window and monitor logs and metrics closely.

Wrapping Up: Make PHP Versions a Controlled Decision, Not an Accident

PHP version and extension choices should never be accidental. For WordPress, OpenCart, Magento and corporate PHP applications, they define your security baseline, performance ceiling and upgrade path. Old versions like 7.4 or 8.0 linger because of a handful of plugins or modules, not because the platform itself cannot move. With a staging environment, clear extension profiles and good backups, you can treat PHP upgrades like any other planned release instead of a risky gamble.

At dchost.com we design hosting, VPS, dedicated and colocation environments with this in mind: multiple PHP versions where needed, sensible default extensions, tuned OPcache and php.ini settings, and clear separation between legacy and modern apps. If you are unsure which PHP version or extension set is safest for your WordPress, OpenCart, Magento or corporate stack, start by running through the checklist above, then align your plans with your long‑term roadmap. When your PHP layer is predictable and up to date, every other optimization – from caching and CDN to database tuning – becomes much easier to execute and maintain.