Convert plugin annotations to attributes

Created on 10 April 2024, 5 months ago
Updated 24 August 2024, 14 days ago

Core is currently moving from using Doctrine annotations for plugin discovery to using PHP 8 attributes, so we should do the same thing both for the plugin types we define and the plugins we implement. (Not all Core plugin types have been converted yet, though, so need to wait for the latter.)

Postponed since thie will have to wait until we depend on Drupal 10.2+.

See the change records:

📌 Task
Status

Postponed

Version

1.0

Component

Framework

Created by

🇦🇹Austria drunken monkey Vienna, Austria

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @drunken monkey
  • Status changed to Active 17 days ago
  • 🇺🇸United States TR Cascadia

    Re-opening.
    Annotation is supposed to be dropped in D11.
    Attributes are supported for everything as of D10.2, and core plugins have all been converted to Attributes as of D10.3.
    I can make a MR if this is something you're willing to do now, just let me know. Or set it back to postponed if you're not interested.

    Perhaps this goes into a 2.0.x branch, so that other modules and sites that have their own search_api Plugins

  • Status changed to Postponed 15 days ago
  • 🇦🇹Austria drunken monkey Vienna, Austria

    Thanks for re-opening!

    However, I’m not sure whether depending on Drupal 10.2 is actually enough for us, since it seems in that Core version only two plugin types had been transitioned to use attributes, neither of which we use in this module. It seems like we should wait until we depend on Drupal 10.3 to do this switch, since then we could at least convert all plugins except entity types (which are still missing, see 📌 Convert entity type discovery to PHP attributes Needs review ).

    If you want you can already create an MR for sure, there shouldn’t be too much we’d need to adapt until December, but I wouldn’t merge this until we move to depend on Drupal 10.3 when 10.2 supports ends, i.e., mid-December 2024.

    Perhaps this goes into a 2.0.x branch, so that other modules and sites that have their own search_api Plugins

    Instead of opening a 2.x branch for this I’d like to keep this backwards compatible, i.e., allow both attributes and annotations for a while (probably as long as Core does). Not sure if it’s possible to trigger deprecation warnings when the annotation is used (doesn’t seem like it, as Core doesn’t do that either as far as I can tell), but if so that’s also something we should do.
    We can then add a note to the release notes to say that the 2.0.0 version of the module will drop support for plugin annotations (whenever we’ll get round to start work on that).

    Probably we should then also have some test plugins that use annotations instead of attributes, to make sure those indeed keep working as they should.

  • 🇺🇸United States TR Cascadia

    Thanks. I was asking because it's a bit of work, and if it's not going to be used/needed/wanted in the near future it's not really worth doing now because I'll have to keep rebasing the MR to try to keep it relevant. I have converted something like a dozen different plugin types to Attributes, so I am already familiar with the process and it would be relatively straightforward for me to do this now. But as time goes on all the little details are going to get fuzzy ...

    Actually, in D11, all but one or two of the Core plugin types have been converted to Attributes already, and those few are being worked on. See 📌 [meta] Convert all core plugin types to attribute discovery Active . I think search_api uses a *lot* of Core plugin types. Especially Views plugins. And search_api of course defines its own plugin types.

    I'm not so worried about whether it's 10.2 or 10.3, I think my concern would be that Annotation discovery is set to be REMOVED in D11, at which point your module will stop working in D11. I personally find it easier to take the time and get things like this put into place before the deadline, rather than having to scramble to get the module working again when that deadline comes.

    My strategy has been to keep both the Annotations and the Attributes in all plugins during the transition. The plugin managers, since they extend DefaultPluginManager, *can* support discovery via both mechanisms, but these plugin managers do need to be updated to pass the new Attribute class to the parent constructor in order for this to work. Doing it this way reduces the risk of disruption IMO. The annotations will have to be removed eventually, but that doesn't have to be done until Core completely stops supporting them.

    Perhaps this goes into a 2.0.x branch, so that other modules and sites that have their own search_api Plugins

    Looks like I didn't finish my sentence here. The point I intended to make is that converting from Annotations to Attributes affects contrib modules that define their own search_api Plugins (one of those modules is maintained by me, which is why this subject interests me). Managing the transition between Annotations and Attributes will be easier for these dependent modules if there is a major version transition, so that contrib modules can set their dependency on search_api to the appropriate version. Replacing Annotations with Attributes is (to me) an API change that is problematic to do in a minor version release. Although that's what Core did (between 10.2 and 10.3). But Core's removal of Annotation discovery for certain Core plugins in a minor point released caused me a LOT of problems, so I'm particularly sensitive about NOT causing these problems when I transition my own plugin types from Annotations to Attributes.

Production build 0.71.5 2024