Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Similar to #1810480: Provide the plugin_id to support views metadata integration, we will benefit from also having the module that implemented or owns the plugin.
This is in preparation for what we will do with broken/missing handlers. Which is also related to #1823608: Admin views in core.
Postpone on this #2016953: Indicate when an optional handler is missing, that it is not "broken"
Comment | File | Size | Author |
---|---|---|---|
#38 | 1825896-38.patch | 133.67 KB | damiankloip |
#38 | interdiff-1825896-38.txt | 7.59 KB | damiankloip |
#35 | drupal-Views-module-owner-1825896-35.patch | 134.26 KB | heddn |
#35 | interdiff.txt | 3.67 KB | heddn |
#33 | drupal-Views-module-owner-1825896-33.patch | 133.14 KB | heddn |
Comments
Comment #1
damiankloip CreditAttribution: damiankloip commentedComment #2
damiankloip CreditAttribution: damiankloip commentedThis should be very quick to implement, we just add this to addItem.
Now we just need to add this to all the current YAML files.... *Looks at dawehner*
Comment #3
dawehnerUpdated all the yml files with the script in the attachment.
Just linking an issue with does something related but at the exact space in code. #1810480: Provide the plugin_id to support views metadata integration
Comment #5
dawehnerLet's postpone this on #1810480: Provide the plugin_id to support views metadata integration as it requires the same kind of assertions.
Comment #6
dawehner.
Comment #7
jibranAs per #5
Comment #8
xjmSee also: #1965164: Add a @PluginID annotation for plugins that only need an ID, like Views handlers
Comment #9
dawehnerHere is an initial patch, which also fixes some of the yml files, so my script could work.
Comment #11
dawehnerJust a rerole. (frontpage got changed)
Comment #13
dawehner#11: drupal-1825896-11.patch queued for re-testing.
Comment #15
dawehnerYet another one.
Comment #17
dawehnerIt's great to see that our test coverage works properly.
Comment #19
dawehner#17: drupal-1825896-17.patch queued for re-testing.
Comment #20
dawehnerNeeds 100% another rerole/another run of the script.
Comment #21
damiankloip CreditAttribution: damiankloip commentedIt's not that easy to get the actual module owner anymore, so I opened #2022087: Add module owner to plugin definition in AnnotatedClassDiscovery. This is pretty dependent on that I would say.
Comment #22
jibranBack to need work. #2022087: Add module owner to plugin definition in AnnotatedClassDiscovery is committed.
Comment #23
damiankloip CreditAttribution: damiankloip commentedOK, here goes.....
Now that issue dep (in #21/#22) is in, we can try this again. After that got in though, I realised that views' ViewsHandlerDiscovery actually extends the Component AnnotatedClassDiscovery and not the Core implementation, so we also need to change that too.
To make things easier, these are the changes in this patch that have been made to ViewsHandlerDiscovery:
The rest is just alot of small yaml changes.
Comment #25
damiankloip CreditAttribution: damiankloip commentedAnd with the actual code to add plugin ID to newly added handlers.
I also had to fix the failing UserDataTest. When I changed/added the module key for handlers, this failed as the options were storing 'module' for the module that user data should be loaded for. I changed these options to 'data_module' and 'data_name' - should pass now.
Comment #26
damiankloip CreditAttribution: damiankloip commented.
Comment #28
damiankloip CreditAttribution: damiankloip commentedIf changes in #2022087: Add module owner to plugin definition in AnnotatedClassDiscovery get in, we maybe want to change this too.
Comment #29
xjmSee #2022087-19: Add module owner to plugin definition in AnnotatedClassDiscovery and #20.
Comment #30
heddnLet's see how this goes.
Comment #32
damiankloip CreditAttribution: damiankloip commented#30, see comments in #28/#29
Comment #33
heddnThis seems to get us closer. But there are probably still a few errors on tests.
Comment #35
heddnI fixed an overlooked omission in views.view.test_user_data.yml from #25. Then I had to make some changes in WizardPluginBase.php. The changes made make sense to me, but I'd like another set of eyes.
Comment #36
dawehnerLet's get it in as fast as possible!
Comment #37
tim.plunkettNot sure if this tag does anything these days.
Because #1822048: Introduce a generic fallback plugin mechanism has left us in an unshippable state, and this blocks it, bumping.
Comment #38
damiankloip CreditAttribution: damiankloip commentedSorry, just a couple of things; The assignment of the provider in WizardPluginBase was still checking for 'module', there were also some missing 'provider' keys in the wizard extending classes.
Comment #39
dawehnerGood catch!
Comment #40
damiankloip CreditAttribution: damiankloip commentedComment #41
alexpottCommitted a4c65be and pushed to 8.x. Thanks!
Comment #42
andypostThis change is wrong! needs follow-up
Comment #43
dawehnerPlease post a new issue and tag it as novice.
Comment #44
andypostFiled #2039677: Fix 'provider' keys for comment wizard default filter definitions
Comment #45.0
(not verified) CreditAttribution: commentedUpdated issue summary.