Problem/Motivation
Drupal 8.8.x is not passing tests on PHP 7.4. PHP 7.4 released on November 28, 2019, a week before Drupal 8.8.0.
Proposed resolution
Fix code to not trigger errors in PHP 7.4 maintaining the same behaviour as PHP 7.0 to 7.3.
There is no release of easyrdf/easyrdf that supports PHP 7.4 in order to work around this we've done #3090017: Isolate test dependency on easyrdf/easyrdf to a single trait and then in this patch we provide a test only version of \EasyRdf_ParsedUri
that is PHP 7.4 compatible. This code is only loaded and available at test time. Hopefully a release of easyrdf will happen sometime but it's not as important because it is now a test only dependency in Drupal 9.
Follow-up issues
- #3110815: \Drupal\hal\Normalizer\EntityReferenceItemNormalizer::normalize() tries to normalize entities that don't exist
- #3110839: Use of \Drupal\Core\Database\Install\Tasks::getFormOptions() in \Drupal\migrate_drupal_ui\Form\CredentialForm::buildForm() results in confusing description for prefix form element
- #3110972: Update easyrdf library to 1.0.0
Done:
- #3090145: Ensure that mixing array and Attribute objects in theme rendering is managed properly
- #3104420: PHP 7.4 Deprecated curly brace syntax for accessing array elements
- #3104421: PHP 7.4 deprecated reverse order of glue and pieces in implode
- #3095895: FieldTypePluginManager::getPluginClass() should throw an exception when called for a field type that doesn't exist
- #2830631: Remove code that tries to use _raw_variables for route argument resolution as it does not work
- #3089764: Updating translations does not clear the JS asset cache so new translations are not loaded
- Get a new release of composer/composer including https://github.com/composer/composer/pull/8296, see comment #33. #3075785: Update composer/composer to ^1.9.1
- Update to release 1.6.8 of mikey179/vfsstream, see comment #31. mikey179/vfsstream 2.0.x-dev requires PHP 7.2, so D8.8. cannot upgrade to it. #3091225: Require-dev mikey179/vfsstream ^1.6.8 in order to support PHP 7.4
- Get a new release of symfony/validator, including https://github.com/symfony/symfony/pull/34097: #3092112: Update symfony packages to 3.4.33 before 8.8.x beta
- #3089530: Tests of copied Doctrine code are not testing what we want them to test
- New release of Typo3's phar stream wrapper and of PEAR's Archive Tar #3088853: Require typo3/phar-stream-wrapper ^3.1.3 and pear/archive_tar ^1.4.8 in order to support PHP 7.4
- PHPunit 6 does not run on PHP 7.4 so we need to upgrade it - #2950132: Support PHPUnit 7 optionally in Drupal 8, while keeping support for ^6.5 - unfortunately PHP 7.0 (still supported in 8.8.0) does not run PHPUnit 7.
egulias/email-validator
- access array on null. Solvable updating to latest version. #3039611: Update core PHP dependencies for 8.8.xmikey179/vfsstream
- use of deprecated curly brackets for array access. Solvable updating to latest version.
#3039611: Update core PHP dependencies for 8.8.x
Remaining tasks
User interface changes
None
API changes
None
Data model changes
None
Release notes snippet
Drupal [insert version] is now compatible with PHP 7.4 and testing on PHP 7.4 is part of the regular automated test suite.
Comment | File | Size | Author |
---|---|---|---|
#226 | 3086374-8.8.2-226-do-not-test.patch | 39.8 KB | nils.destoop |
#218 | 3086374-8.8.x-218.patch | 41.77 KB | alexpott |
Comments
Comment #2
mondrakeAlso see #3085735: Support PHP 7.4 in Drupal 8
Comment #4
mondrakec/p from IS of #3085735: Support PHP 7.4 in Drupal 8 to close that as duplicate.
Comment #5
mondrakeA patch to test how many failures we get after upgrading some dependencies and quickfixing some of the other code as per the IS.
Comment #6
mondrakeComment #7
mondrakeComment #8
alexpottLet's use the null coalescence operator... see https://3v4l.org/731YX.
Let's use the null coalescence operator... see https://3v4l.org/731YX.
Let's use the null coalescence operator... see https://3v4l.org/731YX.
This is unnecessary.
Comment #9
mondrakeDone #8, thanks.
No longer necessary to upgrade other packages than phar-stream-wrapper, apparently.
Added some more tweaks.
Comment #10
mondrakeMore.
Comment #11
mondrakeToo many fails, let's restrict test runs to Unit and Kernel tests and focus on that.
Comment #12
mondrakeComment #13
mondrakeThis may help - touches Element so reopening Functional and FunctonalJavascript tests
Comment #14
alexpottI don't think we should be string casting the key here... why didn't you copy the
if ($key === '' || (is_string($key) && $key[0] !== '#')) {
to the RequestSanitizer?Comment #15
mondrake#13 is down to 107 fails in total!
#14 because otherwise the entire element render is an empty string, hence the thousand of failures. If the $key is numeric we still need to render the element. Or am I missing somethig?
Comment #16
alexpottMaybe it'd be clearer as
I think that'd work without the cast.
Also PHP7.4 compatible release of typo3/phar-stream-wrapper is available... 3.1.3 yay!
Comment #17
mondrakeOn it.
Changing from plan to task, too - this seems closer now.
Comment #18
mondrakeDone #16, added more tweaks.
Comment #19
mondrakeComment #20
alexpottI think I must be missing something but I'm not sure why this type of change is needed. If the uuid key was not set we'd get an error in PHP7.3 too (as far as I know).
Comment #21
mondrake#20 did that because of
Comment #22
alexpottInteresting - so we need to code for when $system_site is FALSE here. I don't think we should be writing it here (when it is FALSE)
Comment #23
mondrakeDone #22 and trying something different with
RequestSanitizer
Comment #24
Ghost of Drupal PastYou wanted
ctype_digit
if ($peek &&)
We know it's defined, no need for the !empty wrapper.Same.
if (!$css_asset)
.Since I am nitpicking anyways why don't we
?? FALSE
. You are type coercing to boolean right after anyways.ctype_digit
After using
??
so much, why is it not used here?is_string($values['options'] ?? NULL)
?? ''
No need for
!empty
again. Just$menu &&
is enough. And since we are touching this ancient code could we please change the == to === and the != to !== please while at it?Yeah triple equals here would be nice too.
Same
?? ''
?? ''
. assertEquals IMO is a wrapper around the dreaded==
and NULL == 0 among other things. No need for that.Same
?? ''
.Comment #25
mondrakeAFK from now. If anyone wants to take this on feel free :)
Comment #27
alexpottComment #28
alexpottAnother dependency needs an update - https://github.com/njh/easyrdf/pull/311
Comment #29
alexpottThanks for the review @Charlie ChX Negyesi
1. I think is_int() here is fine - we are only concerned with integer array keys - string ones can be checked as per usual.
2. $peek can be NULL - changed to be more explicit
3. Hopefully this code can be removed it looks unnecessary.
4. Hopefully this code can be removed it looks unnecessary as well.
5. See 1.
6. Refactored as we can move the block inside the previous if.
7. Fixed
8. Fixed but didn't make the other changes. I think we should limit the changes here. Nothing unnecessary should be done.
9. I think we should do this later
10. Hopefully this change is unnecessary. Removed it.
11. Same as 10.
12. This is the same as 10.
Comment #30
alexpottThis needs more explanation - we're using link as an array later.
This needs more thought. It doesn't look right.
This one looks a bit odd. Why was this needed?
Comment #31
alexpottSo mikey179/vfsstream 2.0.x-dev fixes some of our tests. So either we need to work out what fixes this and get it backported to the 1.x branch or get a release of 2.0... fun.
Comment #33
mondrakeLooks like also Composer yet needs to release a PHP 7.4 compatibile version including https://github.com/composer/composer/pull/8296
In the meantime dev-master could do, apparently.
Comment #34
mondrakeComment #35
mondrakePatch for #33
Comment #36
mondrakeComment #37
mondrakeComment #38
xjmComment #39
alexpottOne more fix due to
Comment #40
mondrake#30 I can't remember... Let's revert at this stage and see what breaks.
Comment #41
mondrakeJust a note that mikey179/vfsstream 2.0.x-dev requires PHP 7.2 , so D8.8. cannot upgrade to it - a 1.x version upstream would be needed?
Comment #42
mondrakeComment #43
mondrakeWe also need a new release of pear/Archive_Tar fixing https://github.com/pear/Archive_Tar/issues/24
Comment #44
mondrakeBetter solution for #30?
Comment #46
alexpottWe can fix the ArchiveTar issue by letting ArchiveTar determine if the file is compressed rather than passing the compression type in.
Comment #47
alexpottThe change in core/modules/hal/src/Normalizer/EntityReferenceItemNormalizer.php is breaking \Drupal\Tests\hal\Kernel\EntityTranslationNormalizeTest so reverting and seeing which test that is "fixing" because maybe the test is wrong.
Comment #49
alexpottHMmm I was wrong in #46 - that's not enough to make the ArchiveTar issues go away. We're going to need a fix upstream.
Comment #50
mondrakeWorking on the views test failures.
Comment #51
mondrakeAddressing #50.
Comment #52
alexpott@mondrake I know using the null coalescence operator is tempting and these fixes kinda preserve the PHP 7.3 (and below) behaviour
But I'm concerned that this is our code talking to us and saying that what we think is true here actually is not - yes PHP used to continue on blindly up the garden path but we're not doing that anymore because your code does not make sense.
Like this specific thing looks like a bugfix - so do we need additional tests - is the fix correct etc...
Comment #53
alexpottWhere is _raw_variables set and not an array - that seems like a bug.
Comment #54
mondrake@alexpott you're right, obvioulsy... let's do this one more, then have a general look and start spinning off specific issues? My concern is that tests will fail if we do not use combined patches, though.
Comment #55
alexpottSo re #53 we have other places that assume _raw_variables is a ParameterBag (for example \Drupal\Core\Path\PathValidator::getUrl) - so I think we can here too. What's super interesting is that I'm pretty sure that the RawParameterValueResolver is not working at all!
Will fail with PHP Error: Cannot use object of type Symfony/Component/DependencyInjection/ParameterBag/ParameterBag as array
But we never get here because in HEAD
never returns TRUE because
array_key_exists($argument->getName(), $request->attributes->get('_raw_variables')
is nonsense.Not fixing \Drupal\Core\Controller\ArgumentResolver\RawParameterValueResolver::resolve here because I want to see what breaks. I guess nothing. We should file a child issue to fix this.
Also added an @todo to resolve
core/modules/hal/src/Normalizer/EntityReferenceItemNormalizer.php
properly. I think this is a good thing for breaking out into a child issue too.Comment #56
alexpott@mondrake see #55 interdiff... it's really helpful if you can add @todo's to the fail tests that the null coalescence operator is fixing - that we we can remove the "fix" and play around with other solutions quicker.
Comment #57
alexpottWorked on #2830631: Remove code that tries to use _raw_variables for route argument resolution as it does not work which it turns out is a blocker for PHP7.4 compatibility.
Comment #58
alexpottComment #60
mondrakeComment #61
alexpottWe have a pear release! I removed the core/composer.json updates because they're not necessary in this issue and just add noise.
I discussed this a bit with @Wim Leers who pointed out
I think the best thing here would be to add the @todo and avert our eyes. We have the same behaviour as in PHP7.3 this problem will go away when HAL is removed and at least we've added a @todo if someone takes this up in contrib.
Comment #62
mondrakeAdded @todos as per #56.
I was trying to look into the annotation parsing test failures, very obscure to me... it looks like something is wrong with the deprecation error handlers, but cannot figure out what.
Comment #63
joseph.olstadWould be great to see green soon, @Taran2L single handedly did the D7 compatibility and all tests are passing for D7. There might be some synergies with his work and the work that needs to happen in the D8 branch.
For this reason I've linked the D7 php 7.4.x compatibility issue here as related.
Comment #64
mondrakeFix for
YamlFileLoaderTest
Comment #65
joseph.olstadtypo3 depedency
Comment #66
joseph.olstadI looked at the various fails and the test code, nothing obvious at the moment. Would have to put a backtrace right before the failure and dump it to file.
My advice, crank up your memory_limit to 1024M in your php.ini
Then put in a backtrace like this somewhere right in the failed line of code core/lib/Drupal/Core/StreamWrapper/LocalStream.php on line 211
the backtrace.log file should go into the root of the D8 folder.
***BEGIN NEW NOTE***
Ah, I see from the issue description, looks like a bit of followup needed upstream still, explains most of the issues. Looks like the plan is almost complete.
***END NEW NOTE***
Keep up the great work! Almost there.
Comment #67
mondrakeComment #68
mondrake@joseph.olstad thanks - re #65 please note a separate issue to upgrade phar-stream-wrapper exists already and is RTBC, #3088853: Require typo3/phar-stream-wrapper ^3.1.3 and pear/archive_tar ^1.4.8 in order to support PHP 7.4.
Comment #69
mondrake@alexpott re #31: it looks like some PHP 7.4 compatibility tweaks are backported already to v.1.x, https://github.com/bovigo/vfsStream/commit/b4dd94960a680d02dd78fb4c282fe...
Let's see this
Comment #70
mondrakeReroll after commit of #3088853: Require typo3/phar-stream-wrapper ^3.1.3 and pear/archive_tar ^1.4.8 in order to support PHP 7.4
Comment #71
alexpott@mondrake unfortunately whatever has been backported to the 1.x branch on vfsstream is not enough :( I was going to bisect and see which commits we need backported. Just haven't got round to it yet.
Comment #72
mondrake@alexpott yep :(
Also, it looks like Composer master is still not full PHP 7.4 compliant, see the failing test
There's a waiting PR https://github.com/composer/composer/pull/8386, but I don't know if this is going to fix it
Comment #73
mondrakeAdding a fix for
ArgumentValidatorTermTest
. However I think this is not correct - thevalidator
property should be initialised beforehand. Added a @todo for a better solution.The views related failures (see the @todos) require someone knowing the ins and outs of the module...
Comment #74
mondrakeSorry ignore the patch in #73
Comment #75
mondrakeUpping
doctrine/annotations
to at least 1.7 seems to solve the annotation test failures. If this is OK then we should spin off an issue to update it in D8.8.xComment #76
mondrakeUnfortunately, doctrine/annotation 1.7.0 requires PHP ^7.1 :(
Comment #77
alexpottSo the doctrine issues shows that our copied tests from #2631202: Doctrine no longer supports SimpleAnnotationReader, incorporate a solution into core weren't copied correctly and we're not testing what we think we are. Going to split this out into a separate critical issue.
Removed composer.json changes as they're not necessary (at this point) are will only end up with the patch being in needs reroll all the time. Also moved back to vfsstream dev-master because it has fixes we need. So we need to file an upstream issue for that.
Comment #78
alexpottFiled #3089530: Tests of copied Doctrine code are not testing what we want them to test
Comment #79
alexpottPatch adds a work around for https://github.com/njh/easyrdf/pull/311 - I'm concerned that EasyRDF is not very actively maintained.
Also fixes \Drupal\Tests\migrate\Functional\process\DownloadFunctionalTest
Comment #81
alexpottMore EasyRDF fix... also need to open an issue to move that to dev dependencies as that's what it is.
Comment #82
alexpottThat EasyRDF exists already - #2901363: Move easyrdf/easyrdf to require-dev
Comment #83
alexpottPatch in #81 reverted #3088447: BuildTestBase->standUpServer always starts new server - here's the proper patch.
Comment #84
alexpott#3089530: Tests of copied Doctrine code are not testing what we want them to test has landed.
Comment #85
joseph.olstad@alexpott, nice work, only 2 fails! I believe you forgot to create an interdiff, however no worries, just easier to follow with an interdiff but not necessary, it is getting closer!
Comment #86
joseph.olstadsomething weird with the test results, I don'T see the failures, the console log is all green but there is 2 fails flagged on the results page.
Comment #87
alexpott@joseph.olstad #84 was a reroll because #3089530: Tests of copied Doctrine code are not testing what we want them to test caused a conflict - it's tricky to interdiff a reroll.
Here's a fix for the remaining fails I think. We need to update the composer binary to the snapshot channel since 1.9.0 is not PHP7.4 compatible.
Comment #88
mondrake#86 yes I noticed that too - looks like the testing infrastructure is not reporting all the fails. If you click on 'View results on dispatcher' link in the rsults page, though, the test failures are there.
#87 aha so in this case the failure is not related to composer as 'the library installed in vendor', but to composer as 'the instance used by the testbot to build the codebase'
Comment #89
alexpott@mixologic thinks that \Drupal\Core\Composer\Composer::ensureComposerVersion() is going to fail when we do the composer update properly... it's not failing locally for me... so lets see.
Comment #90
alexpott@mondrake do you remember why this is needed? Looking at drupal_common_theme()
$variables['attributes']
should default to an array.If this is necessary we should split this out into a separate issue and test. @mondrake do you remember which test you added this for.
Pondering if this is the right fix. I think maybe
elseif (is_string($library['version']) && $library['version'][0] === 'v') {
might be better. Or maybe the better fix is to ensure that version is always a string by doing$library['version'] = (string) $library['version']
somewhere. Not sure.What test caused this. It shouldn't be possible to get to the database form without have a profile selected.
This definitely looks interesting. @mondrake any idea which test caused us to need this.
It'd be great to know which test caused this to change.
This as well because it's unclear how this is not set.
@mondarke any idea about this one>? What test causes it?
This change is not needed anymore.
Same here.
It's be good to understand how $report is not as expected.
This is very smelly I'm not sure that \Drupal\Tests\locale\Functional\LocaleJavascriptTranslationTest::testLocaleTranslationJsDependencies is testing what we think it is. Yep adding
$this->assertRaw($js_filename);
to the test shows that this test is not working as we think it is. We need to file a separate issue to fix this properly.@mondrake do you know which test this was for?
Comment #91
mondrakeCan't remember them all, so I reverted #90.1, 4, 5, 6, 7, 8, 9, 10, 11 and 13 in #3065023-90: Ignore, testing issue, and will report back on the basis of the results there.
Comment #92
alexpottCreated #3089764: Updating translations does not clear the JS asset cache so new translations are not loaded
Comment #93
Berdir#90.1 It probably already is an Attributes object in some cases?
See https://3v4l.org/B4ZhS, that apparently was deprecated in PHP 7.4 (only in beta1+ in fact..)
Comment #94
mondrake#90.1: yes, sometimes
$variables['attributes']
is an object, and array functions do not operate on ArrayObjects (see #3087602-8: DeprecatedArray implements \ArrayAccess, traversals not possible and 9. The current fix is not secure, either. I would suggest to do this, instead#90.8: this is basically breaking ALL the Functional and FunctionalJavascript tests with something like this:
More to come...
Comment #95
alexpottFiled upstream fix for #90.8 - see https://github.com/symfony/symfony/pull/34097
Comment #96
Ghost of Drupal PastWhat about adding
No more guessing whether it's array or object.
Comment #97
mondrakeFull details in #3065023-92: Ignore, testing issue.
Maybe some of the other fixes were transient and are no longer needed.
I am working on an updated patch with findings so far, will test there and then post here once green.
#90.4: this and several other migrate_drupal_ui tests
#90.5:
#90.7:
#90.11: this and other locale tests
Comment #98
mondrake#96
can
$variables['attributes']
be a scalar here?Comment #99
alexpott#96/@Charlie ChX Negyesi this is has caused major headaches before - digging in the issue queue... something was an array at the start the render pipeline and then depending on if a module was enabled it became an Attribute object - making life hard for template_preprocess_functions in contrib and custom.
Comment #100
alexpott@mondrake great work! Thanks for doing this - and also doing it in a testing issue is smart.
Comment #101
alexpottDebugged the failing test \Drupal\Tests\system\Functional\Batch\ProcessingTest::testBatchFormProgrammatic(). This should be
Using null coalescence here could hide errors caused by a batch doing soemthing very odd and unsetting
$batch['progressive']
.Comment #102
mondrake#101 ok will put in an incoming patch in the testing issue
Comment #103
mondrakeSo here's an updated patch with more todos referrring to latest comments.
EDIT - ouch, the todos are in the interdiff but not in the patch... will correct in next one.
Comment #104
mondrake#90.2 if $css_asset is empty, which is the case in some render tests, this fails. Throwing the exception because this is what happens a few lines below if the asset type is not recognised. Yes, it should be split in a separate issue. Added a @todo.
#90.3 I went for an inline check that the version is a string. Casting generally to string before entering in the checks may be fragile: a version number could be interpreted as a float and we never know what the casted string may become (think 1.1 and 1.10, same 'number' but totally different 'version').
Added todos that went missing in #103.
Comment #105
alexpottThis fix isn't right unfortunately.
So I think this should be we need to detect if we dealing with an array() or an Attribute object. And if we're dealing with an attribute object use
isset()
- which is super funky because it works different from arrays. Anyhow I think this is a good candidate for splitting out into a separate issue and getting test coverage as the current code in HEAD is broken too...lolz.
Comment #106
mondrakeSorry I lost some bits in #103 and #104. Will fix now.
Comment #107
alexpottRe arrays vs attribute objects @lauriii dug out #2917653: toolbar_preprocess_html() converts attributes from array to Attribute object - see how much fun!!!
Comment #108
mondrakeRe-added the coalesce operators in
core/modules/field/src/Plugin/migrate/source/d7/FieldInstance.php
andcore/modules/taxonomy/src/Plugin/migrate/source/d6/TermLocalizedTranslation.php
, and re #105 reverted to the hack in #89, adding a @todo to signal the need of a separate issue.Comment #109
mondrakeHow about this for #105?
Comment #110
alexpottThis will work. I wonder if it is worth putting this as a static help on the Attributes object. Also this is not only about PHP7.4...
This code is broken on all versions of PHP when $variable['attributes'] is an Attribute object.
But yeah a separate issue with tests etc is the way to go here.
Comment #111
mondrakeThen maybe all we need here is a
Attribute::getKeys
method to return the defined keys, regardless if array or object and set or null: that’s the problem at hand. Once you know the key, accessing it via array syntax is ok.Comment #112
mondrakefwiw I tried to find the instances where array functions are called with
$variables['attributes']
as an argumentgrep -r -e "rray.*\$v[^\[]*\[\'attributes\'\][^\[]" .
and all I could find was
Comment #113
Ghost of Drupal PastmergeDeep is a special kind of trouble. It passes arguments to mergeDeepArrays which doesn't fatal on as long as the "array" is iterable but if the iterable contains ArrayAccess objects instead of arrays then the recursion breaks! Congratulations on finding a really ugly bug. I mean... https://3v4l.org/X5Cje
Comment #114
mondrakeComment #115
mondrake@Charlie ChX Negyesi let's say I found the call and you found the bug :)
Do we need to file a separate critical issue 'Ensure that mixing array and Attribute objects in theme rendering is managed properly'?
Comment #116
mondrakeComment #117
mondrakeVery strange results in PHP 7.4 tests in #104... we have an intermittent deprecation failure (!). No clue.
Comment #118
mondrakeAn hopefully better solution for #90.5.
Since we are calling
::getDefinition($type, FALSE)
, exception throwing on invalid plugin is disabled, and$plugin_definition
will be NULL. So just intercepting that and making sure the 'class' key exists in the array.Comment #119
alexpottI think the null coalescence here is okay... but what is worth doing is adding a comment that plugin_definition can be null if the plugin does not exist. And we should adjust the return type docs...
Hmmm... actually this introduces a behaviour change. Atm in HEAD if $plugin_definition is an array then it will produce an error. So maybe
The other option would be to throw the exception and catch it and re-throw because the failing test is \Drupal\KernelTests\Core\Field\FieldMissingTypeTest and that's testing exceptions are thrown. Perhaps yet-another-sub-issue to discuss this?
Comment #120
mondrakeFiled #3090145: Ensure that mixing array and Attribute objects in theme rendering is managed properly for #110 and #113
Comment #121
mondrakeComment #122
volegerre #117 yes, php 7.4 introduce some deprecations.
See "Implode with historical parameter order" at https://www.php.net/manual/en/migration74.deprecated.php
Comment #123
mondrake@voleger yes the point here is that the same patch first failed with a deprecation yesterday, and later passed with no error. Pretty weird
Comment #124
alexpottPushed an upstream fix for the vfsStream - https://github.com/bovigo/vfsStream/pull/204 for their 1.x branch.
Comment #125
mondrakesymfony/validator and vfsStream upstream PRs were merged, but no releases yet. Adjusting to requiring most current dev branches to see status.
Also, added back todos for #119 and #120.
Comment #126
mondrakeComment #127
mondrakemikey179/vfsstream 1.6.8 was just released
Comment #128
mondrakeComment #129
mondrakeComment #130
mondrakeComment #131
mondrakeFiled #3091225: Require-dev mikey179/vfsstream ^1.6.8 in order to support PHP 7.4
Comment #132
mondrakesymfony/validator 3.4.33 and composer/composer 1.9.1 are out and we'll need those for the issue at hand here.
Comment #133
mondrakeComment #134
mondrakeComment #135
mondrakeComment #136
mondrakeUpdated patch to reflect new releases of dependencies and symfony/validator updated already to 3.4.33
Comment #137
effulgentsia CreditAttribution: effulgentsia at Acquia commentedCan we open a separate issue for this to discuss it further? It seems to me that we should likely do something when
system.site
doesn't exist. Maybe throw an exception? Or return from the function early? Or at least add a comment for why doing nothing and continuing with the rest of the function is correct?Comment #138
mondrakeAdded a @todo for #137, removed
composer update
of vfsStream (just updated in HEAD), removedcomposer self-update
as it looks like the PHP 7.4 container is already on 1.9.1.Comment #139
mondrake#3075785: Update composer/composer to ^1.9.1 was just committed so we do not need extra container commands at the moment.
Comment #140
xjmWe'll want to mention this in the release notes (either that it's supported by the time it ships, or that there are a few compatibility issues remaining). For beta1 I'm going to list it in the "known issues" section.
Comment #141
mondrake#3089764: Updating translations does not clear the JS asset cache so new translations are not loaded was committed so we can remove a @todo form the patch. On it.
Comment #142
mondrakeDone #141.
Comment #143
alexpottIt'd be awesome if someone could review #2830631: Remove code that tries to use _raw_variables for route argument resolution as it does not work
Re #137 we already have explicit testing of what happens in both a config install and a config import when core.extension is missing - that's why we're getting these errors - they're being triggered by the test coverage. See \Drupal\KernelTests\Core\Config\ConfigImporterTest::testEmptyImportFails(), \Drupal\KernelTests\Core\Config\ConfigImporterTest::testSiteUuidValidate() and \Drupal\FunctionalTests\Installer\InstallerExistingConfigNoConfigTest
Comment #144
mondrakeAlso a review of #3090145: Ensure that mixing array and Attribute objects in theme rendering is managed properly would be nice.
Comment #145
xmacinfoChanged to:
PHP 7.4 is due to be released in November 28, 2019, a week before Drupal 8.8.0.
Comment #146
mondrakeReroll after commit of #2830631: Remove code that tries to use _raw_variables for route argument resolution as it does not work.
Comment #147
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedOpened #3095895: FieldTypePluginManager::getPluginClass() should throw an exception when called for a field type that doesn't exist for this part.
Comment #148
mondrakeComment #149
amateescu CreditAttribution: amateescu for Pfizer, Inc. commented@mondrake, that issue is already a child of this one :)
Comment #150
Gábor HojtsyComment #151
mondrakeReroll after commit of #3095895: FieldTypePluginManager::getPluginClass() should throw an exception when called for a field type that doesn't exist
Comment #152
heddnComment #153
mondrakeThere's not a point release for easyrdf/easyrdf yet, but dev-master was updated yesterday on Packagist, including https://github.com/njh/easyrdf/pull/311.
Let's see if updating to dev-master can help removing the workaround introduced in #79.
Comment #155
mondrakeAdding aliases to allow both old- and new-school class names for easyrdf
Comment #156
mondrakeComment #157
Liam MorlandComment #158
mondrakeComment #159
mondrakeComment #160
mondrakeComment #161
ravi.shankar CreditAttribution: ravi.shankar at OpenSense Labs commentedI have added re-roll of patch #155.
Comment #162
mondrakeNeeds re-roll again after commit of #3104420: PHP 7.4 Deprecated curly brace syntax for accessing array elements
Comment #163
SpokjeRe-roll of #155
Comment #164
SpokjeComment #165
xmacinfoMarked by as Needs work based on bot results. Thanks.
Comment #166
SpokjeTo Be Honest: I don't really understand why is failing on TestBot.
It passes on my local machine and the patch for this issue doesn't (seem to) do anything with/to it?
Let's await the arrival of Bigger Brains, because mine can't grasp it all.
Comment #167
Spokje(Meh, didn't refresh the page, so my status was still on NR, put it back on NW now)
Comment #168
mondrakeWeird. I also do not understand this, but I wrote the failing test, so let's try something different on that one.
Comment #169
mondrakeThe weird thing is that #163 failed, while #161 just a few hours earlier didn't, and I cannot see any change in between that would have affected the results. It is as if PHP 7.4-dev just started behave differently.
Comment #170
Liam MorlandThe failures look more like issues with the testing environment.
Comment #171
Gábor HojtsyOpened #3109885: [meta] Ensure compatibility of Drupal 9 with PHP 8.0 (as it evolves) for PHP 8 and postponed on this one.
Comment #172
timmillwoodI wonder if there's anything we can do to work with the easyrdf community.
Can we open an issue for this todo? Also explain the cases when $system_site might be false as it will give someone a head start coming to this.
Can we open an issue for this todo?
Can we open an issue for this @todo?
Can we open an issue for this todo?
Sorry, same, issue for this todo please.
Is this the standard way to denote sections of code to remove in D9?
Sorry, another, issue for @todo.
and another.
and another
Lets just open issue for all todos.
Comment #173
alexpott@timmillwood progress has stalled here somewhat but these things are supposed to be solved here and not in follow-ups ie. the @todo's are for this issue.
Comment #174
alexpottTo unblock this issue we should land:
#3090145: Ensure that mixing array and Attribute objects in theme rendering is managed properly
#3090017: Isolate test dependency on easyrdf/easyrdf to a single trait
Comment #175
mondrakeReroll after commit of #3090145: Ensure that mixing array and Attribute objects in theme rendering is managed properly
Comment #176
alexpottx-post with #175 but I think this represents the path forward...
This patch adds back the class alias solution for
\EasyRdf_ParsedUri
as since #3090017: Isolate test dependency on easyrdf/easyrdf to a single trait we can do this in test-only code in a way that only impacts the test system. Hopefully easyrdf/easyrdf will do a release and we can upgrade to it sometime. However rather than move to dev-master and make life difficult for any contrib modules using that vendor library we can take the least disruptive path for both Drupal 9 and 8.x at this point.Now we need to focus on the rest of the @todos in Drupal 9.0.x and then focus on backporting to 8.x
Comment #177
alexpottFixing some of the @todos
Comment #178
alexpottHere's a patch with all the @todo's remove other than those that are linked to a specific test or are in a test. This should fail on PHP 7.4 - but let's not add any @todo's back in unless they are linked to either a specific test that can re-create the error or linked to an issue to resolve once this has landed (hopefully we have none of these).
Comment #179
alexpottComment #180
alexpottSo I think fixing the @todo in \Drupal\hal\Normalizer\EntityReferenceItemNormalizer::normalize() is out-of-scope. Using the null coalesce operator we've made it behave the same as PHP 7.3 so opened #3110815: \Drupal\hal\Normalizer\EntityReferenceItemNormalizer::normalize() tries to normalize entities that don't exist to fix that code properly because it is not doing what it is supposed to for entity references pointing to values that don't exist.
Patch attached also fixes \Drupal\Tests\taxonomy\Kernel\Views\ArgumentValidatorTermTest - that test was not testing what it thought it was. Now it is properly testing what happens when the validator doesn't allow multiple terms.
Comment #181
mondrakeComment #182
alexpottOne down...
So this one is fun... the source property 'field_data' has never existed so this sets a source property up of 'field_settings' but it is always equal to NULL. It's completely pointless. The field settings are there - they are in 'data' property.
Comment #183
heddnIf it truly is NULL, then I don't have any concerns. Although BC could be effected, it seems like a small edge case. Considering its really hard to take over the field instance migration from core. No one really does. So +1.
Comment #184
alexpottThis should fix the remaining kernel tests. Now for the functional...
Comment #185
alexpottFixing some of the functional tests. Added a follow-up for the Migrate UI credential form - see #3110839: Use of \Drupal\Core\Database\Install\Tasks::getFormOptions() in \Drupal\migrate_drupal_ui\Form\CredentialForm::buildForm() results in confusing description for prefix form element
Comment #186
alexpottFixing the last fail - again it is a test expectation gone wrong.
Comment #187
alexpottI think we need to add comments for these changes to explain why they are necessary and the situations they deal with.
Comment #188
Gung Wang CreditAttribution: Gung Wang commentedI got a ton of PHP Notices on my local site:
It might be a compatible problem of Drupal 8.8.1 with PHP 7.4.1
My tempery solution is to change the code below:
Comment #189
alexpottComment #190
heddnComment #191
alexpott@Gung Wang I've reverted your changes to the issue summary and issue metadata. The fact that Drupal 8 is not compatible was mentioned in the known issues of the release note for 8.8.0.
I do however agree with you that this has now become a bugfix as PHP 7.4 has been a stable release of PHP since late last year.
Comment #192
alexpottAdding a comment as per #187.
For the \Drupal\language\LanguageServiceProvider::getDefaultLanguageValues() change - I've reverted that change as I want to work out why that is needed.
Comment #193
alexpottOkay now I've added a comment to
\Drupal\language\LanguageServiceProvider::getDefaultLanguageValues()
. I tried to set up the configuration in KTB but this wasn't enough either. I think making the change in\Drupal\language\LanguageServiceProvider::getDefaultLanguageValues()
is ok. Not ideal but better than other larger scale changes to the test system.Comment #194
alexpottUpdated the issue summary to reflect the recent progress and solution.
I think this is just about ready so reviews very welcome!
Comment #195
joseph.olstadretriggered postgresql 9 / on php 7.3 tests
just to see if it was a runner glitch, otherwise might have to look closer at the 3 errors.
Comment #196
alexpottAh still didn't get the NumericFilter value quite right... patch attached fixes postgresql and doesn't break the other db drivers.
Comment #197
Gábor HojtsyChanges look good on a cursory look but I did not scrutinise them. Here are three things I found nonetheless:
Configuraion typo
Is __serialize() and __unserialize() like __sleep() and __wakeup()? I tried finding docs but could not.
Should these not be inheritdoc at this point now that they implement internal PHP magic?
Can we link to the upstream issue here for future checking if that got fixed, etc.
Comment #198
mondrakelooking at how Doctrine is now doing that
maybe we do not need doing the second assignment to
$position
, that I was adding earlier in the patches here only to be on the safe side.Comment #199
longwave> Is __serialize() and __unserialize() like __sleep() and __wakeup()? I tried finding docs but could not.
Yes, this is new in PHP 7.4: https://wiki.php.net/rfc/custom_object_serialization
Comment #200
alexpottThanks for the review @Gábor Hojtsy
1. Fixed.
2. See https://wiki.php.net/rfc/custom_object_serialization - this was implement upstream so we have to follow suit. We have to make this change due to changes in Symfony 4 - see https://github.com/symfony/symfony/commit/5638d6adcc95a0bdc757e70d10c1ad...
3. It is fixed upstream - but they need to do a release - https://github.com/njh/easyrdf/pull/311 - not really sure what to link to. I've create another Drupal issue to track future options.
Comment #201
alexpottRe #198 - good idea we should copy doctrine here because it make applying any future changes simpler. Note that this class does not conform to Drupal's coding standards because it is basically a copy of Doctrine's code.
Also Doctrine has not done the change to \Drupal\Component\Annotation\Doctrine\DocParser::Value() so I'm reverting that to work out why it is needed.
Comment #202
mondrakeThere are no testbots for PHP 7.4 on SQLite and PostgreSQL :(
Comment #203
alexpott@mondrake I'm pretty sure that that doesn't matter too much - and shouldn't prevent us getting this in. I've run many of the tests locally that failed on postgres and sqlite so we know that nothing major is trigger notices in the db drivers.
Comment #204
mondrakeThen I think this is ready, at least for D9. Follow-ups are created and referenced. Tests pass on 7.4-dev on MySQL. Hopefully this in could trigger setup of testbots on a PHP 7.4 point release and for all the dbs.
Comment #205
alexpottThis change is due to incorrect mocking in
\Drupal\Tests\rdf\Unit\RdfMappingConfigEntityUnitTest
.\Drupal\Core\Entity\EntityType::getBundleConfigDependency()
can never return NULL. We should fix the test instead.As this moves the changes from runtime to test time I don't think this affects the rtbc status.
Comment #206
mondrakeThis is Symfony4 as per #200, and is obviously causing lot of failures when this patch is applied to D8.9. So the backport will have to be adjusted for Symfony3.
Comment #207
alexpott@mondrake yeah that is Symfony 4 only code - and there are other things too that'll need to be fixed in 8.9.x. I suggest that once this lands in 9.0.x we get to work on 8.9.x (and 8.8.x).
Re #205 I've filed #3111029: RdfMapping unnecessarily adds a dependency on the module providing the target entity as a related follow-up - though not necessary for PHP7.4 or even a bug fix - just neater and less redundant code.
Comment #208
catchComment nit: is the error that the system.site config is not there, or the ConfigImporterException itself? I would assume the error is the exception getting thrown but if so that's not what the comment says.
Makes sense to mimic Doctrine here.
Oof but it's probably better than relying on a dev version.
Comment #209
alexpott@catch thanks for the review. I've tried to improve the comment to reflect what happens when system.site is not present.
Re #208.3 the reason I think this fix more desirable than using the dev-master tag is that there are API changes there - that's why earlier patches that were installing the dev-master were doing:
Do the class alias means that runtime code in D8 cxontrib modules will continue to work as it does now. Yes it might trigger a deprecation in PHP 7.4 but it'll still work.
Comment #210
mondrakeFWIW, I run a test on TravisCI with PHP 7.4 and with patch in #205 on an experimental db driver:
https://travis-ci.org/mondrake/drudbal/builds/645983785?utm_medium=notif...
All green.
Incidentally, job #14 there runs some test groups on the core SQLite driver, also all good.
Comment #211
catchCommitted 534ee0d and pushed to 9.0.x. Thanks!
Leaving open for the 8.9.x/8.8.x backport.
If there are clean-ups for the 9.0.x commit let's try to spin them off to follow-up issues.
Comment #213
alexpottHere's a patch for 8.9.x and (hopefully) 8.8.x
Comment #214
alexpottFor 8.8.x we have the following conflicts...
So we need #3090017: Isolate test dependency on easyrdf/easyrdf to a single trait to land in 8.8.x before continuing to work on that branch... but we're good to go on 8.9.x so reviews of #213 would be great.
Comment #215
mondrake#213 adjusts the fix for CompiledRoute to legacy D8-supported Symfony 3, and reintroduces the fix for LinkItem that was already in patches up to #175, and dropped in later patches since that entire legacy part is removed in D9.
The patch runs OK on all platforms down to lowest supported PHP 7.0.
So, good to go for D.8.9, I think.
Comment #216
catchCommitted e6f084b and pushed to 8.9.x.
Moving to 8.8.x and 'to be ported' for after the easyrdf patch is in.
Comment #218
alexpottHere's an 8.8.x patch. The only change was to remove the changes to MarkupInterfaceComparatorTest as that doesn't exist in 8.8.x - it was added in #3082340: Replace assertEquals() overrides in PHPUnit Kernel, Functional and FunctionalJavascript tests with a MarkupInterfaceComparator implementation
Comment #219
mondrakeSo this completes the journey.
Maybe the release notes need amendment to notify module developers that if they need to rely on easyrdf in PHP 7.4 without the rdf module, they need to alias the forked class by themselves (at least until easyrdf publish a new point release - which itself would not be a simple change given the namespace change that that would bring).
Comment #221
catch@mondrake that shouldn't go in a release note which is more for site admins, there's no runtime implication for that easyrdf change and it won't make existing sites wors. It could go in a change record maybe?
Committed 7330f73 and pushed to 8.8.x. Thanks!
Comment #222
alexpottAlso if you doing have runtime code that is using easyrdf and running on PHP 7.4 - you don't actaully need to update - yes it will generate deprecation notices but that's all - and depending on how you have error reporting configured you might not even log them let alone see them.
Comment #223
Mile23Just a heads up... This change might be responsible for failing local tests when running phpunit instead of run-tests.sh, discovered by @Beakerboy: https://drupal.slack.com/archives/C223PR743/p1581196846035900?thread_ts=...
Comment #224
alexpott@Mile23 this is not responsible for that beyond making Drupal compatible with PHP 7.4. This happens because of PHP deprecations triggered by PHPUnit. And sure if you upgrade PHPUnit you're not going to trigger those deprecations. Not much we can do about that here.
Comment #225
Liam MorlandPeople interested in system requirements may be interested in #3114079: Update minimum supported Apache version to >= 2.4.7.
Comment #226
nils.destoop CreditAttribution: nils.destoop as a volunteer and at iO commentedIn case someone is searching for the 8.8.2 patch.
Comment #227
alex.skrypnykCould someone please clarify if there is an intent to backport this to `8.7.x` branch. The security support for `8.7.x` is until June 3, 2020. Thanks
Comment #228
BerdirAs you said yourself, 8.7 is in _security support_, that means the only changes that are backported are security fixes, this does not include PHP 7.4 compatibility.
Comment #229
fabienlyHello for information,
I tried to applied patch via composer on core 8.8.3 and php 7.4 and it doesn't applied.
I am using postgreSQL database
The serveur is Centos 7
error log :
This is my drush status :
Comment #230
jacob.embree CreditAttribution: jacob.embree commentedYou don't need to apply this patch to Drupal 8.8.3 because it was included in that release already.
Comment #232
Eugene Bocharov CreditAttribution: Eugene Bocharov as a volunteer commentedIs it me or we also should make change in
/core/lib/Drupal/Core/Render/Element.php
from:
to:
Like it's be done at
child()
method. Since$key
may be integer here too.I'm not sure, should I comment here or open new issue, and make patch for 8.8.x-dev, 8.9.x-dev or 9.1.x-dev.
Comment #233
fgmOr for Drupal 9, could use: