CKEditor embedded media previews do not render with attached assets

I am needing this. I am adding an embeddable render element widget, that lets the user pick which render element to use. The attached CSS and JS is dependent on what the user picks, and I cannot determine this ahead of time, aside from including *all possible CSS*. I am using the Embed module to run the returned preview HTML but the attached CSS and JS is being attached to the root document head, and not the head inside the CKEditor iframe instance.

I also need the ability to render media entity on the client side using attached JS and drupalSettings.

I have solved the problem of inability to preview JS-based media entities by invoking an additional AJAX request to /embed/preview/rich_text (embed module) - the response is processed in the usual Drupal way.

I could also use this, I need to embed an entity that relies on CSS and JS from a library for proper display. I agree 100% that embedded entities should not be interactive, but their attached libraries should load so that they can be displayed correctly without workarounds.

@maximpodorov can you give more details on how that additional AJAX request is invoked to work around the current problem?

Something like this:

  $(window).on('ckeditor:unlockSnapshot', function (e, ckeditor) {
    if (!ckeditor || !ckeditor.document) {
      return;
    }
    var elements = ckeditor.document.$.getElementsByClassName('your-class');
    for (var i = 0; i < elements.length; i++) {
      var element = elements[i];
      var text = element.getAttribute('data-text');
      var wrapper = element.parentElement;
      wrapper.removeChild(element);
      wrapper.style.display = 'block';

      Drupal.ajax({
        element: wrapper,
        url: Drupal.url('embed/preview/rich_text?value=' + text),
        progress: {type: 'none'},
        event: 'entity_embed_dummy_event'
      }).execute();
    }
  });

This is also critical for our project. The editors need to see exactly what the rendered embedded entity will look like when saved/published while they are editing; not including the js and css attached in the template for the view mode completely changes the way the embedded entity behaves in WYSIWYG and makes us have to create some hacks or alternate (superfluous and less effective "previews") view modes to approximate the behavior in the back end theme/CKeditor. We may eventually come up with a contributable solution for this, but for now wanted to at least voice support for somehow including attached assets without being disruptive or overly complex.

Just had a quick chat with phenaproxima about this. Allowing libraries to be attached to CkEditor is apparently not an easy thing to do (see the IS). As a workaround though, it might already help if the media templates can somehow determine they are being used as a "preview", and the attached libraries will not work.

We can discuss how the template can determine that it is being used in CkEditor, and if the Media entity itself should be aware of that (through something like a isPreviewing / setPreviewContext method). Not sure if the workaround should be implemented in this issue or if we should create a new one for it, but to be honest I think providing some variable/context to the media template is the only way we can get anything close to an improvement for this in the short term.

Any thoughts?

I'm a big proponent of letting media entities know they're in a "preview" state. +1 to that approach.

It's just too tricky to get some media entities rendering correctly in the editor. I'd rather just know they're in that state and render some kind of placeholder instead.

Have to make sure it's not cached though.

It is actually insane that there's literally no way to tell if the media item is being rendered inside CKEditor.

This does not work:

function mymodule_support_preprocess_media(&$variables) {
  if (\Drupal::service('router.admin_context')->isAdminRoute()) {
    // Even inside the editor, the media item isn't in an admin route.
  }

  if (\Drupal::routeMatch()->getRouteName() === 'media.filter.preview') {
    // It's only a preview when you first embed it, but on edit it's just part of the content!
  }
}

This is the ridiculous thing I had to do in order to allow clicking on a media item so you can adjust display mode etc:

function mymodule_support_preprocess_page(&$variables) {
  if (\Drupal::service('router.admin_context')->isAdminRoute()) {
    $variables['#attached']['library'][] = 'mymodule_support/ckeditor5_fixes';
  }
}

document.body.addEventListener('click', (e) => {
  // Prevent opening colorbox images in the current tab while in the editor.
  if (e.target.parentElement.classList.contains('colorbox')) {
    e.preventDefault();
  }
});

I can't imagine what other media embeds will need to go through to suppress behavior.

In our special use case we add to load some JS after a custom web component was displayed as a media.

We wrote a Javascript MutationObserver to detect the addition to the page of our custom element and load the related javascript library.

Here is an quick and dirty piece of code for those interested:

jQuery(document).ready(function() {
  // Function to remove specific attribute
  function initImageComparisonSlider(mutationsList, observer) {
    mutationsList.forEach(mutation => {
      // Check if nodes are added
      if (mutation.type === 'childList') {
        // Iterate through added nodes
        mutation.addedNodes.forEach(node => {
          // Check if the node is an element of type DIV
          if ((node.nodeType === 1) && (node.tagName === "DIV")) {
            var article = node.children[0];
            // Check if the node is an element of type ARTICLE
            if (article.tagName === "ARTICLE") {
              var ics = article.children[1];
              // Check if the node is an element of type IMG-COMPARISON-SLIDER
              if (ics.tagName === "IMG-COMPARISON-SLIDER") {
                once('ics-js-css', 'body').forEach(function (element) {
                  let scriptEle = document.createElement("script");
                  scriptEle.setAttribute("src", "https://cdn.jsdelivr.net/npm/img-comparison-slider@8/dist/index.js");
                  scriptEle.setAttribute("type", "text/javascript");
                  scriptEle.setAttribute("async", "async");
                  document.body.appendChild(scriptEle);
                });
              }
            }
          }
        });
      }
    });
  }
  
  // Create a new MutationObserver
  const observer = new MutationObserver(initImageComparisonSlider);
  
  // Define the target node to observe
  const targetNode = document.body;
  
  // Configuration of the observer
  const config = { childList: true, subtree: true };
  
  // Start observing the target node for configured mutations
  observer.observe(targetNode, config);
});

We used Asset Injector for our test, script was activated only on node/*/edit pages.

+1 for this feature. It's a WYSIWYG editor after all, so at least CSS should be rendered when previewing.

I also need this. +1