-
Notifications
You must be signed in to change notification settings - Fork 142
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
PHP 8.4 #2233
Comments
I have the same problem with all my Omeka plugins, that i don't maintain a lot since the release of Omeka S seven year ago. So for me the best solution will probably be to put all my Omeka 2 plugins in archive status soon. |
I think for both platforms we're likely to mask the deprecation notices in at least the first releases that will have official 8.4 support, so to begin with there shouldn't be changes required from modules on the S side or plugins on the Classic side... but I'll have to do some work on seeing what exactly that's going to look like. I'll update here when I have a more solid handle on what we're doing. |
8.4 adds deprecation notices on all methods that use a null default but don't have a question mark in their typehint, which was/is a very common pattern. Here we also have the problem that the question mark for typehints requires PHP 7.1 or greater and the current Omeka Classic support range goes back further than that. We'll eventually increase the minimum and make these changes, but will probably maintain the E_DEPRECATED block at least for a while, as there's many plugins out in the world with this problem and a low likelihood of getting fixes. (see omeka/omeka-s#2233)
8.4 is in its RC cycle and there seem to be a couple changes that are going to be annoying for us, in particular one that deprecates all usages of typehinted parameters in arguments that have null as a default, those are now supposed to have a question mark on the typehint to explicitly say the parameter is nullable.
It's not a problem for us to fix our own usages: the necessary version to add nullability is 7.1, well under our requirement, and there's a good autofixer for this from php-cs-fixer we can use.
The problem is going to be dependencies: this problem exists all over the place in Laminas code for example (and probably other dependencies), and some packages haven't yet been updated. We'll keep an eye out on that as those will probably fall into place as the release gets closer or soon after. The bigger issue will be that we'll likely have to increase our own minimum version to be able to update to these... 8.1 or higher is likely to be necessary to pull in new versions of things, up from our current 7.4 requirement.
The 8 series is quite widespread so it's probably not a huge issue, but I don't love dropping multiple versions of support in what would be a minor release for us. Particularly if we're approaching our own release and we don't have fixes in hand from all dependencies, we may instead have to look at adjusting error_reporting to exclude deprecations temporarily.
The text was updated successfully, but these errors were encountered: