Problem/Motivation

When using the WYSIWYG editor to insert an image, if the view mode of the image is changed, classes added by the image style are not removed. This leads to classes like panopoly-image-quarter being associated with the image, regardless of the view mode selected.

Proposed resolution

Remove the classes as view modes are changed.

Remaining tasks

The difficult part - figuring out how to do it.

User interface changes

None

API changes

None (hopefully).

Data model changes

Original issue

The issue summary for #2422153: View mode classes accumulate when changing image view mode is valid for this issue as well, with this issue focusing on classes added by panopoly_images_preprocess_image_style().

CommentFileSizeAuthor
#6 panoply_2765007_6.patch2.92 KBEternalLight
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ultimike created an issue. See original summary.

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented
Related issues: +#2422163: Panopoly CSS causes issues with WYSIWYG image because of image style class names

Another question is why #2422163: Panopoly CSS causes issues with WYSIWYG image because of image style class names isn't working -- that issue was originally intended to solve this problem :-/

ultimike’s picture

ultimike
Primary language English
Location Florida, USA
CreditAttribution: ultimike at DrupalEasy commented

@dsnopek,

Admittedly, I don't have a full understanding of all the moving parts with this issue (Panopoly Image, Media, Media WYSIWYG, etc...), but in my testing/debugging, it appears that:

1. panopoly_images_preprocess_image_style() gets called when the "add media" WYSIWYG toolbar button is clicked and the various view modes are loaded in the Media modal window. It appears that it gets called once for each view mode listed in the "Display as" select box.
2. After a view mode is selected, and the modal "Submit" button is clicked - the panopoly_images_preprocess_image_style() is not called.

So, if an existing node (one with an image added via the "add media" button previously) is edited...

1. When initially loaded in the WYSIWYG editor, if the image's previous view mode is Quarter Right, then the media tag will contain "class":"panopoly-image-quarter media-element file-quarter-right"}.
2. If the image is selected, then the "add media" button is clicked (to change the "Display as" setting) and the "Display as" select is set to "Original size". Once submitted, the media tag then contains: "class":"panopoly-image-quarter media-element file-default".

At this point, I don't understand how the classes from the image style are supposed to be communicated to the media widget (specifically, its JavaScript code which is clearly handling the updating of the media tag).

-mike

ultimike’s picture

ultimike
Primary language English
Location Florida, USA
CreditAttribution: ultimike at DrupalEasy commented

As an initial step, I decided to try to reproduce the issue on a fresh install of Panopoly (7.x-1.37). Here's what I did:

  1. Modified the WYSIWYG profile by enabling the "Show enable/disable rich text toggle link" on admin/config/content/wysiwyg/profile/panopoly_wysiwyg_text/edit.
  2. Created a new "Content page" with some dummy text and an image in the body field inserted via the "Add media" WYSIWYG button. Set the initial "Display as" to "Quarter Size", clicked "Publish" (save).
  3. The image appears as expected - quarter sized, floated left.
  4. Click to edit the same node.
  5. Select the image, click the "Add media" button, change "Display as" to "Original size", click to "Submit".
  6. So, at this point, in the WYSIWYG editor, the image still appears "Quarter Size". Clicking the "Disable rich text" link shows the following classes on the image (media) tag: "panopoly-image-quarter media-element file-teaser file-default".
  7. Save the node, and see that the image is no longer "Quarter Size", rather it is "Original Size". Inspecting the img tag, the classes are: "media-element file-teaser file-default panoply-image-original".

So, it appears that the issue isn't with the display of the node, rather the issue is with the display of the node while displayed in the WYSIWYG editor.

-mike

dsnopek’s picture

dsnopek
he/him
Primary language English
Location USA
CreditAttribution: dsnopek commented

Ok, so it sounds like #2422163: Panopoly CSS causes issues with WYSIWYG image because of image style class names fixed display of the content (in PHP), but not the situation in the WYSIWYG (in Javascript) :-/

Fixing this would probably involve patching (or monkey patching) the Javascript in Media. Or maybe a hook-like thing could be added to the Media Javascript, that would allow Panopoly to subscribe to an event or set a function somewhere that would filter the classes used?

Looking at the patch on #2422153-10: View mode classes accumulate when changing image view mode, that could be the place that the hook (or inline filtering) would need to happen, although, I didn't test that patch.

A hook-like thing would probably be ideal, because that's something that could get actually merged into Media. After that, if we can monkey patch the Javascript, that would be better than an actual patch (because a Panopoly-specific patch would never get committed upstream).

I hope that helps!

EternalLight’s picture

EternalLight CreditAttribution: EternalLight as a volunteer commented
FileSize
panoply_2765007_6.patch2.92 KB

Hello,

I took a look at this issue and figured that old (initial) panoply CSS class remains in editor after editing an image because it is not updated in media_wysiwyg.filter.js. The attached patch fixes this issue. Note that it could be applied on Media 2.0 that comes with Panoply installation profile out of the box and might not work with the current stable media release (2.3 at the moment of writing).

Please test it out and let me know if it helped.

cboyden’s picture

cboyden CreditAttribution: cboyden commented
Status: Active » Needs review