#Media Initiative

⚡️ Live updates comments, jobs, and issues, tagged with #Media Initiative will update issues and activities on this page.

Issues

The last 100 updated issues.

Activities

The last 7 days of comments and CI jobs.

  • 🇧🇪Belgium herved

    Update: 🐛 MediaLibraryUiBuilder service does not properly allow additional contextual filter arguments Needs work sounds like the proper fix, works perfect for me.
    Could some of you test as well so we could close this issue here as duplicate?
    Thanks

  • 🇧🇪Belgium herved

    I think I just stumbled on this issue.

    It looks like the form ID changes because it is built according to the views arguments being passed, e.g:
    - initially (modal loaded): views_form_media_library_widget_image
    - click apply filters or pager: views_form_media_library_widget_image_[some additional args]
    - click insert selected: views_form_media_library_widget_image

    FormBuilder::buildForm checks the form_id to build the ajax response and throw FormAjaxException.
    But since the form_id doesn't match, drupal sends an HTML response instead of JSON, which results in a "parsererror" in JS.

    The main suspect here to me is MediaLibraryUiBuilder::buildMediaLibraryView which passes only 1 argument to the view:
    $args = [$state->getSelectedTypeId()];

    Just unsure what to do/how to solve at this point.
    Any thoughts?

  • 🇬🇧United Kingdom catch

    The filter is only for text. It shouldn't be used for HTML.

    The output of a text format is by definition HTML. Even if you're entering markdown or something, the end result is HTML, and the auto line break filter can theoretically be applied at any point in that process. You could say it should only be applied at the beginning, before any other HTML formatting is applied from different filters, and that editors shouldn't copy and paste paragraph breaks when using a format with the automatic line break filter, but the text format system doesn't enforce this at all, and I've had plenty of sites where a mixture of handwritten and copy and pasted content gets put into the same text format.

    The question is, does this filter make any sense at all in conjunction with CKEditor fields

    The media filter can be used without ckeditor5, so the line break filter ought to be able to work with it - and comments above suggest this is broken without any involvement from ckeditor5 at all.

    There might well be a case for adding some validation to prevent the auto-line break filter from being configured alongside ckeditor5 though but that feels like a new issue to me.

  • 🇩🇪Germany rgpublic Düsseldorf 🇩🇪 🇪🇺

    * IMHO, I think this is correct. The filter is only for text. It shouldn't be used for HTML. I don't see any valid use-case either. Whether it really needs to check and silently fail or whether a description would enough is anyone's guess. There are other filters which just use the issue description to specifiy their restrictions in order to work correctly ("only use after/before this and that"). They don't check and silently fail in these cases either.
    * This issue morphed into sth. else though. The original issue as still seen in the issue description was "we can't guarantee that the rendered representation of that media item will be a single HTML element". That's still a valid concern and by far isn't solved by just disabling this filter. But perhaps a new issue could be filed for this. The far more complicated problem to solve is: If a media *entity(!)* is rendered it unsurprisingly consists of entity *fields(!)*. When rendering these fields, there are DIV tags introduced at the very least because the default field item template contains DIV tags. I know this affects issues with far reaching consequences and this is probably not easy to change, but my take on this is: This is actually wrong. A DIV cannot appear inside a SPAN tag. This causes invalid HTML. Whenever a field is rendered inline you will get these problems which is kind-of sad. It could perhaps be solved without turning the whole of Drupal on its head if we said that field elements should be rendered with a special SPAN tag template just for the media entity display mode or sth. along these lines.

  • 🇩🇪Germany drubb Sindelfingen

    The question is, does this filter make any sense at all in conjunction with CKEditor fields? I think it's primarily meant for use with plain text fields, as CKEditor does this conversion already. I can't think of a use case for fields powered by CKE, so maybe we need a hint not to use it, or prevent usage at all for CKE fields. At least it should fail silently and not destroy the markup given by CKE.

  • 🇺🇸United States phenaproxima Massachusetts

    Glad we got this isolated, I think with that in mind it shouldn't be too hard to write a test case.

  • 🇬🇧United Kingdom catch

    Moving this to filter module. Should be possible to write a test case given the examples above to reproduce the duplicate link, then we can try to fix it in _filter_autop

  • 🇦🇺Australia jannakha Brisbane!

    patch #466 applies to D10.3, but selected image styles are not visible in CKEditor 5 while adding/editing image:

    Config works as expected:

    Selected image styles are not available in CKEditor5:

  • 🇩🇪Germany drubb Sindelfingen

    Did a quick test to look at this filter in isolation, by calling the _filter_autop() function directly. This is broken indeed:

    $output = _filter_autop('<p><a href="https://google.de"><drupal-media/></a></p>')
    

    Result:

    <p><a href="https://google.de"></p>\n
      <drupal-media/></a></p>
    
Production build 0.69.0 2024