Using a translatable string as a category for field type is deprecated in drupal:10.2

You can see on https://www.drupal.org/pift-ci-job/2837276 → that the daily tests passed at 10.1 up to Jan 5th. Then when the core testing branch switched to 10.2 on Jan 6th we immediately got the deprecation messages and red test failures.

Looking at the CR I think the module might also need a address.field_type_categories.yml file. I don't know if the lack of this file was the cause of the tests still complaining of Using a translatable string as a category for field type is deprecated in drupal:10.2.0 even when the category is now updated to just category = "address",

Yes:

Where number is the category ID defined in core.field_type_categories.yml:

So setting "address" results in a broken reference if the same type is not defined in the yaml file.

Thanks for working on this!

Is there any reason why the gitlab pipeline is not triggered when I commit to the branch? I can see there are pipeline runs on this project.

The reason is that Gitlab CI file isn't yet committed to the branch. See 📌 GitLab CI Needs work .

Oh yes, sorry, I can see that it is very new work, the pipelines only started running yesterday.

Replying to #5 it seems that the new file address.field_type_categories.yml is not strictly needed. The latest test at 10.2 no longer has the deprecation messages now that I found the two other places where the translation was being done. There are now only 2 tests that fail, due to Ajax problems, and those are also in the main branch test at 10.2.

But it probably is worth creating a categories.yml, as I guess this is where the translation is done, for better UI.

Shortening the title somewhat, and updating the status.

Added new address.field_type_categories.yml
Ready for review.

So does this mean that a contrib which supports 10.2 and up without deprecations must have untranslatable categories for 10.1 and lower? That's fairly annoying. It's hard when core makes changes where there's no way to maintain wide compatibility.

Ahh, reading the CR there's a "BC layer" section → that explains how to do it. IMHO, we should. NW for adding HOOK_field_info_alter() for this.

Also, moving to a task. There's no bug, just a new deprecation to handle.

Ha ha, that BC layer was not there when I opened the issue, it was added on 9 Jan https://www.drupal.org/node/3375748/revisions/view/13354071/13370886 → So it looks like this will take a bit longer to fix?

I suspect that this deprecation has taken many contrib maintainers by surprise (me included) as I did not have up-coming deprecations being flagged on either the drupalCI nor Gitlab-CI tests when 10.1 was the default branch to test against.

The problem is that one of the modules I maintain has integration with Commerce, which requires the Address module. Both of these have this deprecation for translatable category, so the DrupalCI tests are now failing at 10.2.

It really wasn't that bad. 😉 Tested manually on 10.1.x-dev.

Hah, but local testing uncovered a bug in 10.2.x with all this new UI: 🐛 Field type plugin description is assumed to be an array Fixed

Yay, 🐛 Field type plugin description is assumed to be an array Fixed is now fixed. Not that it needed to block this, but it's nice that it's done. This is clearly working, and the fact that the D10 tests are failing in DrupalCI is annoying and misleading. Committed to 2.x and cherry picked to 2.0.x and 8.x-1.x.

Thanks!
-Derek

dww → closed merge request !38

Thanks. At least the D10.2 test failures on drupalCI have reduced from 13 down to 1

Scheduler has a 'next minor' gitlab pipeline with deprecations being shown not suppressed, so I will check when you next make a release, that the warning is gone. But I know it will be :-)

Commerce has the same problem, but it's not fixed yet
📌 Using a translatable string as a category for field type is deprecated in drupal:10.2 (Commerce) Active

Yup, I had already opened a tab for an issue about that remaining deprecation. Fixed at 📌 JSWebAssert::assertExpectedAjaxRequest() called unnecessarily in ZoneTerritoryElementTest::testZoneTerritory Fixed

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