Missing config schema for core.base_field_override.*.*.* third_party_settings.content_translation

Completed the IS.

Left a todo in the steps to reproduce as I'm not seeing the issue.

Thank you for the additional steps. I can confirm the issue with Media type.

But applying patch #4 does not fix the issue, cleared cache multiple times too.

This may need a test case too but trying to figure that out.

I can also confirm this issue. config_inspector is very helpful to make it visible for different content types.

re #8: You might need to re-save the media type again for the string types to all get saved in accord with the schema format.

Do we need an update hook to resave all base field overrides again? I think that would be more disruptive then not.

MR should be updated to 11.x

But if re-saving is needed to get to work then probably would need an update_hook, using batch API

They don't need to be re-saved to work. But rather to get the "right" order per the schema and convert any 1 => true, etc. But if we add a hook update, then it will cause a resave of all base fields, which is very disruptive. Many times that config doesn't even exist as an exported config. But if we force loading/saving, we'll add lots of noise/files and create possible confusion.

but without the re-save the problem isn't fully fixed though?

In our case, it was resolved without the need to re-save.

The values added were:

third_party_settings:
  content_translation:
    translation_sync:
      file: file
      alt: '0'
      title: '0'

The MR patch works for me in Drupal 11.2+, though to me this doesn't work without re-saving because in the case of "file" the stored value is integer 0, and it still causes the following error:

variable type is integer but applied schema class is Drupal\Core\TypedData\Plugin\DataType\StringData

After re-saving, the 0 values get converted to string '0'
So, we might need an update hook.

I've rerolled the MR to target 11.x, as well as added a post update hook to only resave base field overrides which have the content_translation third party settings.

The resave occurs within the callback because the entity data is still untrusted as far as we're concerned.

Yay main, rerolling

Thanks!

Would like some feedback here from others regarding the do or do not save issue.

Apparently there was some question as to whether this needed tests (#8), but update paths do require tests. So I'm setting the status to Needs Work for that.

Added static patch including the post update hook.

Affects Canvas too: https://git.drupalcode.org/project/canvas/-/merge_requests/882/diffs?com... was forced to forward-port this.

This is now causing errors in contrib testing since #3606969: Content translation column group settings only show up once there are base field overrides saved landed.

I don't think we should hold this back on upgrade path tests. They are tricky beasts and this is using the ConfigEntityUpdater class so things are pretty standardised. Also saving config without schema is now deprecated so configuration in modules will be automagically fixed during install too.

Code looks perfect to me, I wouldn't change a comma.

Triggered the test-only test - https://git.drupalcode.org/project/drupal/-/jobs/10641177 - which shows that the updated \Drupal\Tests\content_translation\Functional\ContentLanguageBaseFieldSyncWidgetTest::testBaseFieldSyncOptionsVisibleOnFirstLoad() now fails.

Committed and pushed 22c7a860b85 to main and 1663b3a807f to 11.x and 93d8061f073 to 11.4.x. Thanks!

Yay!