Problem/Motivation

Multiple things are moving to PHP Attributes. Plugins, Entities, REST resources, PHPUnit. Maybe a few more things. Let's convert to PHP Attributes in a BC manner so we still support Drupal 10.3, but also set ourselves up well for Drupal 12 or 13 when Attributes are the only supported mechanism.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork migrate_plus-3541220

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

heddn created an issue. See original summary.

heddn opened merge request !139

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Status: Active » Needs review

Thanks to Tag1 for providing a small budget to explore AI. I used Claude mainly. Initially I asked it to convert all the things. That seemed too much in one pass. So then I asked it to suggest a Rector configuration that would help here. It did a decent job, but then I was still left with fully importing class names manually. Of note, rector didn't seem to want to update/convert all of the PHPUnit attributes. I tried to convince it, even pulled out xdebug to see why it was ignoring some of the conversions for the @covers* cases. But to keep thing moving (and so I didn't fall prey to the issue where AI actually _slows_ things down) I opted use PHPStorm's automation to quickly and manually convert the few remaining phpunit annotations.

  • heddn committed d7d3c692 on 6.0.x 
    chore: #3541220 Annotation to PHP Attributes conversion

By: heddn
heddn’s picture

heddn
Primary language English
Location Nicaragua
commented
Status: Needs review » Fixed

Lets land this. Its very disruptive. But it will always be disruptive. And much of the RTBC queue is cleaned out right now, so this is about as good as it gets.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented

I read in https://www.undpaul.de/en/blog/2026/01/20/converting-php-class-annotatio... this is very disruptive and:

Old annotation-based plugins will not be discovered and will cause migration failures.

Is this truly the case? I thought that with listing Drupal 10.5 as minimum drupal core version and core's ability to support both annotation and attributes at the same time, that other custom or contrib modules could still maintain annotations without any more effort. Can anyone report to the contrary with steps to reproduce?

prudloff’s picture

prudloff commented

I also saw this article and was surprised to see such a breaking change in a patch release.

I tested quickly and AFAICT \Drupal::service('plugin.manager.migrate_plus.data_fetcher')->getDefinitions() still returns plugins defined with an annotation.

steffenr’s picture

steffenr
Primary language German
Location Bremen
commented

Which Drupal version are you running?
We discovered the problem with our Drupal 10.6 installations.
I'll recheck with the latest 10.5.8 release later and update the blog post accordingly, if this was the "real" cause of the problem.

steffenr’s picture

steffenr
Primary language German
Location Bremen
commented

Just a quick udpate on the issue with steps to reproduce:

  • clean Drupal 10.5.8 installation
  • modules installed: migrate, migrate_plus and my custom migrate_plus DataParser plugin
  • use PHP Annotation in migrate_plus DataParser plugin and run drush ms will result in error
    Could not retrieve source count from my_custom_migration: The "my_custom_json_path" plugin does not exist. Valid plugin IDs for Drupal\migrate_plus\DataParserPluginManager are: json, json_subitem, simple_xml, soap, xml
  • use PHP attributes in migrate_plus DataParser plugin and run drush ms works as expected and won't throw an error
heddn’s picture

heddn
Primary language English
Location Nicaragua
commented

There was a quick followup in #3565462: Syntax error in DataParserPluginManager. Its landed for a while. I just noticed I hadn't tagged a new release though, so I've release it now with https://www.drupal.org/project/migrate_plus/releases/6.0.10

If you can still reproduce the issue after updating, let's open a new issue and link it back here so we can further investigate.

steffenr’s picture

steffenr
Primary language German
Location Bremen
commented

@heddn Thanks for your quick response. Updating to version 6.0.10 of the module solves the issue and the error i described cannot be reproduced anymore.
I'll update the blog post accordingly.

heddn’s picture

heddn
Primary language English
Location Nicaragua
commented

I'm relieved. Thank you for your blog post too. It will help others who are also facing this situation. Plus its a great walk through how to upgrade from annotations to attributes. I also found that using PHP Rector was very useful in this space too.