-
Notifications
You must be signed in to change notification settings - Fork 824
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 support #9665
PHP 8 support #9665
Conversation
This seems fine but also a little arbitrary. IMO it would be better to get this PR including the php 8 nightly build on travis, and surveying what else needs to be remedied. Arguably, spurious failures on the nightly line might be a distraction, but I would argue:
Since PHP 8 is only a few months away (expected Nov 2020) that seems reasonable. |
I see that some dependencies (embed at least) are pinned to ^7 support; I might try a build with ignore-platform-reqs for nightly to see how far it gets. |
4ad8980
to
0e62c63
Compare
OK I got some way with this, notes:
|
I had a few of these already covered, was planning on raising individual PRs as I made progress 😅 (TIL that I'll pull down your work and see if I can make some further headway. |
0e3f2b4
to
98ef847
Compare
@Cheddam sorry just saw this after I force-pushed with a squashed fix into the league/csv. I'll stop force-pushing now! :P |
I like the idea of this in principle, however I'm a little nervous about merging code that's not the subject of a test run. Which leads you to "add a PHP 8 build as part of the merge" which in turn leads to "fix all the PHP 8 failures before merging" :| One way out that would be to configure a PHP 8 build that has some stuff disabled, and then re-enable some things in subsequent PRs that fix it. Sometimes that's easier said than done, though. |
I think it'd make sense to merge a PHP 8 build marked to ignore failures, and then iterate on getting it green across multiple PRs. The key thing we want to ensure is that we're not breaking builds for older PHP versions in the process of fixing them for PHP 8. Worst case, a 'fix' for PHP 8 doesn't quite hit the mark in a way that isn't clear from the change in build failure, and we take another crack at it. I'd be pretty stoked if we manage to ship support by November 26th / CMS 4.7.0, but I don't think this single PR should remain open until we do - it risks getting into rebase hell. Let's see how far we get in the next few days. If there's no light at the end of the tunnel, I suggest we mark the PHP 8 build as ignored, get this PR reviewed and merged, and iterate from there. |
FYI I'm looking into a PHP 8 compatible version of PHPUnit 5.7 here http://github.com/sminnee/phpunit Will publish as sminnee/phpunit, replaces phpunit/phpunit, once it's working. Same thing I did for phpunit-mock-objects. |
To be honest I think with that forked version of phpunit and leaving --ignore-platform-reqs in place we'll be pretty close to a passing build. The changes already in this PR will need a solid review, but I don't think it's as big as it otherwise might be. |
OK, with the forked and patched version of phpunit, we're down to just a handful of failures: Deprecated methodIt looks like this is disabled by default in PHP 8 so can probably only run libxml_disable_entity_loader if PHP_MAJOR_VERSION < 8. SilverStripe\Core\Tests\ConvertTest
Different tokens in parsed codeI believe this is what you were working on. Check out the i18n text collector too - it might have its own implementation/ SilverStripe\Core\Tests\ObjectTest
SilverStripe\i18n\Tests\i18nTextCollectorTest
Different behaviour when classes don't existMy guess is that non-existent classes throw some different kind of error / result in the Reflection system,. SilverStripe\Core\Tests\ClassInfoTest
SilverStripe\ORM\Tests\DataListTest
|
Given the above, I don't think we need allowed-failures to merge this – I think we can probably get it over the line? |
Yep, sounds sensible - unfortunately I was fighting my PHP 8 testing environment this evening so didn't make any further inroads, but can help tackle the remaining items over the next few days. Exciting times, thanks for getting stuck in on this! |
Lol Travis is my PHP 8 env! ;-) If you get a shareable vagrant or docker based environment running id definitely be interested :-) |
Seems that PHP 8 builds on Travis have ceased to function for the time being 😞 (some context here) Once they're operational again, I'll be keen to see whether we're green after the last few patches I pushed up. |
Fair enough. Although... I think '8.0snapshot' is probably the better build to run with if it's available. |
It looks like |
378db4a
to
47973f5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve this, but I've been heavily involved in its development ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good and it's exciting to see PHP 8 support being added to the 4.x line.
It's a shame we can't just upgrade to PHPUnit 8, but there has been some work to the ss-upgrader tool to add an easier upgrade path for that in SS-5.
src/Control/Middleware/ConfirmationMiddleware/HttpMethodBypass.php
Outdated
Show resolved
Hide resolved
One thing to highlight for @silverstripe/core-team I added a prefer-lowest build to this PR and identified a few places where we lie about our requirements:
So I've updated the composer requirements. Because support hasn't worked for 2 years and 18 months respectively, I think this is okay but wanted to highlight it as part of the review of this PR. Alternatively we could look to fix these two areas so the older packages can still be used, but I think that's probably overkill. |
Looking good except for some failures with CSVs in the 7.1 build (--prefer-lowest) probably like some of the other dependencies we actually rely on a more specific version than we declare |
579184e
to
338b2db
Compare
💚 |
Shall we remove "WIP" from the subject Garion or is there still more tidyup you want to do before the next round of review? |
Happy with the contents; I'll tweak the commit structure a bit first now that it's green, and then drop the WIP 👍 |
Throws errors in PHP 8
Hopefully this has better PHP 8 support.
This provides 5.7.28 with fixes for PHP 8 support.
This build will ensure that older versions of packages that we claim work with silverstripe/framework do, in fact, work. ‘Composer install’ changed to ‘composer update’ as that’s what’s being executed in the absence of a composer.lock, and better clarifies intent. Note that: * Support for nikic/php-parser ^2 was lost in 25759ff. * Support for monolog/logger < 1.16 was lost in 7ab55a4
This maintains support for embed 3.0.0.
338b2db
to
85252ca
Compare
This PR introduces a
nightly
build, representing PHP 8, and achieves baseline support for it in framework. This is the first step towards shipping full PHP 8 support in core, which we hope to ship with CMS Recipe 4.7 around the same time that PHP 8 goes stable.Notable changes
(Commentary by @sminnee)
These are necessary to get PHP 8 working but are worth bearing in mind by reviewers:
league/csv
now supports both version 8 and 9, instead of just version 8. this means that unless a user has specified that they need version 8, they may upgrade to version 9 as part of an update. IMO not technically a breakage but might be worth listing in upgrade notes. If people haven't pinned a requirement but have made direct use of this package (bad practise, but people might do this) then their code might break.Note also that in this initial PR, on PHP 8 we are running composer with
--ignore-platform-reqs
. Before removing this all dependent packages will need to release an official PHP 8 version. However, as long as our tests pass, this shouldn't block merge. I'd suggest that we stand up a PR that removes this after merging this, and see what's required to get it installing.Fixes #9666
Fixes #9667
To do: