[meta] Convert all core plugin types to attribute discovery

The blocker is committed.

Meta question, is this enough of a meta issue to encompass the entirety of moving from annotations to attributes, or should we also open a parent 'plan' issue that encompasses this and any other attribute issues that come up (like deprecations and so on)?

I think we should start by opening child issues here to finish off actions (only needs deprecations now?) and blocks (two remaining blocks plus deprecations?) and then go from there.

📌 Triggering deprecations for plugins using annotations when core plugin type has been converted to attributes Needs work will add deprecations for all plugin types that use the BC-discovery automatically, doesn't need a separate issue for actions. Blocks maybe could use a separate issue, although the layout builder one kind of already has one issue.

IMHO this is enough for the meta issue to cover relate tasks as well?

Added 📌 Triggering deprecations for plugins using annotations when core plugin type has been converted to attributes Needs work as a child as it seems the best place for it right now.

I'm a bit unsure if we should wait on rector to do at least the bigger ones. I guess entity is by far the most complex with 100+ very large attribute definitions. @andypost started something there, but unsure how feasible it is to have something that works in a reasonable timeframe, this is far more complex than most deprecations.

This is something we have to be aware of with this change. As necessary as it is to remove doctrine annotations and as much better the new DX is, this might be the single biggest deprecation that we've had since 8.0 (deliberately excluding some pre 8.0 things). There's barely a module out there with not at least a single plugin and *many* contrib modules defining their own plugin types that other contrib modules will first need to wait to support attributes, sites will break when updating the wrong module first and dependency versions aren't clearly defined. This is going to be painful.

One thing to consider I guess is to fork the doctrine stuff even further so we keep support for Annotations until D12?

@berdir @longwave just opened a new issue to discuss that 🌱 [policy, no patch] Allow both annotations and attributes in Drupal 11 Active

Added child issues for all plugin types except \Drupal\plugin_test_extended\Plugin\Annotation\PluginExtended which we can sort out later.

Updated issue summary with list

Unless I am mistaken, there is also the views handler, \Drupal\views\Plugin\ViewsHandlerManager.

Updated IS with link to https://github.com/palantirnet/drupal-rector/pull/257

@bbrala polished 10.2 conversions already

@quietone yes, views plugins are the last and could use own META

Added 🐛 Block attribute class expecting wrong ContextDefinition Active which may also impact other plugins too

Added 🐛 Fix @param docs for $deriver on plugin attribute classes Needs review

I realized that we forgot about another generic plugin feature beside deriver, the provider. It isn't used a lot in core for obvious reasons, but it's a valid use case to implement a plugin if another module exists. There are some challenges with it in case it depends on base classes/traits like \Drupal\layout_builder\Plugin\Block\InlineBlock (which doesn't use provider because the deriver kind of takes care of that but it would be if not using a deriver)

\Drupal\book\Plugin\migrate\destination\Book is another example in core, which has been made redundant due to the move to book module, and it's being removed in 📌 Convert MigrateDestination plugin discovery to attributes Postponed .

The most common use case is contrib modules providing plugins for core or other contrib modules that may or may not be there. entity_browser does that for some of its plugins, linkit does it, pathauto for forum module, and our monitoring project. Those cases are all for their own plugin types, so those modules are absolutely free to define it, but it won't be possible to do it directly in the attribute for core plugin types. There are not many examples that would need that, one that I found is https://git.drupalcode.org/project/crop_image/-/blob/1.0.x/src/Plugin/Fi..., which provides a field widget plugin if entity_browser is enabled.

Not sure what we should do about that :)

This is releasing very soon:

https://github.com/palantirnet/drupal-rector/blob/2cc2787bd323406b7da4f4...

Tracked in this PR: https://github.com/palantirnet/drupal-rector/pull/296

Tested on this issue: https://www.drupal.org/project/drupal/issues/3396166 📌 Convert entity type discovery to PHP attributes Needs review (see the MR for the automated branch)

Released here:

https://github.com/palantirnet/drupal-rector/releases/tag/0.20.1

Includes usage docs for Core conversions. Hopefully it helps speed things up.

Added 7 more views plugin types for conversion

Fun fact, you can run the rector on an existing MR to check if something was missed. It will skip over any classes already implementing the attribute.

Sorted the task list a bit

Added 📌 Update Drupal\Component\Annotation\Doctrine\StaticReflectionParser::hasClassAttribute() to allow attribute subclasses Active to the list to handle subclasses.

Issue summary updates: Remove Tip from the issue summary because it will be done in contrib. And added 📌 Triggering deprecations for plugins using annotations when core plugin type has been converted to attributes Needs work .

Earlier this week I did a check using a branch with all converted plugins in rector against head.

https://github.com/palantirnet/drupal-rector/tree/feature/annotation-rules

Good news, there were no conversions missing.

@Berdir sent me a message there were a few missing.

Examples:

PreviewAwareBlock
AnnounceBlock

So i've looked into why this is. Might be me doing not smart things while scripting.

Ok, i've done a booboo when making the script. Aftersome tweaks:

AnnounceBlock.php
InlineBlock.php
PreviewAwareBlock.php
TestXSSTitleBlock.php

The BooBoo were a few things:

My config added classes instead of the annotations. Rector didnt like backslashes before the classes, so did some extra normization actions. I'll push how i ran on core to a branch here.

Compare changes on GitLab

@bbrala great job! Looks only formatting left to apply and it could be reused for contrib!

Added 🐛 Move content_translation I18nQueryTrait to migrate module Active to the remaining tasks for visibility, because it's a blocker for 📌 Convert MigrateSource plugin discovery to attributes Active .

Tagging this so it's easier to find in 'things that would be good to do for 11.0/10.3 beta'.

This may be the wrong place for this (apologies if so).

The change record and documentation state Drupal 10.2.0 plugins should start using attribute-based instead of annotation-based plugins, but the core plugins don't actually support attribute-based discovery until 10.3.x. Can there be more clear documentation stating it's not well-supported yet until 10.3.x?

Relevant links:
- https://www.drupal.org/node/3403921 → (10.2)
- https://www.drupal.org/node/3395575 → (10.2)
- https://www.drupal.org/node/3229001 → (10.3)

I think the actual conversion is done now that 📌 Convert MigrateSource plugin discovery to attributes Active is in.

Next steps are 🌱 [policy, no patch] Allow both annotations and attributes in Drupal 11 Active and 📌 Triggering deprecations for plugins using annotations when core plugin type has been converted to attributes Needs work afaik.

Rebased and updated 📌 Triggering deprecations for plugins using annotations when core plugin type has been converted to attributes Needs work , next step is removing the simple remaining conversion that we missed into separate issues. That now also includes a deprecation for plugin managers that only provide an annotation class. That passes now, there was a single deprecation caused by a special test plugin manager which is now updated too.

So yes, I can confirm that core is now fully converted to attributes, minus the small bits in that issue.

As for this meta, I agree that 📌 Triggering deprecations for plugins using annotations when core plugin type has been converted to attributes Needs work is essential but IMHO, 🌱 [policy, no patch] Allow both annotations and attributes in Drupal 11 Active is not a child of this critical task but a follow-up. It is not required to get rid of annotations, "only" a performance improvement, and it will only become realistic for most sites once majority of contrib projects have caught up with this.