- Issue created by @drunken monkey
- Status changed to Active
10 months ago 5:38am 22 August 2024 - 🇺🇸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
10 months ago 10:14am 24 August 2024 - 🇦🇹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 Active ).
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 Postponed . 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.
- 🇦🇹Austria drunken monkey Vienna, Austria
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.
I’m aware of that, but that doesn’t help us at all as long as we support Drupal 10 (which we will for quite some time). I sincerely hope Drupal 11 won’t remove plugin discovery by annotations as long as they support versions that still rely on annotations for some Core plugin types, as that would be an absolute nightmare for a lot of contrib maintainers.
Or do you know if that is seriously being discussed? If so, is there a particular issue for that?
As far as I can see, annotations remain to be supported for all plugin types (except those added in Drupal 10.3+) even in Drupal 11.x HEAD.I also don’t quite understand your reasoning for wanting the addition of attributes to be restricted to a 2.x branch of the module. If we keep support for annotations, too (which we definitely will as long as possible), then what is the problem of adding the attributes in a minor release? You can depend on that in your modules just as easily as on a major release.
To summarize, I propose the following:
- Any time we upgrade our minimum supported Core version, convert all our plugins to use attributes where supported by that Core version. (I.e., I think for all except entity types once we depend on Drupal 10.3 in December 2024, and then convert the entity types once we depend, probably, on 11.1 (depends on when Core completes 📌 Convert entity type discovery to PHP attributes Active ).
- In the first such MR, also add attribute discovery for all our plugin types, but keep annotation support as well.
- Only when necessary to support the latest Drupal version (shortly before Drupal 12.0 gets released, I assume, if that drops annotation discovery support) drop the annotation discovery from our plugin types. (Or maybe not even then, if easy to support using
DeprecationHelper
. In that case we’d only drop support once our minimum supported Core version doesn’t support it anymore.)
Please tell me if you see any problem with that approach.
If not, it would be a great help if you could already work on that first MR that depends on Drupal 10.3, yes. (I’ll gladly help keep it up-to-date until we can merge it in December, but I don’t foresee many changes would be necessary.) Or, I guess, we can also do a first MR right away that only transforms our own plugin types, if you prefer. - 🇦🇹Austria drunken monkey Vienna, Austria
Note to self: Entity types were switched to attributes in 11.1, see 📌 Convert entity type discovery to PHP attributes Active .
- Status changed to Closed: duplicate
21 days ago 4:16am 3 June 2025 - 🇬🇧United Kingdom scott_euser
I think this is now a duplicate of the work that is mostly done in 🐛 Fix failing pipelines Active