You are here
JRA - Wed, 2022/08/24 - 19:19
Hi, how would I go about updating my version of PHP to 8.x? My web host uses v8 and I don't want to build a website locally that I can't then upload to my host.
Thanks,
J
Forum:
Hi, how would I go about updating my version of PHP to 8.x? My web host uses v8 and I don't want to build a website locally that I can't then upload to my host.
Thanks,
J
You can update PHP using sury.org
As a general rule we recommend that where possible, you prefer the default libraries provided by Debian. One reason behind that is because then you will get automated security updates from the Debian Security team (which make the minimal changes whilst fixing security issues).
However, PHP version is perhaps one of the most asked for things and we get it. PHP is under relatively rapid development and the newer releases often support new features and stricter standards (both of which usually mean better performance and enforce/encourage better code standards).
Another reason why we don't recommend updating to newer versions of packages (other than from an official source, such as Debian themselves) is because you need to add third party repositories, which may or may not be reputable and trustable. In the case of PHP, we have a very reliable source! Ondřej Surý is a Debian/Ubuntu developer and maintainer, who is a member of the PHP packaging teams of both distros. So he is intimately involved in the development and maintenance of the official Debian and Ubuntu PHP packages. Thankfully, he provides a third party apt repo that is specifically aimed at Debian (so works flawlessly with TurnKey).
I do have dreams of providing a TurnKey tool that can allow you to easily change PHP versions. Unfortunately, that remains a dream for now. I did start work on it ages ago, but it stalled and other priorities have intervened... In the meantime though, it's still possible - just not very "turnkey"!
FYI, you can find lots of info how to update PHP on Debian all over the net (try googling something like "debian install php 8 sury.org"). Any/most of those should work (so long as you keep in mind the relevant Debian version; TKL v16.x = Debian 10/Buster; TKL v17.x = Debian Bullseye/11). The general process is even covered in an old post by me. However, the README.txt I refer to (in that post) has since been improved. So I'd just recommend using that now.
In an effort to make this post a little more generic (so it should work with both v16.x & v17.x appliances - perhaps even newer releases, once we get there) I'll try to write this in a somewhat generic way. Ideally I think that this should be a doc page, so I'll probably transfer this to a doc page once we've confirmed that it works reliably.
First, here is an overview of the process:
I'll go through each step in more detail below, but please keep in mind that to work, these commands all need to be run within a single terminal session (some of the earlier commands set variables that are used in later steps).
Set PHP version to install and collect current PHP version & packages
To ensure that all the same PHP modules are (re)installed for the new version of PHP, set the new PHP version to install and collect the current PHP version and currently installed packages (and generate a list of new packages to install):
Set up sury.org PHP
As I noted above, the deb.sury.org README.txt has been improved in more recent times and I now suggest just using that for the initial setup:
Install relevant new packages
Then install the new version of PHP and the relevant libraries and modules, including Apache mod_php:
First double check the modules that will be installed:
That should return a list that looks vaguely like this (the specific packages may be different as different appliances have different modules pre-installed):
Install these new packages like this:
If there are additional modules that you want to install, install like this:
Where 'module_name" is the actual PHP module name, e.g. 'mbstring' or 'curl' etc. In future shell sessions, you won't have the variable PHPV_NEW set, so just substitute the PHP version number. I.e. to install the PHP curl module for PHP 8.0:
Reapply php.ini tweaks, restart Apache and win!
The new version of PHP comes with it's own copy of the relevant php.ini file(s). You will likely want to re-apply any tweaks that you had previously applied to the relevant php.ini file(s). The new php.ini files are found at /etc/php/${PHPV_NEW}/apache2/php.ini (or /etc/php/${PHPV_NEW}/php-fpm/php.ini if used with PHP-FPM e.g. if using Nginx instead of Apache) and /etc/php/${PHPV_NEW}/cli/php.ini. Unfortunately, there isn't currently an automated or easy way to check for modifications that have been made previously. But hopefully you can work that out?!
[update] You'll also want to ensure that when you use php from the commandline, you will (almost certainly) want to use the same version of PHP as you've just installed. This may have been auto-configured by previous steps, but just in case, I suggest explicitly setting it. To ensure that you're using the right version from the CLI, run 'update-alternatives', like this:
Running the wrong version of PHP from CLI might cause issues with cron jobs (otherwise, they will likely run under the old version).
Once you've made your desired tweaks to the relevant php.ini file(s), then restarting Apache should be the only remaining step. Like this:
(Or if using PHP-FPM: 'systemctl restart php-fpm')
I hope that all "just works". Please let me know how you go with it.
Hi, I was going through this
Your data shouldn't be at risk, but good to make a backup first
Your data shouldn't be at risk, but it's always a good idea to have current backups, especially before you do anything like this. Ideally, you should have made sure that you have a current, working backup before you started! TKLBAM is a good option, although simply creating a copy of your web root and a dump of your DB are a decent "poor man's backup". Although if you care about your data, I urge you to set up an automated backup regime, ideally to a remote location.
Anyway, to create a "poor man's local backup" of Nextcloud (and data) something like this should do the trick:
When you are done and want to get rid of the local backup, just delete it like this:
Now to fix your server. Assuming that you are trying to install PHP 8.1, please try this:
Also, to ensure that you are using PHP 8.1 when using PHP via the CLI, run this:
I'll update my previous post(s) to include that update alternatives command. I didn't think of that before and It might cause issues for some cron jobs otherwise!
Hi Jeremy,
First, up. Your data should be ok!
As I noted, your data should be ok. Most of it is in the database and as PHP isn't running properly, the risk of your data getting corrupted is fairly low IMO. I do agree that your disaster plan leaves a bit to be desired, but I reckon you'll be ok this time...
So first thing is that Apache appears to just be rendering the PHP code as text, rather than processing it and rendering the resultant HTML. I suspect that is caused by you no longer having an Apache PHP module installed and/or enabled.
Before I go any further, I am working on the assumption that you are going back to the Debian defaults. To ensure that works as it should, be sure to disable the third party PHP related apt sources.list. IIRC it should be called 'php.list'. If you get errors about file not found, please double check what the right name of the file is (in /etc/apt/sources.list.d). Assuming it's 'php.list':
Then update apt sources (so knowledge of all third party packages is cleared):
Then make sure that the correct Apache PHP module is installed and enabled:
Fingers crossed, that should be it...
It just occurred to me that I didn't mention the logs that you posted at all... Sorry about that.
I covered the PHP file just being displayed (i.e. rendered as raw test, rather than processed).
The Apache log doesn't show us anything of value. The 'AH01909' warnings are just because Apache is using the servername of localhost, but doesn't have a SSL cert for that.
On face value, the Nextcloud log doesn't give us anymore info than the Apache log. Although, I did just notice that the last line might be of interest? Let me render the contents in a way that makes it easier to read:
That last bit suggests that the output has been truncated (i.e. isn't the whole output). In case you aren't aware, this is a PHP stacktrace. I'm not super familiar with PHP, but my guess is that it's just the backend details of the 50x error that the front end is reporting. I think that you need to get PHP working properly and ensure that is right before you start worrying about that too much.
Hopefully my other posts help with that...
"Internal Server Error"
Is this new?
A 50x error relates to something on the backend not responding as it should. The most common cause of that is when the front end server is simply acting as a reverse proxy and the backend server is not responding (or not responding properly). In my experience, 50x errors are uncommon when using Apache mod_php, although if there is some serious PHP misconfiguration then perhaps?
Try reinstalling and re-enabling mod_php as per my previous post. If that still doesn't work, please then please paste back with the latest from your Apache and Nextcloud logs.
I just realised that I didn't discuss the logs you posted (and actually, I didn't look at them properly). I'll update the previous post.
Jeremy, I found this
Jeremy, found this here - it solved my issue:
Thank you so much for the help. Finally I've my stuff back again. :)
Glad that solved your issue, although my guess is just one line
I'm glad to hear that that solved your issue, although the only line that should have made any difference was this one:
That enables Apache's PHP 8.0 module. So you're now using PHP 8.0. FWIW, installing the package 'libapache2-mod-php8.0' should auto enable it as part of the install process. So it should have "just worked". Obviously it didn't for you. I'm not completely sure why, but it's good to know. Perhaps we should document running that line explicitly anyway (if it happens automatically, re-running it won't cause any issue)?
Anyway, glad to hear that you are back up and running. Now go and set up backups! :)
Thanks
The php.ini is unique for each PHP version
Each PHP version has it's own php.ini file (actually, there are cli and apache php.ini files for each version). So when you upgrade PHP, you get new default php.ini files. So you'll need to update the relevant php.ini file(s) to apply your settings to the new relevant php.ini file. FWIW, the paths should be something like this:
Where PHP_VERSION is the PHP version you are using. I.e. now you have PHP 8.0, the paths will be:
Updates to the CLI php.ini should be applied instantly. Changes to the Apache2 php.ini will require an Apache restart. I.e.:
Good luck with it.
Thanks for the php upgrade fix
Fixing and Improving the script
Are you sure Marcos?
Hey Marcos. For starters, thanks for the heads up on the issue you hit.
However, it appears that the php-redis package; unlike most of the other php-<...> packages, isn't just a metapackage that depends on a phpX.Y-redis package. The php-redis package IS the package and contains the important files!
There is no php7.4-redis package?! I.e. (I included php-zip so you can see the difference):
So it appears that php-redis is an exception to the rule... But that doesn't quite align with what you've noted?
Disable previous Apache mod
Thanks for sharing your experience Ian
Thanks for sharing your experience Ian. AFAIU at least in theory, installing the newer version should automagically do all that for you. It seems that's not the case in practice.
Also, thanks for the heads up about Adminer not being supported with newer PHP. I have briefly tested it on the newer v17.x releases and it appears to work ok there (at least on face value).
Hey Jed, that right!
Awesome - Thanks Marcos
Awesome. Thanks for publishing your solution. I'm sure others will find that useful!
Add new comment