Why Exponential supports PHP 7.4 #

This page is for site owners, administrators, hosting companies and developers who run, or must run, Exponential on PHP 7.4, and for anyone who wonders why a project that supports PHP 8.5 on the day it appears also goes back to a PHP version that its makers stopped supporting in 2022.

Supported: PHP 8.0 to 8.5. Usable without support: PHP 7.4 (Exponential 6.0.15 and later).

"Without support" means: the software is designed to be usable on PHP 7.4, but the project gives no bug-fix or security commitment specific to PHP 7.4, you use it at your own risk, and the features that need PHP 8 are not available there.

The supported versions stay PHP 8.0 to 8.5, and the newest PHP stays fully supported; usability on PHP 7.4 is added below them, not instead of anything.

Contents #

1. In short
2. Who it is for
3. What works on PHP 7.4 and what needs PHP 8
4. How it works
5. A short history of PHP support in Exponential
6. Why the project does this
7. How security is kept
8. The honest trade-offs
9. The end-of-life stance
10. Installing on PHP 7.4
11. Related pages

In short #

Who it is for #

Using Exponential on PHP 7.4, without support, is for organizations that want a current Exponential but cannot change the PHP version of the machine it runs on yet. In our experience they are rarely careless; they are usually bound by something outside their control:

• Hosting contracts and managed platforms. A shared or managed host decides the PHP versions it offers, and a contract may run for years.
• Long-term operating system releases. Distributions with long support periods shipped PHP 7.4 as their standard PHP: Debian 11, Ubuntu 20.04 LTS, and the php:7.4 stream of Red Hat Enterprise Linux 8 and its rebuilds. Organizations with extended support contracts for these systems receive patched PHP packages from their vendor.
• Certified and audited environments. In the public sector, health care, finance and industry, a server image may be certified as a whole. Changing PHP means a new certification, planned months ahead.
• Remote, offline and low-bandwidth sites. An installation in a remote office, on a ship, in a research station or on a network without Internet access is updated when someone can get there.
• Other applications on the same server. A server that also runs software which only works on PHP 7.4 cannot move until that software can.

For all of them the choice used to be: stay on an old Exponential with known bugs, or wait. Now they can run the current release, with its fixes and features, and move to PHP 8 when their circumstances allow, without moving Exponential again at that moment.

What works on PHP 7.4 and what needs PHP 8 #

The kernel (everything in kernel/ and lib/) and the extensions shipped with it (ezjscore, ezoe, ezformtoken, expservices, expimageeditor, exphelpsite) run on PHP 7.4. For the extension packages and servers, the table shows the oldest PHP each one needs. "7.4 (older release)" means Composer installs, on PHP 7.4, the last release of the same line that still runs there; on PHP 8 you get the newest one.

Nothing in this table fails silently with a white page. A package that cannot run on your PHP is simply not installed by Composer, and the one server that would need PHP 8, Velocity, says so:

$ php bin/php/console exp:velocity start
the Velocity engine (qbix) needs PHP 8.0 or later, this is PHP 7.4. Exponential runs on PHP 7.4 with Apache or
nginx and PHP-FPM, or with the php engine (exp:velocity start --engine=php)

How it works #

Three pieces make one code base run from PHP 7.4 to PHP 8.5.

1. The kernel is written for the oldest supported PHP. Every PHP file must be valid PHP 7.4: no union types, no nullsafe operator, no match, no named arguments, no constructor property promotion, no enums, no readonly. Typed properties and arrow functions, which PHP 7.4 introduced, are fine. A newer function is used only behind function_exists() or through a polyfill. The rule is checked by make lint74-all and by a PHP 7.4 job in continuous integration, which lints every file, installs the production dependencies with Composer on PHP 7.4 and loads every kernel and extension class.

For 6.0.15 this meant: the namespace Exponential\View\Kernel\Class became Exponential\View\Kernel\ContentClass (class is a reserved word before PHP 8.0; the old name still works through class_alias), a few Type|null parameters became ?Type, three nullsafe operators became plain checks, mixed disappeared from two magic methods, and a few runtime differences got a fallback: WeakMap (8.0) falls back to SplObjectStorage, a GD image is a resource on 7.4 and an object on 8, a cURL handle must stay open until its last use, and ZipArchive::setMtimeName() exists only from 8.0.

2. Polyfills fill in the functions. symfony/polyfill-php80 and symfony/polyfill-php81 define str_contains(), str_starts_with(), get_debug_type(), array_is_list() and the other small functions added in PHP 8.0 and 8.1, on the PHP versions that lack them; on newer PHP they do nothing. lib/phpcompat.php covers the few the kernel needs beyond that.

3. One metapackage per PHP range. The kernel's composer.json requires se7enxweb/exponential-php-floor at ^1.0. Each version of that metapackage belongs to one PHP range and requires the packages that run there:

Composer always installs the highest version whose PHP requirement the running PHP meets. The result: the same composer require se7enxweb/exponential (or composer create-project of a skeleton) gives a complete, consistent installation on every supported PHP, and nobody has to know which extension needs which PHP. The source of the metapackage is se7enxweb/exponential-php-floor; its README lists each version.

The technique is not new to the project: the Exponential Platform DXP 4.6 line uses the same kind of metapackage, se7enxweb/exponential-platform-dxp-php-floor, to select maintained forks of its libraries on older PHP versions.

A short history of PHP support in Exponential #

