Add an update hook to download required JavaScript libraries

Created on 21 November 2022, over 1 year ago
Updated 10 February 2023, over 1 year ago

Problem/Motivation

Lightning Media has exotic dependencies. It uses Composer to bring in three JavaScript libraries that are normally available from npm/Bower. It does this using Asset Packagist, which serves as a third-party bridge repository between Composer, npm, and Bower.

There are a few problems with that. For it to work at all, it requires interesting stuff to happen in the top-level composer.json (the Asset Packagist repository must be defined there, along with some configuration for the oomphinc/composer-installers-extender plugin and installer paths). This is tricky developer-type stuff and, with the retirement of the Lightning profile, we can't reliably expect anyone to have that. It also completely breaks the ability to run tests on Drupal CI, since we can't really affect the layout of the docroot in which tests run.

Proposed resolution

Let's stop providing those dependencies.

To prevent sites from breaking, we will add an update path to the relevant submodules, which downloads the required libraries.

πŸ“Œ Task
Status

Fixed

Version

4.0

Component

Miscellaneous

Created by

πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

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.

  • πŸ‡ΊπŸ‡ΈUnited States RichardDavies Portland, Oregon

    @alfattal Did you ever figure out the cause or solution to the entity browser items no longer being clickable after upgrading lightning_media? I'm experiencing the exact same issue.

  • πŸ‡ΊπŸ‡ΈUnited States alfattal Minnesota

    @RichardDavies No, I did not and I'm still waiting for an update from the module maintainer (phenaproxima) after he requested attaching "pre-update" and "post-update" versions of my composer.lock file.

  • πŸ‡ΊπŸ‡ΈUnited States RichardDavies Portland, Oregon

    After digging into this a bit, I believe this commit in v4.7 is the culprit. It changed how JS/CSS gets applied to entity browsers. I've verified that after upgrading to 4.7 or above, my entity browser no longer has the JS/CSS that was formally applied to the entity browser and adds the "click" event handler.

    I don't fully understand the rationale behind that change, but it seems to be intentionally more selective about when the JS/CSS gets applied... is there something different I need to do to my entity browser configuration so that it meets the more selective criteria now?

  • πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

    I don't fully understand the rationale behind that change, but it seems to be intentionally more selective about when the JS/CSS gets applied... is there something different I need to do to my entity browser configuration so that it meets the more selective criteria now?

    Thanks for the great detective work, @RichardDavies! I would not have thought to look that far back, and it wasn't clear from the bug report that this was breaking for a different entity browser apart from the ones that were previously shipped with Lightning Media. (It was especially unclear because it has nothing to do with the change made in this issue.)

    That CSS/JS library was custom-developed for the media_browser and ckeditor_media_browser entity browsers which shipped in older versions of Lightning Media. It was never intended to be used by other entity browsers.

    With that in mind: in Lightning Media 8.x-4.0, we stopped shipping entity browsers. We continued to package the Entity Browser module, to avoid breaking sites which use it, but we no longer used Entity Browser ourselves. So, it made sense to apply that library more selectively to try and support sites that were still using the entity browsers that we shipped in Ye Olden Days. But, as I said, that library was never meant for other entity browsers that we didn't create, and in fact, I would consider it a bug that it was getting applied to other entity browsers.

    If you need to restore the functionality, I'd say the proper solution is to implement the appropriate form_alter hook in your own custom module, and include the library there (YOURMODULE_form_entity_browser_ENTITYBROWSERID_form_alter). To future proof it even more, go ahead and copy the entire library, wholesale, into your custom module as well. :) Since we are not using it, I don't see any value in reverting the commit. (In fact I would like to deprecate the library as a whole and remove it in a future version of Lightning Media.)

    I'd consider this case closed, but feel free to reach out on Drupal Slack if you'd like to discuss more.

Production build 0.69.0 2024