[10.2] PHPUnit errors: non-existent service plugin.manager.field.field_type_category

Yes, there was a change in core Drupal. These are unit tests, and Drupal is now using a service it didn't use before. What needs to be done is to add a service mock in the test base class.

Thanks a lot Tim (@TR)!

Based on your instructions I was able to take an initial stab at this issue and the changes are now ready to be reviewed in ticket's merge request MR!26.

In the last build:
https://git.drupalcode.org/issue/rules-3425542/-/pipelines/184562

The issue seems to have disappeared from the PHPUnit job:
https://git.drupalcode.org/issue/rules-3425542/-/jobs/1712331

Taking the failing tests down from 124 to 3 🎉 \o/

I haven't looked at the remaining errors yet, but assume they wouldn't necessarily be "too" difficult to fix.
If you think it would be worth looking into them and try fixing them as well in the same MR, please let us know.

Otherwise, I suppose this merge request should fix at least the issue describe in this ticket.

We would greatly appreciate if you could please try testing, reviewing the changes and give us your feedback.

Feel free to let us know if you have any questions or concerns on any of the changes in this merge request or the ticket in general, we would certainly be happy to help.
Thanks in advance!

The core change seems to be \Drupal\Core\Field\FieldTypePluginManager::__construct now requires FieldTypeCategoryManagerInterface → ?

In which case this patch will only work for versions of core >= 10.2.

Because core Drupal 9.x is no longer supported, when this change is made the Rules dependencies should probably be raised to 10.2+ so that this D9-incompatible change won't break things.

Thanks a lot Tim (@TR) for your prompt reply and for finding the corresponding change record.

As suggested, I went ahead and updated the version requirement of the module to "drupal/core": "^10.2".

As a follow-up task, I've added 📌 Support drush ^12 commands Active , looking at the line "drush.services.yml": ">=9" in the composer.json, that could most likely be removed, since drush ^12.4.3 would now be required.

Once again, we would greatly appreciate your reviews, advice and feedback.

Feel free to let us know if you would see anything else or more work needed on the merge request MR!26 or the issue in general, we would be happy to help.
Thanks!

Hi Tim (@TR),

Just wanted to mention I've come across similar issues with deprecated code or functions in newer versions of Drupal Core.

It's probably not the first time you've faced this but I'd like to share what I was able to find on the topic:

If it helps, I found the following posts:
https://mglaman.dev/blog/drupal-module-semantic-versioning-drupal-core-s...
https://www.drupal.org/project/ideas/issues/3357742 🌱 Guidelines for semantic versioning and Drupal core support Needs review

Basically, accordingly to Matt's blog post, since the current version of the module is already compatible with D10 (Major), it would make sense to create a new minor development branch, in this case 3.0.x or 3.1.x which would drop support for D10.1, thus support D10.2 and above.

If you'd like to keep backward compatibility in the same development branch, we could always modify the patch to add cases on \Drupal::VERSION and have code for previous and future versions in the same file, for example, see what we've done for block_class:2.0.x:
https://git.drupalcode.org/project/block_class/-/blob/2.0.x/src/Controll...
or in tests:
https://git.drupalcode.org/project/block_class/-/blob/2.0.x/tests/src/Fu...
and it works ==> Tests fixed with a broad coverage, see pipeline:
https://git.drupalcode.org/project/block_class/-/pipelines/191822
with multiple Drupal core versions being tested/supported.

This code is mostly inspired from the admin_toolbar module, which tends to be very strict and careful with backward compatibility given the popularity of the module and probably the wide range of Drupal core versions using it.

However, as soon as the current block_class:2.0.x branch is stabilized and we've fixed more major or critical issues, I believe the correct way to move foward would be to create a new minor release development branch which will drop support for 10.1, just like it is suggested in Matt's post.
See also a very similar problem we've been facing with a merge request for the block class module #3412155-11: Deprecated system_get_module_admin_tasks in drupal:10.2.0 and is removed from drupal:11.0.0 → .

Probably the same comment stands for the related Honeypot issue 📌 PHPUnit: Fix Functional Tests 'HoneypotFormCacheTest' Needs review and probably any change related to code deprecation and backward compatibility in general.

These types of issues are very tricky and definitely not as straight forward as we could think.

If you have other ideas, advice or suggestions, I would be very happy to hear your feedback, since I'm also maintaining quite a few modules which necessarily come across the same type of code deprecation issues.

Feel free to let us know if you have any questions, suggestions or if we could do anything to help, we would surely try answering as soon as possible.
Thanks in advance!

The 8.x-3.x branch will not be supporting D10.3+

Going forward, the new 4.0.x branch is dropping support for D9 and requiring D10.3+, and will provide support for D11.

So this issue is only going to be addressed in 4.0.x.

Working on getting the branch configured and the tests running now ...

I have verified, by re-testing in GitLabCI against D10.3, that the MR does fix the failures of the kind You have requested a non-existent service "plugin.manager.field.field_type_category"

There are still other failures, so the tests don't currently run green.

I think all that this needs now is to rebase the MR against 4.0.x and remove the dependency changes - those will be handled in another issue. I will be doing this myself later tonight.

Thank Tim (@TR) once again for your prompt and very clear follow-up on this issue.

Feel free to let us know if there is anything we could do to help, re-rolls, rebase, or any other change that would be required in the merge request.

Thanks in advance !

Thanks for your help DYdave!

Merged!

Thanks a lot Tim (@TR)!
Great job on creating the new major branch and all your updates in other tickets!

Now this issue is fixed in 4.0.x, we will get back to working on related honeypot ticket to pass the tests.
When I get a chance, I'll try taking a look at the Drush related ticket as well.

Thanks again!

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