Problem/Motivation

After upgrade (on D11.4.4). I disabled media_directories_ui and media_directories_editor and enabled media_directories_browser.
I can see the existing images in the browser.

However:
* When editing all content-types I get a dialog box with: 'An error occurred while attempting to process /node/403/edit?ajax_form=1&_wrapper_format=drupal_ajax: q.trim is not a function'

* In edit for a custom content-type (blog) I can see the image in the image-field, as it was before, but it is not rendered on view, but get the filename of the image displayed: <div class="topic_image">abstract_47.jpg</div>. Other content-types are similar.

This may be a strange interaction with my theme, but hard to track down without more clues. Nothing obvious on browser Console .

Steps to reproduce

see above

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Comments

jons created an issue. See original summary.

rang501’s picture

rang501 commented

There are no trim() calls outside vue app, so it should not be caused by this module. This should log something on the browser console, if it does not do that, then check network traffic - maybe something hints more about it - what may call it or what the response contains.

The second issue should not be related to media directories field widget, but more like field formatter configuration. This module does not provide formatter, so they should not be related. I'm not sure if any third party code is trying to read widget settings and fails because it is different from the core widget.

rang501’s picture

rang501 commented
Status: Active » Postponed (maintainer needs more info)
jons’s picture

jons commented

Deinstalled media_directories and still getting it - esp when click media field button icon in content edit.
Moving to core

jons’s picture

jons commented

* Changing image widget in Manage form display to Autocomplete allows an image to be added
If media_directories_browser installed - this widget also works
So a problem with Media widget (also Entity browser) - needs work

* Something changed the order of fields in Manage Display and the Format of the image to 'Label', and Label setting to Above (in all content types that have an image)! media_directories upgrade to v2? Some of this is affected in the media_directories.install

rang501’s picture

rang501 commented

Is the label issue with CKEditor or field? The media_directories_editor adds a formatter for entity embed and it was not intended to be used elsewhere. For CKEditor issues, the compatibility submodule provides the needed functionality to render media.
If the formatter was used elsewhere, then it should be switched back to core and configured as needed.

Or is the issue with edit form? In that case the widgets need to be configured. The automatic way to do this is implemented here: https://www.drupal.org/project/media_directories/issues/3613265

jons’s picture

jons commented

CKEditor is not involved AFAIK.

The image fields in all custom content-types were affected being moved to the bottom of the page in 'Manage display', and Format changed to 'label' and the Label changed from 'hidden' to 'Above'.

In 'Manage form display' the image used 'media_library_widget' in D10, now 'media_directories_browser_widget' in D11. Going from D10 to D11 I changed media_directories 2.2.0-beta2 - 3.0.0-alpha2 and disabled _ui and _editor, and enabled _browser.

The separate? 'q.trim is not a function' problem is when 'Manage form display' value for an image is 'Media library' (which it must have been changed to at some point).

rang501’s picture

rang501 commented

What I'm understanding at the moment: the issue is with display (not form display), the field configuration was changed for some reason. In this case can you tell what was the previous formatter used? The only relation with formatter and this module was special formatter for entity browser called "Image with dimensions" (media_directories_image_dimensions).

jons’s picture

jons commented

A previous view.display (from a saved config export) was
field_blog_image:

    type: media_directories_image_dimensions
    label: hidden
    settings:
      image_style: blog__400x300_
      image_link: ''
      image_loading:
        attribute: lazy
      dimensions:
        image_width: ''
        image_height: ''
    third_party_settings: {  }
    weight: 0
    region: content
rang501’s picture

rang501 commented

Yes, it does make sense now. The formatter "media_directories_image_dimensions" was created for entity browser and the intent was to allow setting custom dimensions when embedding media inside the CKEditor. It probably leaked to display settings. The 3.x does not need it anymore.

I'm not sure if this module should handle it, maybe just document it. A fix for this is probably to use Thumbnail (media_thumbnail) formatter. It is most likely compatible on the settings side, if only the image style was used. So changing the type in yml files media_directories_image_dimensions -> media_thumbnail should work. The "dimensions" key can be cleaned up.

I assume (and hope) the dimensions was not used because on it own it does not respect aspect ratio and cause weirdly scaled images.

jons’s picture

jons commented

These all were rebuilt by hand
The equivalent yml:

  field_blog_image:
    type: entity_reference_entity_view ('Rendered entity')
    label: hidden
    settings:
      view_mode: blog_image
      link: false
    third_party_settings: {  }
    weight: 0
    region: content

This also included using the current Drupal method for styles by setting up per-content-type view modes (eg blog_image) and assigning them to content-type image fields - then linking to styles from Configuration > Media > Image styles.

The question is, how did all this get changed/lost.

rang501’s picture

rang501 commented

The formatter was inside the editor submodule. It was uninstalled, formatter went missing and Drupal defaulted to something else. I'll add this to migration documentation in case someone else happened to use that formatter as well. I think this shouldn't be handled automatically.

Are there any other issues?

jons’s picture

jons commented
Title: q.trim is not a function » media_directories_editor deinstall issue

@rang501 - I've changed the title etc to reflect this. The q.trim is a separate problem still being evaluated.
A block created by Views with Slideshow format also disappeared as block and view. This used a 'slider' content-type that was affected by same issue as described here.

There is such a lot to reconfigure that the _editor deinstall really needs a real-time prompt to make people aware and at least to ensure they have a config backup (drush cex) to help identify what needs to be changed (eg grep for media_directories_image_dimensions)
As Drupal does not have a pre-uninstall hook, adding an Alter to the uninstall form (filtered for this sub-module) to add a confirm step/button would help. This could also print a list of affected content-types. I believe something can be done with drush too.

  • rang501 committed 99134d67 on 3.0.x 
    Issue #3613033: Migrate field displays and widgets on deprecated...

  • rang501 committed 9fb52bb5 on 3.0.x 
    Issue #3613033: Add "linkit" to the cspell dictionary
rang501’s picture

rang501 commented

There is now new documentation for upgrade: https://project.pages.drupalcode.org/media_directories/upgrading/
Now there should be straightforward upgrade path.

The uninstallation now should cover the formatter migration by switching back to core formatter if it has been used somewhere.

But in general config backup is a must - Drupal may delete things accidentally not related to uninstalled module as some config dependency calculation went crazy.

I'll try to create better testing locally to see if there are any other problems.

  • rang501 committed 6f2d77eb on 3.0.x 
    Issue #3613033: Self-wire compat filters on install and preserve embed...
rang501’s picture

rang501 commented
Status: Postponed (maintainer needs more info) » Needs review

There were some issues, which are now fixed, hopefully the upgrade path is smoother.
The documentation has been updated.

jons’s picture

jons commented

👍

rang501’s picture

rang501 commented
Status: Needs review » Fixed

Releasing it as the changes are important. Further upgrade related issues should be reported separately.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.