MediaEmbed conflates default view mode with user-selected view mode

Created on 27 January 2020, almost 5 years ago
Updated 24 March 2023, over 1 year ago

Problem/Motivation

The new MediaEmbed functionality added in 8.8.0 incorrectly conflates a text format's MediaEmbed default view mode with the view mode selected by an editor when embedding the media. If the default view mode for the text format is changed, this will result in corruption of data. The implicit relationship with the embeds using the previous default view mode is now broken, and all of the previously embedded media that used the old embed are now displaying the new default view mode.

If an editor embeds media and selects what a site builder has designated as the default view mode, then that data (the 'data-view-mode' attribute) is stripped from the <drupal-media> element. The editor is unaware this happens. From their point of view, they selected a view mode and expect that selection to be honored; however, from this point forward, MediaEmbed assumes that if a <drupal-media> element lacks a 'data-view-mode' attribute, then the view mode must be the current default view mode.

The following comment from \Drupal\media\Form\EditorMediaDialog::buildForm() pretty much sums it up:

    // Store the default from the MediaEmbed filter, so that if the selected
    // view mode matches the default, we can drop the 'data-view-mode'
    // attribute.

Here's the catch. If that default view mode changes, then piece of embedded media that used the prior default view mode will now use the new default view mode. The editor's view mode selection has been disregarded and their original selection is unrecoverable.

Setting priority to critical as this bug corrupts user data.

See below for steps to reproduce:

  1. Install Drupal 8.8.2-dev with Standard install profile.
  2. Enable Media and Media Library.
  3. Add a new Media view mode: 'Image'.
  4. For 'Image' media bundle, enable custom display settings for the 'Image' view mode.
  5. (Note that the default view mode will render a 480x480 image.)
  6. For the 'Image' view mode for the 'Image' media bundle, configure the view mode to render a 220x220 image.
  7. Edit the 'Basic HTML' text format/editor.
  8. Add the Media Embed button to the toolbar and enable the 'Embed media' filter.
  9. For the 'Embed media' filter, configure it as follows:
    • Default view mode: Image
    • Media types selectable in the Media Library: Image
    • View modes selectable in the 'Edit media' dialog: Default, Image, Media Library
  10. Save format/editor configuration.
  11. Upload an image to the Media Library.
  12. Create a new Basic page node.
  13. Embed the image.
  14. Observe that the default embed is using the 'Image' view mode (e.g. 220x220px).
  15. Use browser inspector tool to inspect the element and observe the 'data-view-mode' attribute is not present.
  16. Click on 'Edit media' and change the view mode to 'Default'.
  17. Use browser inspector tool to inspect the element and observe the 'data-view-mode' attribute is present and has a value of 'default'.
  18. Click on 'Edit media' and change the view mode back to 'Image'.
  19. Save the node.
  20. Edit the 'Basic HTML' text format/editor.
  21. Change the 'Default view mode' to 'Default'.
  22. Save format/editor configuration.
  23. Reload the Basic page. Notice that the image is now being rendered 480x480px and not 220x220px.

Proposed resolution

Stop removing 'data-view-mode' from <drupal-media> elements.

This bug is already out in the wild, so we'll need to figure out how to address existing installs. Right now, there are sites out there with <drupal-media> elements, tucked away in various fields, without a 'data-view-mode' attribute. I assume we'll need to use hook_update_N() to update those <drupal-media> elements.

Remaining tasks

  • Write patch
  • Update tests

User interface changes

None

API changes

None.

Data model changes

None.

Release notes snippet

There will certainly need to be something.

πŸ› Bug report
Status

Needs work

Version

10.1 ✨

Component
MediaΒ  β†’

Last updated about 12 hours ago

Created by

πŸ‡ΊπŸ‡ΈUnited States Chris Burge

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • The Needs Review Queue Bot β†’ tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

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

  • πŸ‡ΊπŸ‡ΈUnited States Nuuou Lincoln, NE

    New patch derived from #65 to support CKEditor 4 now int Contrib.
    Divided into two patches: One for Media in Core, the other for CKEditor in Contrib.

  • Status changed to Needs review over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States joegraduate Arizona, USA

    Re-rolled the core-only patch from #67. I think we need to open a companion issue for the CKEditor contrib project and add the ckeditor module patch from #67 there.

  • Status changed to Needs work over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Moving to NW for the test cases

  • @joegraduate opened merge request.
  • Status changed to Needs review over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States joegraduate Arizona, USA

    Rebased existing MR branch into a new MR targeting 10.1.x.

  • Status changed to Needs work over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Seems there are few more changes in the MR then the patch. What changes did you make?

  • πŸ‡ΊπŸ‡ΈUnited States joegraduate Arizona, USA

    Adding interdiff to show differences between old MR and new one.

  • πŸ‡ΊπŸ‡ΈUnited States joegraduate Arizona, USA

    Seems there are few more changes in the MR then the patch. What changes did you make?

    @smustgrave #68 is essentially a re-rolled version of #24.

    The new MR, !3714, is essentially a re-roll of the existing MRs which added lot more changes per the discussion in this issue about the need for an update path for existing sites.

Production build 0.71.5 2024