I'm relatively new to this module and have been using it for a short while. As a site editor I often add media to a wysiwyg field (like node body) after choosing the view mode for the media, which directs the properties of usage. However, I think there would be instances where I would like to override the properties of the media such as alt & title text, or perhaps even the height and width of an image for example. I wouldn't want to create a separate file view mode just for that one instance. Nor would I want to overwrite the file's properties (alt & title) since its a one-off.
Would it be great to have a small icon placed on top of media inserted into a wysiwyg field, such that clicking on the icon would bring up a form to edit the properties of that media instance alone?
This is very similar to #1291518: Use Field Formatters for Embedding Options, however it applies for the current instance of usage only, not the actual file entity or file view mode.
In effect, the main things that I think is needed for this is:
- JS (e.g. media.image-instance.overlay.js) to add edit-icon on embedded media, which on-click pops up a media instance edit form
- Menu callback for the above form that, based on the file mime returns form with appropriate fields (like alt, height, title etc.)
- In wysiwyg-media.js: Add a new element called 'instanceoverrides' to the tagContent variable when creating the JSON in the 'detach' function:
tagContent = { "type": 'media', "instanceOverrides": instOver, // @todo: This will be selected from the format form "view_mode": attributes['view_mode'].value, "fid" : attributes['fid'].value, "attributes": mediaAttributes };
- media.image-instance.overlay.js to convert submitted form values of the instance edit form into the tagmap. Sample js for this is attached.
-
function media_token_to_markup() {}
in media.filter.inc to consider the 'instanceOverrides' property in $tag_info and merge it with $settings, such that the instanceOverrides take priority.
- Now, users can examine the file object during load, and it should have the values of the instanceOverrides in the
$file->override
array and can be used in the appropriate tpl.
I believe this would add value to the good work done in this module so far.
Comment | File | Size | Author |
---|---|---|---|
media.image-instance.overlay.js_.zip | 2.27 KB | girishmuraly |
Comments
Comment #1
CBThis might be what you need? #1307054: Accessibility - Media browser image alt and title fields
Comment #2
mrfelton CreditAttribution: mrfelton commented#1307054: Accessibility - Media browser image alt and title fields (or actually, #1553094: Alt and Title support for Images I think) does solve part of the problem of being able to override alt/title attributes fgor an individual embedded media instance. But, I think this ticket is about more than that. This is about being able to edit a media embed after embedding it. Currently, once you have embedded the image there is no way to edit it's properties at all. What if you made a mistake when typing the alt or title text. What if you selected the wrong image style? How do you edit those things? Currently the only way to do this is to delete the embedded image, and re-embed. It's a very bad usability issue.
The idea of having a small icon placed on top of media inserted into a wysiwyg field, such that clicking on the icon would bring up a form to edit the properties of that media instance would solve this problem very nicely. Either that, or a contextual menu that you get by right clicking on the image, with an 'edit' option which brings up the settings for the media instance.
Comment #3
girishmuraly CreditAttribution: girishmuraly commentedYes I'm more in line with @mrfelton
Comment #4
Dave Reid@mrfelton: I think this is covered by #835516: Add ability to edit file meta data and fields when embedded in WYSIWYG already.
Comment #5
loparr CreditAttribution: loparr commentedHi,
Is this issue resolved? I have installed latest dev relase of media module but after embedding an image inside editor, I can not see any option to edit the image back - for example to change it's style. I am missing something? Thank you
Comment #6
kumkum29 CreditAttribution: kumkum29 commentedHello,
I have the same problem in my site. After to have inserted an image in the text, I haven't any solution for edit this image (view mode, alt text...).
Have you found a solution ?
Thanks for your help.
p.s: I use the CKeditor module not the Wysiwyg API module. So i don't see the edit button for the media. The problem comes from CKeditor module?
Comment #7
kumkum29 CreditAttribution: kumkum29 commentedHello,
if we use the Wysiwyg module (+CKeditor editor), we can edit the image inserted in the text.
The functionnality seems not to be active if we use the CKeditor module.
Comment #8
Devin Carlson CreditAttribution: Devin Carlson commentedComment #9
chiebert CreditAttribution: chiebert commentedDitto @kumkum29's observation: the behaviour added in #835516: Add ability to edit file meta data and fields when embedded in WYSIWYG does not seem to be working if we're using the Ckeditor module (vs. WYSIWYG module + Ckeditor library). I'm using
Media 7.x-2.0-alpha4+30-dev (2015-Mar-31) with patches #2333855-7: Media Browser Settings for "WYSIWYG" aren't respected with CKEditor Module (e.g. browser tabs) and #2401811-11: With Media WYSIWYG enabled - "Contextual links" are shown for anonymous users
Ckeditor 7.x-1.16+9-dev (2015-Apr-01)
Ckeditor library 4.3.2
The modal that pops up when I try to edit an existing embedded image seems to re-load the original values for that media entity - and in addition, since I have two view modes enabled via media_wysiwyg_view_mode, the originally-selected view mode is not the one that is selected in the modal form. Instead, the first one in the list of available view modes is chosen as the default...
Saving the form seems to save whatever new view mode I've chosen, but any other changes (alt, title, custom caption field) are not saved.
Comment #10
pramodganore CreditAttribution: pramodganore commentedSimilar issues here
Comment #11
chiebert CreditAttribution: chiebert commentedRan a debug trace within media_wysiwyg_view_mode_form_alter() when calling up a popup for a previously-embedded piece of media (an image, in this case)...
Original conditions:
Variables when media_wysiwyg_view_mode_form_alter() is called for the above-mentioned media entity:
So, I'm seeing two problems here so far:
Does anyone know where one would set 'media_wysiwyg_wysiwyg_default_view_mode' in the current code base?
Comment #12
chiebert CreditAttribution: chiebert commentedJust want to confirm that I tried all this again on a clean install using just the bare file_entity-7.x-2.x-dev and media-7.x-2.x-dev modules, plus the Ckeditor module and library as above, and the stock view modes. Same results: $form_state['values'] isn't set, and $_GET['fields'] is set to 'undefined'. $view_mode is eventually set to 'full', but since that's not one of the allowed view modes, it defaults to the first one on the list. Select a new view mode, and that's saved, but changes to other form values (just alt and title, in this case) are not saved.
Comment #13
chiebert CreditAttribution: chiebert commentedSimilar behaviour if I try to embed a new entity from the media library: I get the popup form, but the only thing that appears to save is the choice of view mode. Changes to the alt, title and other custom fields are not saved - or, at least, are not converted back into the tag that's inserted into the textarea. Continuing to dig, but the interaction of the js and the php code is stymieing me. Any hints as to how the tags are handed up to the modal and then back again would be appreciated...
Comment #14
gmclelland CreditAttribution: gmclelland commentedShould this issue be renamed "Ckeditor module - Edit media embeds in Wysiwyg textarea"? It might make it a bit more clear.
Comment #15
chiebert CreditAttribution: chiebert commentedQuite possibly.
Another day, another run at getting field changes to load and save for previously uploaded/embedded images. Here's what I've just tested:
The main new piece for me is #2348439-5: Allow dynamic WYSIWYG markup.
What works:
What doesn't work:
Supposedly all this was fixed back with #835516-97: Add ability to edit file meta data and fields when embedded in WYSIWYG was committed, but if so, then something has broken since then, at least for Ckeditor Module users. I'm in the process of reading that code in more detail to see how it works, and to see what might have changed between then and now... I'll also try and test if WYSIWYG module + Ckeditor library does any better. I recently switched from that stack to straight-up Ckeditor thinking it would lighten the load, especially in view of the fact that D8 has gone to a single integration point with Ckeditor...
Comment #16
mgiffordComment #17
joseph.olstadall related issues are closed (fixed) except
#2348439: Allow dynamic WYSIWYG markup
marking this as fixed, otherwise follow up in:
#2348439: Allow dynamic WYSIWYG markup
or open a new issue
Comment #19
mgiffordThanks @joseph.olstad