Problem/Motivation
The Media Embed filter plugin currently removes contextual links from embedded media. The code mentions:
// - Contextual Links do not make sense for embedded entities; we only allow
// the host entity to be contextually managed.
However, I think the ability to contextually manage items is exactly why I'd rather embed media than insert an image directly in my content. For example, I could have an "Attribution" field on an image bundle, and want to provide users the ability to edit that attribution wherever that image appears. Same idea with some image style implementations that use cropping, if you are editing content, and see a weird crop in an embedded image, it's a much better UX to edit the image in place, than to click over to the media library, brainstorm what title search might correspond to this image, page thru results...
Proposed resolution
Add a checkbox to the settings form for the Media Embed filter that allows users to opt in to contextual links on embedded media.
Remaining tasks
Add the featureWrite tests?
User interface changes
New option on Media Embed filter settings form, defaulting to current behavior.
API changes
NA
Data model changes
Add new field to filter_settings.media_embed
File: core/modules/media/config/schema/media.schema.yml
show_contextual_links:
type: boolean
label: 'Show contextual links on embedded media to users with appropriate permissions if contextual module is enabled.'| Comment | File | Size | Author |
|---|---|---|---|
| #38 | 3174252-provide-option-to-show-contextual-links-for-embedded-media.patch | 5.91 KB | trackleft2 |
| #34 | media-embed-contextual-links-option-3174252-4.patch | 2.02 KB | schiavone |
| #33 | 3174252-nr-bot.txt | 90 bytes | needs-review-queue-bot |
Issue fork drupal-3174252
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
xaqroxHere's a patch. I'm not sure if this needs tests, I have very little Drupal testing experience but willing to try if necessary!
Comment #3
xaqroxOops, patch had wrong paths, this one should work...
Comment #4
staceroni commentedWhile you are reviewing a long-form article, that has many
<drupal-media>image embeds, and you come across a media item with extra fields, you should be able to use ContextualLinks to be able to jump into that Media item immediately.The comment
// Contextual Links do not make sense for embedded entitiesisn't clear on why it doesn't make any sense.So many things on a page -- blocks, menus, entity relationship fields -- support contextual links with the same "sense" as how I would like to be able to manage media within the body of a node.
Comment #5
staceroni commentedThe patch #3 causes a php warning
Notice: Undefined index: show_contextual_links in Drupal\media\Plugin\Filter\MediaEmbed->settingsForm() (line 187 of core/modules/media/src/Plugin/Filter/MediaEmbed.php).Comment #9
jvogt commentedThe php error caused by #3 is resolved with a cache flush. I'm not sure how to force a flush on a core update, so hopefully someone else can help out.
Comment #11
smustgrave commentedThis 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.
Comment #13
e.r.n.i.e commentedI applied the patch #3 successfully (Drupal 10.1).
👏 Thank you @xaqrox! This is an important UI improvement for my use cases.
Comment #14
4kant commentedPatch #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!
Comment #17
phthlaap commentedAdded tests and fix some issues of config.
Comment #18
smustgrave commentedStill needs submaintainer review but relooking and seeing the schema change realize will need an upgrade path + tests
Comment #19
phthlaap commentedTests already there. Can you help to suggest what is the upgrade path?
Comment #20
smustgrave commentedWhen 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
Comment #21
phthlaap commentedCan you please help provide sample code in any module?
Thanks.
Comment #22
phthlaap commentedComment #23
smustgrave commentedLeft a comment.
Comment #25
trackleft2I'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_embed filter section and seeing missing key.
2. running the update
3. exporting text format config and looking at the media_embed filter section and seeing key there.
Comment #26
trackleft2Created draft change record feel free to edit or update. https://www.drupal.org/node/3483890
Comment #27
smustgrave commentedWith the update hook will need it's own test case as well.
Thanks
Comment #28
trackleft2Added a new fixture database and test for update following this guide https://www.drupal.org/docs/drupal-apis/update-api/writing-automated-upd...
Comment #29
trackleft2Comment #30
smustgrave commentedLeft a comment on MR.
Comment #31
trackleft2The 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.
Comment #32
trackleft2I'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.
Comment #33
needs-review-queue-bot commentedThe 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.
Comment #34
schiavone commentedUpdated the patch for version 10.3.10
Comment #35
trackleft2Don't use the patch in #34 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.
Comment #36
schiavone commented@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?
Comment #37
trackleft2@schiavone the main difference between the patch and the merge request is the
core/modules/media/config/schema/media.schema.ymlfile, in which the data type is set tobooleanwhich creates a small discrepancy in the active config for anyone who updates from the patch to the merge request.This is because the patch in #34 sets the value as an integer.
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.
Comment #38
trackleft2Providing an updated patch without tests against the 11.x branch
Comment #39
smustgrave commentedThere's also filter.format.basic_html.yml files in standard and demo_umami profiles that will need to be updated.
Comment #40
seanbI don't remember why we thought contextual links did not make sense for embedded media. I think it is because the use cases are relatively complex. Not having contextual links for the simple use cases in core was ok for the moment. When embedding a document link, the contextual links seem like a bit of overkill, but when embedding a slideshow, or something complex like that, it totally makes sense.
My first feeling is it depends on the view mode / media type whether contextual links make sense. At least per media type. Can we change the configuration of the filter to allow which media types/view modes should have contextual links?
Maybe we should even move the configuration to the media type / view mode config so we can also use this for entity references for example?