Provide option to display contextual links on embedded entities

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

Tagging for tests as that will need to happen.
But also tagging for subsystem review as they may have different thoughts about if this should be implemented.

I applied the patch #3 ✨ Provide option to display contextual links on embedded entities Needs work successfully (Drupal 10.1).

👏 Thank you @xaqrox! This is an important UI improvement for my use cases.

Patch #3 applied cleanly in D 9.5.10 and in D 10.1.5
That´s exactly what I was looking for. Webmasters are now able to edit and therefore also to crop images...
Thanks a lot @xaqrox!

Added tests and fix some issues of config.

Still needs submaintainer review but relooking and seeing the schema change realize will need an upgrade path + tests

Tests already there. Can you help to suggest what is the upgrade path?

When making a schema change that would appear in config export an upgrade path needs to be included that will add that setting to existing sites, setting to null. Then a simple test for the upgrade path that
- checks config doesn't exist
- run updates
- checks config now exists with default vlaue

Can you please help provide sample code in any module?
Thanks.

Left a comment.

I've updated the test to comply with the latest coding standards.
I've moved the update function to a post_update.php file.
I've add batch functionality to the update.

I've tested that the update works locally and on an existing site by
1. exporting text format config and looking at the media_embet format section and seeing missing key.
2. running the update
3. exporting text format config and looking at the media_embet format section and seeing key there.

Created draft change record feel free to edit or update. https://www.drupal.org/node/3483890 →

With the update hook will need it's own test case as well.

Thanks

Added a new fixture database and test for update following this guide https://www.drupal.org/docs/drupal-apis/update-api/writing-automated-upd... →

Left a comment on MR.

Not sure we need a full dump like this. This doesn't need to be unique to umami and could probably use one of the existing figures in system.

The issue is that the standard recipe does not have a format that has a media_embed filter enabled.

OK, I'll do it the hard way.

I've updated the database fixture to include just what is added into the database when the media module is enabled plus two text formats that have the media_embed filter enabled.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Updated the patch for version 10.3.10

Don't use the patch if you intend to use this module as there is currently no upgrade path for changing the config schema data type.

If you do use the patch and then remove it, you should be able to fix your site configuration so that it matches the new schema by simply resaving the setting after updating the codebase.

@trackleft2 The only difference between the updated patch in #34 and the patch in #3 is an update of the line number that sets the default setting to show the contextual link. So should the same apply to both patches? If there's a problem with updating the schema should we create an update?

@schiavone the main difference between the patch and the merge request is the core/modules/media/config/schema/media.schema.yml file, in which the data type is set to boolean which creates a small discrepancy in the active config for anyone who updates from the patch to the merge request.

I haven't heard of creating an update for migrating from one version of a patch to another, so I wouldn't support that idea.

Providing an updated patch without tests against the 11.x branch