-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support PHP8.2 #32595
Comments
8.2 support on server is tested in #32463 |
phpseclib/phpseclib#1808 This fix on phpseclib side is needed for 8.2 support. |
Nextcloud 25.0.1 seems to work fine on PHP 8.2.0 RC 6. Will support for PHP 8.2 be officially enabled in the upcoming 25.0.2 or 25.0.3? PHP 8.2 release is planned for 24 November 2022. |
No, PHP 8.2 support should come with Nextcloud 26 most likely. We need to bump several dependencies and adapt our code to make it warning-free before we officially support 8.2. |
Currently missing:
|
(moved up to ticket description) |
I think this has to be changed on the master branch to allow apps to start testing against PHP 8.2: Line 37 in d635d58
|
For the Arch Linux users coming here see https://wiki.archlinux.org/title/Nextcloud#Migrating_to_php-legacy |
Currently you can also easily downgrade from PHP8.X to PHP7.4. After that everything should work again. From most instructions# From most instructions on how to install Nextcloud
sudo apt update && apt upgrade -y
sudo apt install apache2
sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt update
# and so on Downgrade 8.X -> 7.4Then you can simply downgrade by manually removing PHP8.X and then manually installing PHP7.4. sudo apt-get purge php8.
sudo apt-get autoclean
sudo apt-get autoremove
sudo apt -y install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt -y install php7.4
php -v Result:
Other PHP7.4 Packagessudo apt-get install -y php7.4-cli php7.4-json php7.4-common php7.4-mysql php7.4-zip php7.4-gd php7.4-mbstring php7.4-curl php7.4-xml php7.4-bcmath Source:
@szaimen This makes issue #36148 moot. However, it would still be really handy if Nextcloud supports the new PHP versions. |
@Niffecs PHP 7.x is EOL and should not be used, latest Nextcloud runs just fine on 8.1. |
Here's what i do when i have a server running PHP 8.1 & PHP 8.2. I just change it so it runs on 8.1. then once its supported change it back to 8.2
|
Debian Bookworm just moved to PHP 8.2 and started dropping PHP 8.1 packages/modules, like APCu. Would be great to have PHP 8.2 support with NC26 enabled. |
I adjusted the
sed -i 's/>= 80200/>= 80300/' /var/www/nextcloud/lib/versioncheck.php I looped through the whole web interface and all apps and didn't face any Nextcloud or PHP error/warning, not even any deprecation warning so far 👍. Of course CI needs to be migrated before it can be officially supported, but as a workaround and for testing I'll stay with this now. Did anyone of you face any actual issues with PHP 8.2 so far? Will report if I do. |
I had to upgrade to 8.2 because debian removed 8.1 packages and I couldn't go back, so this was the emergency solution. Works fine. |
for nextcloud 24/25 wrote an easy temporary fix that disables php version checking. everything works stable on nextcloud 24.0.10 and 25.0.4 . just replace versioncheck.php file in /nextcloud/lib/ directory. https://github.com/meizuflym/nextcloudversioncheckfix/releases |
part of the software does not work on nextcloud 26 rc1. for example the owncloud music app. |
I wouldn't completely remove it. Use scalpel instead of hammer: sed -i 's/>= 80200/>= 80300/' /var/www/nextcloud/lib/versioncheck.php |
Well, I actually did it with a margin for the future, for the next versions of php so that there are no questions about what to do when let's say php8.3 comes out. technically this will solve the problem forever. |
That is exactly the reason why I'd use the above method. Only because Nextcloud 25 runs with PHP 8.2, doesn't mean it (or even Nextcloud 26) runs with PHP 8.3. That check has some reason, and should be hacked only for a very specific NC+PHP combination, where it is known that it works, especially when posting it online for others to follow. |
I have tested nextcloud 24 and nextcloud 25 with php 8.2 and I can say that it will work with 8.3 with 80% probability, because it is just a continuation of php 8.x, it does not have many differences from php 8.1 or 8.2. the difference between php 7.x and php 8.x is much bigger, but it still works. For the most part, they only add new functionality and commands, and do not remove and break old functions. in nextcloud 26, it was not the new version of php that broke compatibility with some of the software, but the developers of nextcloud. I added the ability to work with php 8.2 and higher on nextcloud 24/25, if developers need to cut out part of the functionality for this, I'd rather use this way of working. |
I'm not sure what problem you aim to solve by completely removing the PHP version check. The only reason where it can be required, is when you are on Debian Bullseye (PHP 7.4) with Nextcloud 25 and want to upgrade to Debian Bookworm (PHP 8.2) with Nextcloud 26, which isn't possible with either an intermediate PHP version via custom compiling or 3rd party repo, or hacking the PHP version check. The letter is the quicker and possibly cleaner solution, but the goal is to do the change as minimal as possible, only to immediately upgrade Nextcloud (making the patch obsolete), to minimise the risk of unexpected misbehaviour.
Manipulate your own Nextcloud instances and run them with any unsupported PHP version you want, but do not encourage others to do the same. It may or may not work fine in your particular case (did you have a look into your webserver, PHP, database and Nextcloud logs to know whether really everything works so fine?), but this also depends on the used apps and features, and we cannot know for sure how every part of core and apps' code reacts to it. This sets such Nextcloud instances an all data they host at risk. Every "developer" who needs/wants to bypass the PHP version check knows how to do it and does not need publicly shared patches. Those who think they need them, are more likely unaware of the risks and implications and hence should not use them. |
I offer people a working solution. if they want, let them use it. developers do not offer such a solution. this is some variation. By way, nextcloud 26 I also screwed the solution of problems with software compatibility. it turned out to be banal funny, it was necessary to add 1 file to /nextcloud/lib/public/AppFramework/Db/ and it all worked. take the Mapper.php file from the latest nextcloud 25 along the same path, and transfer it to nextcloud 26. all software that requires this file starts working normally. |
Please just read through #34692 (Changes for developers & admins in NC26). Your mapper issue is explained there (#34490). This framework has been deprecated since version 24 and has now been removed with NC26. You can migrate your non working apps to QBMapper instead of using a file which will not be provided with security fixes in the future and can lead to unexpected behavior. |
I tried to transfer the OwnCloud Music application to QBMapper, it cannot work with it. if it works, don't touch it. Yes, and what prevents me from taking this file not from you, where it is not supported from some kind of fright, but from OwnCloud developers? from their git repo to be exact. |
So, I have a bit of a problem here. nc26 doesn't support PHP 7.4. I tried the alteration to versioncheck above, just so I could at least get far enough to run the updater, but it throws a Having a situation where there's no legitimate way to upgrade between versions is absolutely astonishing. |
sed -i 's/>= 80200/>= 80300/' /var/www/nextcloud/lib/versioncheck.php did not work? It did just work for me yesterday 🤔. |
Both changing it to 80300 and commenting out the entire PHP 8.2 >= section threw the same preg_match() error (well, a server error, but that error is what showed up in the apache logs ― it throws the same file no matter what page or endpoint is accessed on the instance)
Which is the preg_match() in this section, from the last block of that file.
|
And it immediately works as fast as you revert the change in |
Yes, it goes back to the PHP 8.2 warning if I revert the change. The change to versioncheck.php makes no difference while running PHP 7.4. The section of code that throws the error is unrelated to versioncheck, or the changes I've made to it. It's likely that this section of code does, legitimately, have an issue with PHP 8.2 while running nc25. Unfortunately, my PHP is limited, so I do not have the ability (or time really) to bughunt that. Which is kinda why there needs to be a legitimate way to upgrade from nc25 to nc26 under PHP 7.4, or an official upgrade script that can bring nc25 to nc26 under PHP 8.2. Because at the moment, the admin control panel falsely just tells me that I have the latest version of nextcloud. At v25.0.7. This isn't a case of "it's new and hasn't been rolled out to all installs yet", nc26 has been around since March. Even nc27 is out now. Instead of showing some "you're on PHP 7.4 and need to be on PHP 8+ to upgrade" messaging, it just... does nothing. The This... ain't great. |
An upgrade path would have been nice indeed, was all discussed before NC26 release, when drop of PHP 7.4 was announced (now it is too late for such change). It was not seen as sufficiently important (or more a distro/admin issue providing/using such ancient and EOL PHP) for too many devs and users and too few of us (including me) were pointing out exactly the problem you face now. This is why I instead wrote the HowTo, and that worked for many users.
Right, a code section which is not executed if the version check fails. However, you are the first one (AFAIK) which reports this error, so it is not a general issue with PHP 8.2 but an issue with your particular PHP 8.2 build, or a linked library. Check out this StackOverflow question with the same error on the same function with PHP 7.4, solved by upgrading |
tl;dr: I fixed it myself. Original post below. I appreciate you going to dig this out, but like I said, this error was not occurring while running under PHP 7.4. The changes to versioncheck have no effect while running under PHP 7.4. The issue is in running nc25 under PHP 8.2 in order for it to let me upgrade to nc26. As such, a fix for this error under PHP 7.4 won't fix my issue. For the avoidance of doubt, I did upgrade libpcre2 (all packages) anyway, but it made no difference to the error's occurrence under PHP 8.2 ― I believe libpcre2 was already at a version above the one which was causing errors for the users in these threads (you'll note that the other fix offered up in those threads, and others for the same error, is "upgrade PHP 8", which, lol). Pre-Post Edit: I spent hours just upgrading everything I could short of a dist-upgrade, fixing broken upgrades, conflicts, dependencies, blah blah blah. It still throws a 500 error. It just no longer shows anything for it in the apache logs (logs are working, it'll generate entries for access and other errors). ...however, after digging around in the install directory by myself, I found that you can just call /updater/ directly and provide the secret. Which works under PHP 8.2 even without the versioncheck modification. ... :-| |
The linked issue was just an example from where this error could come from. Applying all available distro packages, then restarting PHP, is generally a good idea to try fixing such issues. The Great that the PHP issue was solved by upgrading to NC26. Someone in the forum posted that he was able to upgrade from Debian Bullseye with NC25 to Debian Bookworm with NC26 as well without hacking the Second thing is that the
However, I never got or saw anyone getting the update offered as long as PHP 7.4 is used, so that only the second option is possible. @McCovican do you remember if you got the update offered while still being at PHP 7.4? |
I appreciate the sentiment, but the number of times I restarted apache etc. switching between 7.4 and 8.2 kinda rules that out as a factor, heh. My issue here could've been avoided by clearer signposting that the self-contained updater would be accessible outside of the admin panel while on PHP 8.2 (given that nothing else in nc25 worked while on PHP 8.2, it wasn't exactly obvious that the updater would ― it was a last-ditch effort to even try it).
No, I was not offered it, nor received any notifications about it. Which is quite dangerous in an of itself ― leading the user to believe that they are currently running the latest version of the software when they are very much not, is absolutely terrible UX and has significant security implications. There needs to be clear signposting in the admin panel that users running PHP 7.4 are limited from upgrading to nc26, and that running PHP 7.4 is the reason for that (along with clear signposting that they can access the upgrader directly while on PHP 8.2). The current notification is very, very weak and does not infer that it is causing any limitations on the upgrade path. To be absolutely clear about the "does it offer you the upgrade to nc26 while on PHP 7.4" point, I switched between 7.4 and 8.2 quite a few times while I was bughunting things. When I was on 8.2, the standalone updater failed on me (for minor issues completely unrelated to this), and I switched back to 7.4 to double-check. The updater, on refresh, immediately went from offering me nc26, to instead saying that I had the latest version. Big yikes. This was, all round, an entirely avoidable scenario with some incredibly simple UI notices and changes. |
It does warn you that you're running an out-of-date PHP version, at least. But indeed, it is probably better to still notify/inform about the NC update as well. It is prevented separately when trying to use the web updater and again when trying to do the 2nd stage afterwards. However, if there is no mechanism to prevent the update from being offered, the So optimum probably is:
However, first we need to understand in which case the update is (not) offered in the first place. |
How to use GitHub
Is your feature request related to a problem? Please describe.
PHP8.1 is the latest and greatest PHP. One day there will be 8.2 and it would be cool if Nextcloud can support it reasonably early. Not too early where it is unstable, but as soon as the support libraries are ready and there are no known issues.
Describe the solution you'd like
As a first step: have PHP8.2 nightly included in CI builds ASAP.
Later: include official 8.2 support once it's stable.
Describe alternatives you've considered
N/a
Additional context
Todo
The text was updated successfully, but these errors were encountered: