Edit media instance in Wysiwyg field [#1404084]

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

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Sydney

CreditAttribution: CB commented 23 July 2012 at 04:39

This might be what you need? #1307054: Accessibility - Media browser image alt and title fields

Comment #2

mrfelton CreditAttribution: mrfelton commented 26 July 2012 at 08:39

#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 commented 26 July 2012 at 11:24

Yes I'm more in line with @mrfelton

Comment #4

Dave Reid

he/him

English

Nebraska USA

CreditAttribution: Dave Reid commented 26 July 2012 at 18:58

Status:

Active

» Closed (duplicate)

@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 commented 7 October 2013 at 01:20

Status:

Closed (duplicate)

» Active

Hi,
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 commented 6 February 2015 at 18:13

Hello,

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 commented 8 February 2015 at 18:11

Hello,

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 commented 17 April 2015 at 17:43

Component:

Code

» Media WYSIWYG

Comment #9

chiebert CreditAttribution: chiebert commented 27 April 2015 at 18:54

Ditto @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 commented 27 April 2015 at 20:29

Similar issues here

Comment #11

chiebert CreditAttribution: chiebert commented 27 April 2015 at 22:53

Ran 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:

Modules:
- File Entity 7.x-2.0-beta1+29-dev (2015-Apr-21)
- Media 7.x-2.0-alpha4+37-dev (2015-Apr-24) patched with #2177893-14: Custom wrapper breaks tokens with CKEditor >=4.0 without widget plugin, #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) with Ckeditor library 4.3.2
Media WYSIWYG View Modes set to limit allowed view modes to media_original and em_img_caption (custom view mode), and to use em_img_caption inside the WYSIWYG.
Instance of embedded image is confirmed to have "view_mode":"em_img_caption" in the JSON string of the underlying media tag.

Variables when media_wysiwyg_view_mode_form_alter() is called for the above-mentioned media entity:

$form_state['values'] isn't set at all, so the first test for values in the form fails.
$_GET['fields'] is set to 'undefined', so $query_field in the next test never gets a ['format'] key or corresponding value.
By the time we get to the third 'if' test, we still don't have a $view_mode set, so we get the default view mode - except in my case, the variable 'media_wysiwyg_wysiwyg_default_view_mode' does not exist (!!!), so it defaults to 'full'.
Finally, since 'full' isn't among the allowed view modes, the form element isn't populated with the correct choice.

So, I'm seeing two problems here so far:

The fact that $form_state['values'] isn't set AND $_GET['fields'] isn't a JSON-encoded string means the existing view mode isn't getting passed into this hook. Need to figure out what that's (not) the case...
The absence of the variable media_wysiwyg_wysiwyg_default_view_mode is a bit shocking. I can't actually find anything in the existing code base (versions as above) that sets this variable - just a variable_del() in media_wysiwyg_uninstall(), and three calls to variable_get(). When I googled the variable name, I DID find this patch: #2147221-1: Migrate variables to appropriate submodules, which supposedly migrates a bunch of variables to the new submodules. Unfortunately, since they unset the old variables without confirming that the submodule is actually enabled (the test is for module_exists()), I think it's possible that the original variable could have gotten deleted but not migrated if the new media_wysiwyg module wasn't enabled - which actually happened to me.

Does anyone know where one would set 'media_wysiwyg_wysiwyg_default_view_mode' in the current code base?

Comment #12

chiebert CreditAttribution: chiebert commented 27 April 2015 at 23:41

Just 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 commented 28 April 2015 at 15:29

Similar 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 commented 28 April 2015 at 15:35

Should 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 commented 29 April 2015 at 16:43

Quite 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:

File Entity 7.x-2.0-beta1+29-dev (2015-Apr-21)
Media 7.x-2.0-alpha4+37-dev (2015-Apr-24) patched as per:
Ckeditor 7.x-1.16+9-dev (2015-Apr-01) with Ckeditor library 4.3.2
Media WYSIWYG View Modes set to limit allowed view modes to media_original and em_img_caption (custom view mode), and to use em_img_caption inside the WYSIWYG.
Instance of embedded image is confirmed to have "view_mode":"em_img_caption" in the JSON string of the underlying media tag.

The main new piece for me is #2348439-5: Allow dynamic WYSIWYG markup.

What works:

When I embed a previously-uploaded image, the popup modal presents me with the enabled fields for my image file entity, including the alt, title and a custom 'caption' text field, plus a choice from among the restricted list of view modes I've set up for images.
Changes/choices made to the view mode and the alt and title fields are propagated back to the JSON-encoded embedded media tag once I click 'save' in the modal, and are represented in the final rendered entity.

What doesn't work:

Changes made to the custom 'caption' text field are not encoded into the media tag when saving the modal form, nor do they persist in the rendered image entity.
When I click on an already-embedded image in the WYSIWYG, and click on the Media button to bring up the modal, only the default settings for the fields on that file are filled in - even if there were previously-saved local-instance changes to the alt and title fields, those are lost when the modal form is loaded. Likewise, the JSON-encoded view mode for the image is not pre-selected in the 'display as' drop-down. It's like this is a completely fresh media embed.

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...