Multiple PHP versions on Nginx

The nice thing about Nginx is that running multiple versions of PHP is actually quite easy. It only takes the change of one number to switch between different builds of php-fpm in the site configuration and a different build is used. At present I'm a little stuck back on PHP7.3.33 as various things fall over in PHP7.4 and I just get a white screen with PHP8, so I need to clear the PHP7.4 niggles and get bitweaver working clean on that before then moving through 4 versions of PHP8. The more difficult bit is just building an old version that can be installed with Nginx.

The source code for PHP has been designed to be built easily and this starts with a source code package which has most of what is needed. The first stage is to build the basic package and while in the past this just worked, trying to build a clean copy of PHP7.4.33 is proving a little difficult. The xml code is throwing errors which prevent it being built so I have had to disable it at the moment. I basically start by grabbing the last of a major version build, in this case 7.4 but I may need to roll back a bit to find one that compiles cleanly. I keep the source folder tree separate to the resulting running code, so /opt/php-7.4.33 has the source code and is compiled to create a production tree at /opt/php74.

./configure --prefix=/opt/php74 --enable-fpm --with-fpm-systemd --with-config-file-path=/etc/php74 --with-config-file-scan-dir=/etc/php74/conf.d --without-libxml --disable-all

Once built, it also creates the necessary tools to build the shared extensions, which are listed in the /opt/php-7.4.33/ext directory. Not all the extensions I need are included in the base distribution, and so I have to add a couple of extra ones such as interbase to provide the firebird connection, and imagick for the power powerful graphics tools. Compiling these is relatively easy once the correct version of the phpize tool and php-config files have been created. These push to a long-winded directory path for the extensions, but that keeps the id code easily observed. It is just a matter of running the following in each required directory to create the code extensions.

/opt/php74/bin/phpize
./configure --prefix=/opt/php74 --exec-prefix=/opt/php74 --with-php-config=/opt/php74/bin/php-config
make
make install

The resulting files end up in /opt/php74/lib64/extensions/no-debug-non-zts-20190902 where the date code corresponds to the build that phpize is producing. The extensions are all tagged with that code, and the core software will fail to load any extension that does not have a matching ID.

Once we have a working set of code in /opt/php74/ then we can clone the php-fpm service code files to create a new php74-fpm service independent of the other live versions. openSUSE is currently managing version PHP8.3.19 on port 9000, and so I leave that alone, and have added services at 9073 and 9074 which are identified as php73-fpm and php74-fpm. At this stage I am not sure if I will need to add PHP8.0, 1 and/or 2 but those can easily be created if required. The obvious target is to get everything clean on PHP8.3, but there is a lot of legacy code that will have to be massaged through the often unwelcome deprecation and 'improvements' that each new version of PHP seems to 'require'. We used to be able to just add new parts to the original PHP4 code base, but very little of that code would run today?

It is not only my own code base that needs 'modernizing', all of the third party libraries also need bringing up to date and this just adds to the fun as many of these have also 'improved' the interfaces and need their own modifications to the user code. I have adbDB, smarty, ckeditor and other bits that I will need to weave into the revised framework.