shootify's picture

Hi there, i am on a need of update the PHP Version of my Proxmox LXC (turnkey-ngnix-php-fastcgi 17.1.1)  from php 7.4 to 8 or 8.1, any guide to follow? help is much appreciated. 


Jeremy Davis's picture

There are a few threads here covering how to upgrade PHP (e.g. here, here &/or here).

They're all a little dated, but the theory remains the same. The only differences should be the Debian code name (i.e. v17.x is based on Debian "bullseye" - so mentions of "buster" (basis of v16.x) should be replaced with "bullseye" - for other Debian codenames, please check the TurnKey Debian doc page).

The other thing (obviously) is the PHP version. Debian Bullseye has PHP7.4. Even though using PHP 8.0 is an option, unless you have reason not to, I recommend just using 8.1.

Sorry that it's not a nice concise answer with clear step-by-step instructions as I might have hoped. I have been hoping to put some time aside to build a tool to make changing PHP versions easy, but I just haven't had any spare cycles lately.

shootify's picture

thanks so much for your hard work. 

Jeremy Davis's picture

Thanks for your kind words ;)
shootify's picture

Hi Jeremy, I have been using espocrm container V16, i also been updating this app quite often with no problems, however few months ago the V7 of espocrm required php 8 or later which i did update, (8.1) however yesterday i update to the latest espocrm 7.3.5 and it broke my nstance... checking the server log it gives an error with php 7 which i though i uninstalled prior installing php8.1, in i run Php --Version it shows version 8.1.5 so i dont know whats going on. can you help? 

[Sun Jan 15 17:35:18.400046 2023] [php7:error] [pid 829] [client] PHP Parse error: syntax error, unexpected ')', expecting '|' or variable (T_VARIABLE) in /var/www/espocrm/vendor/laminas/laminas-mail/src/Protocol/Smtp.php on line 329

[Sun Jan 15 17:47:16.283948 2023] [php7:error] [pid 830] [client] PHP Parse error: syntax error, unexpected ')', expecting '|' or variable (T_VARIABLE) in /var/www/espocrm/vendor/laminas/laminas-mail/src/Protocol/Smtp.php on line 329

please let me know if you can help...

PS: Would be awesome if you somehow include Php V upgrade on defcon... for an easy way.... (asking too much probably)




Jeremy Davis's picture

My guess is that you installed newer PHP, but haven't enabled it (and default PHP - v7.4 - is still installed and enabled).

There's no harm done leaving the current PHP installed, but obviously,. the point of installing it is to use it!

In the case of Apache, you can check either by checking what Apache modules are enabled:

apache2ctl -M | grep php

That shows me that I have PHP7.x enabled:

 php7_module (shared)

You can also peek inside the /etc/apache2/mods-enabled directory:

ls -l /etc/apache2/mods-enabled/ | grep php

That shows that PHP 7.4 is enabled:

lrwxrwxrwx 1 root root 29 Jan 15 21:19 php7.4.conf -> ../mods-available/php7.4.conf
lrwxrwxrwx 1 root root 29 Jan 15 21:19 php7.4.load -> ../mods-available/php7.4.load

To disable PHP 7.4 and enable PHP 8.1 (note this requires that the libapache2-mod-php8.1 package is already installed):

a2dismod php7.4
a2enmod php8.1
systemctl restart apache2

Note that the same applies to disabling/enabling alternate versions of PHP - just disable the currently enabled version and enable the relevant desired version (after installing the relevant libapache2-mod-phpX.Y package).

You didn't mention PHP via CLI, but I'll mention that too as it may be important if there are CLI instructions/steps.

Checking what version is enabled is super easy:

php -v

Should show something like this:

PHP 7.4.33 (cli) (built: Nov  8 2022 11:40:37) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.33, Copyright (c), by Zend Technologies

To update to use PHP8.1 (requires that php8.1-cli is installed):

update-alternatives --set php /usr/bin/php8.1
update-alternatives --set phar /usr/bin/phar8.1
update-alternatives --set phar.phar /usr/bin/phar.phar8.1

Hopefully that helps?!

And finally:

PS: Would be awesome if you somehow include Php V upgrade on defcon... for an easy way.... (asking too much probably)

I agree. I spent a fair bit of time over my "holidays" working on a tool like that. I have got part of the way there, but still have lots to do and not 100% sure when I might get back to it, but it is the goal!

shootify's picture

Hello Jeremy, thanks so much for your help, i fixed running the commands you posted. i am not a very savy when it comes to this, so i appreciating all your help. just got some more questions regarding this:

1- how to completety remove/uninstall the previous version of php in this case PHP7.4

2-should i uninstall old version first before upgrading to new php version? (as you mentioned it might not required?)in case in the future if going to upgrade to php 8.2, (somehow php is getting a lot of upgrades lately). 

Once again THANK YOU SO MUCH. 


Jeremy Davis's picture

You could try removing old versions - but it may break things and/or pull in alternate packages (which you likely don't want/need either). That is because of other packages in the system.

For example, if you try to remove php7.4-mysql, that will want to install php-sqlite3 & php7.4-sqlite3. If you dig in a little deeper, that is because Adminer depends on php-mysql or php-sqlite3 - so if you remove one, it will want to pull in the other. Another workaround to remove the php7.4-mysql package, is to replace the php-mysql package from Debian, for the one from But if you install the php-mysql package from, that will depend on the latest PHP version - so currently, will pull in php8.2-mysql.

In apps that we provide that include a newer PHP version, I work around that by building a local dummy php-mysql package (that depends on the relevant php version mysql package). You could do that too if you wish, but personally, I think that you are better off, just leaving it be (i.e. leave php-mysql & php7.4-mysql installed).

As an aside, one thing I have been pondering is whether providing a heap of new TurnKey repos, purely for resolving this issue, is a good path forward or not? My thought is to provide PHP version specific repos (e.g. one each for PHP8.0, PHP8.1, PHP8.2, etc), which just contain simple meta-packages that depend on the specific relevant library version. E.g. in the PHP8.0 repo, there is a php-mysql package that depends on php8.0-mysql, etc. That would probably be the "right" way to do it, but it will also add additional maintenance overhead for us; plus there may be some other side effects that I haven't yet considered.

PS it looks like Debian are aiming to include PHP8.2 in their next release, so TurnKey v18.x (later this year hopefully) will likely have that as default PHP version.

Add new comment