Fix: The update to convert "numeric" arguments to "entity_target_id" is deprecated

Using a 10.3.x site and the config_update module → the differences report showed that for the Node and Media views, the user_page::display_options::arguments::uid::plugin_id has been changed from numeric to entity_target_id and there is a new key target_entity_type_id with a value of user

--- a/config/install/views.view.scheduler_scheduled_content.yml
+++ b/config/install/views.view.scheduler_scheduled_content.yml
@@ -1106,7 +1106,8 @@ display:
           not: false
           entity_type: node
           entity_field: uid
-          plugin_id: numeric
+          plugin_id: entity_target_id
+          target_entity_type_id: user

The tests now run OK at 10.3 (both locally and in pipelines), but every test fails at 10.2 with

Drupal\Core\Config\Schema\SchemaIncompleteException:
Schema errors for views.view.scheduler_scheduled_content with the following errors:
    views.view.scheduler_scheduled_content:display.user_page.display_options.arguments.uid.not
    missing schema,
    views.view.scheduler_scheduled_content:display.user_page.display_options.arguments.uid.target_entity_type_id
    missing schema

Quite confused. Nothing was backported to 10.2.X. I don’t see how this could possibly be causing any test failures. But it’s late and I’m not of my right mind, so I’ll try to look again when I’m sober and have had some sleep. 😂

Oh, I misread. Yeah, if you’re running against 10.3.x, you need to update any default views to use the new handler. Maybe we need another CR to clarify?

Thanks for the reply. I have updated the views .yml files so that the tests run and pass at 10.3 without the deprecation. But it has caused the tests to fail at 10.2

Nothing was backported to 10.2.X.

That might be the problem. I want the module to be compatible with 10.2 and 10.3. Is that possible?

That exception should only be thrown when strictConfigSchema is set to TRUE. Could you set it to FALSE, and then set it to TRUE again when 10.2 support is dropped (i.e. in about six months). Or... possibly conditionally set it based on Drupal core version?

Thank you @catch, yes setting strictConfigSchema to FALSE has solved it, running locally the tests pass at 10.2 now. I will do a conditional to set it based on core version, as I presume we want it TRUE for all versions 10.3+

When I get a moment when I’m not on my phone, I’ll try to update the CR for some additional clarity. But a few points here now that I’ve slept:

1. The change to fix the bug was to add new argument handler plugins that properly deal with entity references instead of using entity IDs as numbers. These made it into 10.3.x and up, but not 10.2.x and down.
2. If you ship a view still using numeric it’ll keep “working” as well as it always has.
3. You can’t change your default view to use the new plugin, strict config schema or otherwise, in 10.2.x since the new handlers do not exist there.
4. But what you can (and probably should) do is to ignore the deprecation warning in 10.3.x about it until you can safely drop support for 10.2.x and require at least 10.3.x.
5. This deprecation is about the fact that the automatic conversion to the new/shiny handlers will be removed in 12.0.x. So you’ve got plenty of time and things will be auto-converted for you.

So my recommendation for right now is to leave your views using numeric, tell GitLab CI to ignore the resulting depreciation notices until you’re ready to ship a release that requires at least 10.3.x, then you can convert your shipped views and reconfigure your pipelines to fail on depreciations (if that’s what you actually want). 😅

Thanks / apologies,
-Derek

Mentioned at the core issue, but maybe we want a quick follow up to silence this deprecation in 10.3.x so it only starts getting hit in 10.4.x when 10.2.x is no longer supported?

Thanks dww for the info in #9. Sounds like I should remove the strictConfigSchema=FALSE and also revert the change to the views.

I understand when you say that the new plugins were not backported to 10.2, but I am not seeing any error, and the views appear to work. What problem would I see? I'd like to expand the test coverage on the views we provide so that modifiying the view in this way would fail a phpunit test. But I can't see anything wrong in the UI, when using the view in 10.2 with the changed plugin.

Adding the core issue that introduced this change.