Postponed awaiting Symfony 5.4 changes that may require core changes.
Drupal 9 was released with Symfony 4.4. Drupal 10 is planned to adopt either Symfony 5.4 (#3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support)) or Symfony 6 (#3197483: Evaluate the potential update of Drupal 10 to Symfony 6 and do it if possible). Either way deprecated API uses in Symfony 4 need to be resolved and incompatibilities with Symfony 5 releases need to be resolved. If a Symfony 6 update is done, we need to bridge the gap as well with Symfony 5 somehow, see #3196027: Contrib support solution needed for potential Symfony 4 to 6 upgrade, Symfony 5 only deprecations are not available in Symfony 4.
This issue is for any outstanding compatibility issues with Symfony 5.
See #2976394: Allow Symfony 4.4 to be installed in Drupal 8 for prior art with Symfony 4 on Drupal 8.
See children issues.
None at this time.
None.
TBD
TBD
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 3055180-2.drupal.Meta-Make-Drupal-8-work-with-Symfony-5-along-with-Symfony-3-and-4.patch | 198.12 KB | mikelutz |
Comments
Comment #2
mikelutzHere is a copy of the most recent green patch from #2976395: check if my custom config entity is being updated/modified. Individual child issues should start by posting this patch, with the appropriate deprecation suppression removed to show the failures,
Comment #3
gábor hojtsyThis sounds like a duplicate of #3009255: [META] Symfony 5.0 compatibility, but we can close that as duplicate and keep this, just need to parent / tag properly.
Comment #5
gábor hojtsyCarrying over this single comment from @andypost from there:
Comment #6
gábor hojtsyComment #7
andypostIt makes sense to decide on related #2825358: Event class constants for event names can cause fatal errors when a module is installed while resolving
- #3055194: [Symfony 5] The signature of the "Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher::dispatch()" method should be updated to "dispatch($event, string $eventName = null)", not doing so is deprecated since Symfony 4.3.
- #3055198: [Symfony 5] Symfony/Component/EventDispatcher/Event is deprecated in Symfony 4.3 use Symfony/Contracts/EventDispatcher/Event instead
Comment #9
mikelutzComment #10
gábor hojtsyJust committed #3114785: [Symfony 5] Update deprecated short factory configurators in Yaml which was an easy quick win. Any other such quick wins? :)
Updated the issue summary to be current.
Comment #11
gábor hojtsyComment #12
martin107 commentedI think the ProxyBuilder needs to be updated to be compatible with Synfony5's new interfaces which are starting to use for example "string" as a parameter type or return type.
So I created this issue.
Comment #13
xjmComment #14
xjmComment #15
daffie commentedNeeds a reroll.
Comment #16
catchRetitling slightly since we'll need issues for Symfony 5.0 + higher deprecations.
Comment #17
catchUpdated the issue summary, there are currently three patches required.
Would be good to do an updated patch here to check that's all that's remaining.
With EventDispatcher we can't make core 100% compatible, only provide forward-compatibility layers to support the continuous upgrade path, so there will be some core changes required apart from just the composer update itself. We should probably open a Drupal 10 'Update to Symfony 5' issue a patch for those changes (the code we need to change is unlikely to change a lot more before the branch opens, unless there are further changes in Symfony itself).
Comment #18
gábor hojtsy@mikelutz: can you help with what are the steps to generate this patch? It sounds like we may have all Symfony 5 issues resolved now :)
Comment #19
catch#3055193: [Symfony 5] The "Symfony\Component\HttpFoundation\File\MimeType\MimeTypeGuesser" class is deprecated since Symfony 4.3, use "Symfony\Component\Mime\MimeTypes" instead. still needs work for the last Symfony 4 deprecations.
After that's committed, there are some changes required to actually update to Symfony 5, and some of our dependencies aren't compatible yet - notes and in-progress patches at:
#3161889: [META] Symfony 6 compatibility
Comment #20
catchAdded the upstream MinkBrowserKit issues to the issue summary.
Comment #21
catchNow that #3055193: [Symfony 5] The "Symfony\Component\HttpFoundation\File\MimeType\MimeTypeGuesser" class is deprecated since Symfony 4.3, use "Symfony\Component\Mime\MimeTypes" instead. is RTBC there's nothing to do here, but hesitant to actually close this given the Mink issues (which have been open for months), so moving to plan/postponed since we may need to try to push those along upstream if they're still open when we want to open the Drupal 10 branch.
Comment #22
mikelutzSetting to NW for a couple new SF4 deprecations we missed. #3172425: "Symfony\Component\Lock\Factory" is deprecated since Symfony 4.4 and will be removed in 5.0 use "Symfony\Component\Lock\LockFactory" instead and #3172537: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided
Comment #23
gábor hojtsyAw, celebrated too early then. Updated the issue summary. How do we know these are the only ones left?
Comment #24
mikelutzThe SF5 test patch is down to 26 test failures, and I found these two issues while reviewing those tests. We really don't have to fix them here, but they met the criteria, so I added them here.
One of them is a skipped deprecation that we just didn't make an issue for. All the remaining skipped SF4 deprecations are around the Event and MimeTypeGuesser changes, and those need to stay in Drupal 9, as we still need to use the legacy classes for now, despite having wrapper code and a plan to switch over to the new classes in D10, so we aren't skipping any other deprecations that should cause a problem.
The symfony/Lock deprecation for some reason doesn't trigger a deprecation error, it only has an annotation. I assume a mistake on symfony's part, so I think these will be the last two, unless somehow I trace another of the remaining test failures to another SF4 deprecation, but I don't expect to.
Comment #25
gábor hojtsy#3172425: "Symfony\Component\Lock\Factory" is deprecated since Symfony 4.4 and will be removed in 5.0 use "Symfony\Component\Lock\LockFactory" instead landed.
Comment #26
andypostBack to status from #21 as last issue fixed #3172537: Passing a command as string when creating a "Symfony\Component\Process\Process" instance is deprecated since Symfony 4.2, pass it as an array of its arguments instead, or use the "Process::fromShellCommandline()" constructor if you need features provided
Comment #27
longwaveA new issue that has arisen with Symfony 5.2: #3185603: [Symfony 5] Symfony Constraint plugins are not strictly Drupal plugins
Comment #29
gábor hojtsyBack to postponed again since #3185603: [Symfony 5] Symfony Constraint plugins are not strictly Drupal plugins landed and there are no other blockers listed.
Comment #30
daffie commentedWe also need #3187074: [Symfony 5] Services are private by default. The issue is ready for a review.
Comment #31
gábor hojtsyGood point, added that to the issue summary though :)
Comment #32
gábor hojtsyAaand #3187074: [Symfony 5] Services are private by default landed.
Comment #33
gábor hojtsyOpened #3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support) for the actual update for when the Drupal 10 branch is open.
Comment #34
xjmComment #35
longwaveBack to active for #3209239: [Symfony 5] Symfony\Contracts\EventDispatcher\Event subclasses need return types
Comment #36
catch#3209239: [Symfony 5] Symfony\Contracts\EventDispatcher\Event subclasses need return types is in now.
Was going to mark this back to postponed, but there is still no movement on either of the MinkBrowserKitDriver PRs, so I've gone ahead and opened an issue to start tracking that more actively, and potentially switch to a fork in the meantime: #3209459: Switch to friends of behat MinkBrowserKitDriver for PHP 8 and Symfony 5 compatibility.
Comment #37
catchRe-titling since all known Symfony 4 deprecations are dealt with, but we still have the potential for Symfony 5.4 introducing a breaking change.
Comment #38
gábor hojtsyGiven #3209459: Switch to friends of behat MinkBrowserKitDriver for PHP 8 and Symfony 5 compatibility landing, going to remove this section from the issue summary:
Also updating the text in general and postponing awaiting Symfony 5.4 later this year.
Comment #39
gábor hojtsyAdding to release highlights.
Comment #40
andypostIt could be marked as fixed I guess
Comment #41
catchI don't think there are any outstanding issues remaining, however we haven't got Symfony 5.4 to test with yet, so we can keep this open to track those issues once we do.
Comment #43
longwaveSymfony 5.4.0 is out. Discussed briefly in Slack with @andypost and @Gábor Hojtsy, next steps here are a new child issue to upgrade Drupal 10.0.x to Symfony 5.4, and then if all is well this can be closed as done.
edit: #3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support) already existed, let's use that
Comment #44
gábor hojtsyI don't believe we have any outstanding Symfony 5.4 issues other than actually updating to it in #3197482: Update Drupal 10 to depend on Symfony 5.4 (as a stepping stone to Symfony 6, for deprecation checking support), so this one is more Fixed than Active. Thanks all!