Problem/Motivation
ControllerResolver::getArguments() has been removed in Symfony 4, leading to test failures when 8.x is updated.
Proposed resolution
Re-implement it in our subclass, mark it as internal for removal in Drupal 9.
This appears to be only called by our test coverage, so another option would be to remove the test coverage and treat the inherited method as 'dead code'.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | Screen Shot 2018-12-20 at 16.11.28.png | 33.71 KB | wim leers |
| #16 | 3020536-16.patch | 5.88 KB | catch |
| controller-resolver-symfony4.patch | 1.12 KB | catch | |
| #2 | 3020536-2.patch | 1.82 KB | catch |
| #6 | 3020536-6.patch | 2.7 KB | sjerdo |
Comments
Comment #2
catchAlso need to directly implement the interface.
Comment #3
kim.pepperNit. Looks like some whitespace issues.
Comment #4
alexpottIs this only legacy tests that are calling it? If so they could be skipped if Symfony > 3.
Comment #5
catchIt looks like only
Drupal\Tests\Core\Controller\ControllerResolverTest::testGetArguments()which is indeed legacy. That's testing for a deprecation message on doGetArguments(), which is only called by getArguments(). How would we skip tests based on Symfony version though?Tagging novice and needs re-roll for fixing the Symfony -> Drupal coding standards stuff.
Comment #6
sjerdoUpdated indent of patch and removed a use of ArgumentResolverInterface::class which wasn't used in sprintf.
Comment #7
sjerdoComment #8
sjerdoExcuse me, I've add the wrong interdiff. Here is the correct one.
Comment #9
alexpottDone some more thinking about this. I think we need to add a deprecation to our new getArguments() because ideally we don't want people to use it. But if we want people to be able to use Symfony 4 on Drupal 8 then we need to provide it. For me though this pseudo-backporting of Symfony code is one of the reasons that I'm suspicious that making Drupal 8 core AND contrib AND custom be able to run with both Symfony 3 and 4 is likely to be complex and quite involving. That doesn't mean that prepping Drupal 8 to support Symfony 4 is wrong as that will result in less work but this is different and feels like a dangerous precedent.
Comment #10
catchdoGetArguments() already has a deprecation notice and getArguments() always calls it, so it's impossible to call the method without getting a deprecation, but it would be clearer if it was on the main method.
Apart from #3020385: Symfony 3 and Symfony ^4.2 JsonEncode constructors are incompatible this is the only tricky change in Symfony 4.2, everything else has been minor test updates, so I don't think it's that bad. Of course we have Symfony 4.4 deprecations still to come which could be harder to deal with. I don't think we should try to support Symfony APIs that core doesn't use/test that contrib might happen to rely on or anything like that though, since that's a promise we may well not be able to keep.
These are changes where if we were making the change directly in the 9.x branch, that we'd just be able to delete the old test and doGetArguments() and be done, but the difference between doing it now and in one year makes it worth it for me.
Comment #11
alexpottThat's going to be hard to discover though. We're far from 100% test coverage and we've changed stuff in core for Symfony 3 -> 4 deprecations already. For me adding this method to our code is the start of us providing a facade to Symfony 4.
The other idea of detecting Symfony 3 maybe could be done with an explicit assertion on whether
\Symfony\Component\HttpKernel\Controller\ControllerResolver::getArguments()exists.Comment #12
catchWell I meant literally just fixing what we have test coverage for.
Here's a patch that does that, it's not too bad, had to remove a @covers from a couple of tests.
Comment #13
catchThe 'combined' patch includes the Symfony 4 update and some other patches, it should theoretically only have a fail in page caching at this point and maybe one or two others.
Comment #14
alexpottI like #12. The changes to
@coversseem great to me because we really ought to be only covering our own code and we don't implement getArguments().Comment #16
catchThree more tests testing the same deprecation that need the same approach.
Comment #17
wim leersNit: extraneous
\n.Why not use
::class?This looks like invalid PHP. Yet … it did pass tests. WTF? 😱
Comment #18
wim leersApparently that's dreditor screwing this up. First time that ever happened to me.

Comment #19
catchNeither of these classes are used anywhere else in the file, so we'd be importing them at the top (using the fully qualified class name as you do in a use statement), then here using the namespaced version... to get the FQCN again via ::class, which seems like a lot of indirection compared to using the string.
Comment #20
wim leersFair! LGTM then :) Trivial test-only changes, really.
#17.1 can be fixed on commit (or not at all, it's super nitpicky).
I don't think is the right component though.
Comment #21
alexpottAll the tests being changed here are already legacy tests so this looks great to me.
Committed 8b6fd65 and pushed to 8.7.x. Thanks!
Fixed the unnecessary new line on commit.
Also fixed
I guess these were the cause of the dreditor weirdness :)
Comment #24
xjm