The step to PHP 8.1 in 6.0.8 was right at the time: it let the project clean up years of PHP 5 and PHP 7 code quickly. Once that work was done, the same review showed that very little of the kernel actually needed PHP 8. Only a handful of language features stood between the code and PHP 7.4, so going back cost days, not months. That is why the supported floor came down to 8.0 in 6.0.15, and the software was made usable, without support, on 7.4.

Why the project does this #

Exponential grew out of a content management system that organizations have run for more than two decades. Many of them still do. The engineers at 7x, who maintain Exponential, have spent most of that time helping such organizations, and they have seen the same pattern many times: a site is not held back by a lack of will, but by a contract, a certification, a platform or a budget cycle that nobody on the project can change this year.

The project's values follow from that experience:

• Meet people where they are. Software that only runs on the newest platform helps the organizations that need help least. Keeping the software usable on an older PHP version, even without support, lets the others take part, get the current fixes and features, and plan their own move.
• Separate the application upgrade from the platform upgrade. Changing Exponential and changing PHP at the same time doubles the risk. With PHP 7.4 support, a site first moves to the current Exponential on the PHP it has, and later moves to PHP 8 with an application that already runs there. Each step can be tested and rolled back on its own.
• Never trade the future for the past. Supporting PHP 7.4 does not hold back PHP 8.5: the newest PHP is supported from its first release, and every feature that needs PHP 8 is still built. The old version is carried by a small set of rules and tools, not by giving anything up.
• Be honest about the cost. Older PHP has real drawbacks. This page names them instead of hiding them.

How security is kept #

Exponential on an old PHP is only as safe as the whole stack, and on PHP 7.4 that stack is unsupported. This is how each layer is kept safe.

PHP itself. The PHP project ended security support for PHP 7.4 on 28 November 2022. Run PHP 7.4 only where someone still fixes it: the PHP packages of an operating system with long-term support (for example Debian LTS or extended support, Ubuntu Pro, or the PHP 7.4 stream of Red Hat Enterprise Linux 8 and its rebuilds within their support periods), or a host that backports security fixes. An unpatched PHP 7.4 downloaded from somewhere is a risk no application can remove.

Exponential's own code. The kernel is one code base for every PHP version. Security fixes go into it once and reach PHP 7.4 and PHP 8.5 alike, although the project makes no commitment specific to 7.4; there is no separate, older branch that could fall behind.

Dependencies. Composer's security blocking stays on: Composer refuses package versions with known security advisories during resolution, on every PHP version. The metapackage only selects versions that Composer accepts. Where an upstream library dropped an old PHP version before fixing a vulnerability, the project maintains patched forks of the last compatible line (the approach already used for the DXP 4.6 line, for example for Twig 3.11 and graphql-php 14.11) instead of pinning a vulnerable release.

Extensions. On PHP 7.4 a few extensions are installed in the last release of their line that still runs there. These releases are days or weeks older than the newest ones, not years; when a security fix lands in such an extension, the project publishes a release of that line for PHP 7.4 too, or a new version of the metapackage that requires it.

Polyfills. The polyfills come from the Symfony project, are widely used and are maintained independently of Exponential. They only add functions; they change nothing on PHP versions that already have them.

The honest trade-offs #

• Fewer features. Velocity, Layouts, two-factor authentication and the other packages in the table are not available on PHP 7.4. For many small and medium sites that is acceptable; for others it is the reason to move to PHP 8 first.
• Older extension releases. Some extensions are one or a few releases behind on PHP 7.4.
• Less testing. The full test suite runs on PHP 8.1 to 8.5. On PHP 7.4 the continuous integration checks the syntax of every file, a production install and the loading of every class. The project's own test runs on PHP 7.4 use PHPUnit 9.6, the last PHPUnit for PHP 7.4, which does not read the PHP 8 attributes some tests use.
• Slower PHP. PHP 8 is faster than PHP 7.4, often by a wide margin with OPcache and the JIT. A busy site gains speed from the move alone.
• Security depends on your vendor. See above: an unpatched PHP 7.4 is a risk no application can remove.

The end-of-life stance #

Usability on PHP 7.4 is a bridge, without support. It exists so that organizations can run a current Exponential while they prepare their move to PHP 8. The project's commitments:

• Usability on PHP 7.4 is not removed in a patch release. When the time comes, it is announced in the changelog and in this documentation at least one release ahead, and the release that removes it says so in its notes.
• The deciding factor is security: as long as maintained, patched PHP 7.4 packages are widely available from operating system vendors and the dependencies can be kept free of known vulnerabilities on PHP 7.4, the bridge stays.
• The newest PHP is never dropped or delayed to keep an old one.
• Every site on PHP 7.4 should have a plan to move. The PHP upgrade runbook shows the steps; with Exponential already current, the move is a change of PHP and a composer update, nothing more.

Installing on PHP 7.4 #

1. Check the machine with 2. Requirements: PHP 7.4 with the required extensions for the web server and the command line (the same version and extensions in both).
2. Install the 6.0.15 line, as on any PHP version (chapter 3). Run Composer with the PHP 7.4 that will serve the site, so it selects the PHP 7.4 packages.
3. Serve the site with Apache or nginx and PHP-FPM, or with exp:velocity start --engine=php for a quick test.
4. When the machine moves to PHP 8, run composer update with the new PHP: Composer moves the metapackage to the version for that PHP and installs the packages that were left out.

Related pages #

• 2. Requirements: every PHP version, extension and setting
• Operating system support
• PHP 8.0 support: the fallbacks for PHP 8.0, which PHP 7.4 shares
• Supported PHP versions: the rules for code and extensions
• PHP upgrade runbook
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.