See meta-issue: #2511554: [meta] Move some parts of Page Manager into CTools
Currently, Page Manager has BlockDisplayVariant, which contains much of the same code that we'd want in Panels' display variant, but we don't want Panels to depend on Page Manager.
Also, there are people sub-classing BlockDisplayVariant for use on Drupal 8 in production today!
The proposal is to move it into CTools and then both Page Manager and Panels can use it. Also, BlockDisplayVariant isn't very useful unless sub-classed, so it makes sense to make it abstract so that the only people who are using it are sub-classing it.
Comment | File | Size | Author |
---|---|---|---|
#27 | interdiff.txt | 2.81 KB | tim.plunkett |
#27 | 2511566-ctools-27.patch | 30.23 KB | tim.plunkett |
#25 | interdiff.txt | 2.23 KB | tim.plunkett |
#25 | 2511566-ctools-25.patch | 30.29 KB | tim.plunkett |
#19 | interdiff.txt | 15.27 KB | tim.plunkett |
Comments
Comment #1
dsnopekComment #2
dsnopekPostponed on #2511570: Remove Drupal\page_manager\Plugin\PageAwareVariantInterface
Comment #3
dsnopekAdding to the sprint board because a Panels issue is blocked on this one: #2511582: Extend BlockDisplayVariant rather than copying code from Page Manager
Comment #4
tim.plunkettThis is the next step.
Comment #5
lslinnet CreditAttribution: lslinnet at Adapt commentedGonna give this a go either later tonight or tomorrow morning, had a quick talk with Tim & Kris regarding the associated traits, it got decided to also move these to ctools.
Comment #6
dsnopek@lslinnet: Most of the traits should be moving into CTools in #2511556: Add BlockVariantInterface (and Trait), and BlockPluginCollection from Page Manager, however, some of them got de-scoped (by EclipseGC) because they won't be necessary once #2551633: Make variants into their own config entity is done. That said, if we need them just to finish this issue, I'd be all for adding them back to the scope of that issue, and then removing them later when they are obsolete.
Comment #7
lslinnet CreditAttribution: lslinnet as a volunteer commentedHere is the initial go at the move, fairly certain additional work is needed (like tests)
Comment #8
japerryHere is a re-write of them
Comment #9
dsnopekUnfortunately, #2551633: Make variants into their own config entity makes lots of changes to BlockDisplayVariant (actually, simplifying it and removing some of the necessary interfaces and traits). I don't really know how long it'll take to get that committed (hopefully, not long!) but it might make sense to postpone this one on that one.
Comment #10
japerryHeya, so unfortunately I think we're going to do this first because its blocking a whole bunch of issues.
Here is some re-writing with tests that need to be redone by Tim.
Comment #11
EclipseGc CreditAttribution: EclipseGc commentedThis is a review of 8, should basically apply to 10.
Not a problem for this code move, but I think we should consider making these static methods.
Don't implement this. The user of the trait will need to manually implement this method.
Ok... so I'll move this to ctools, but no one can ever ever use this beyond the scope of this patch because we need to move this back out ultimately and apply these methods to the PageVariant entity we have pending.
We're trying to get this into core right now, so we're likely to remove this shortly, but ok.
Also there are 21 use statements on our BlockDisplayVariant... I didn't apply this code yet, are they all used? Please delete those which aren't if any.
Eclipse
Comment #12
dsnopekIs there any way we could fast track review/commit of #2551633: Make variants into their own config entity? It's also blocking some important issues, including the massively important wizard changes!
Also, the patch on #2551633: Make variants into their own config entity removes all the code that EclipseGC doesn't like. :-) So, this patch would be much, much simpler after the other is merged.
Comment #13
japerryHere are some other changes based on EclipseGC's review. Still need one test done but lets see if this passes the others.
Comment #14
japerryComment #16
japerryTry it again.
Comment #19
tim.plunkettComment #25
tim.plunkettA couple bugs still. Since VariantBase now uses RefinableCacheableDependencyTrait, we cannot use it while extending.
Comment #27
tim.plunkettMore fixes.
Comment #30
tim.plunkettCommitted!