Moving forward from 8.x-2.x.dev (with Library and D9)

P.S. to number 1. If there is anyone else out there (not a maintainer) who really knows the dependency injection stuff, I'd be happy to send a list of the programs that the standards compliance programs are complaining about. I think that if we could get these fixed up, we'd be a long ways towards having a great Drupal 9 compliant module.

To test further, and based on the code that's in the git referenced in #1 I used Composer to install a Drupal 9.0.8 site locally. Then I added in my Juicebox module. I created a juicebox gallery content type. I added in a photo gallery within that content type. It works ... you can view the photo gallery. You can configure Juicebox both from the extend screen and from the admin config screen.

There are still problems. I sure could use some help from a seasoned Drupal developer ... the output from the PHPCS standard practice is below showing what's left to do. There are two things that particularly concern me:

1. settingsform.php is not "injecting" the getLibrary function correctly. This is at lines 35 and 141. I've hacked away at it a bit but that's at the 5 propeller head level and I'm at most at 2.

2. juiceboxformatter.php is not injecting imagestyle properly. It's a variant of the problem above.

I think that in both cases I need a class with a function within them that can be used to inject the code. I just don't know how ... yet.

It would also be worth it for someone more expert to review the changes I've made to translations. In pre-Drupal 9 you could just use global t() function ... now you have to use a stringtranslationtrait thing and have a function that instantiates a string_translation variable. Then you can do a $this->t in place of a t() and Drupal won't complain. What I've done so far seems to work but I'm not sure I haven't created some unnecessary or duplicate code along the way. Better not to have that on 10k sites a few years from now.

There are a few other nits pointed out by phpcs ... unused variables for instance. I'm not sure these need fixing and if so what the right approach would be.

This all needs a lot more testing than I can do by myself ... I will have to rely on our maintainer and others to step in. We might want a 8.9x release that removes use of the contrib library module and then a 9.x release. People who have other blockers to using Drupal 9 could use the 8.9 release ... those who don't could test the Drupal 9 release.

@dk40 ... waking up to your posts today gives me hope! Thanks. I'm reading text books as I go re. dependency injection so having some guidance is great. I will try your suggestions out. If I can make them work locally I'll put them up on my github account where I have the code that removes the contrib module library dependency and MANY FIXES identified by PHPCS (code sniffer).

We need our maintainer's expertise and collaboration on getting commits done in the "official" Drupal dot org version. Hopefully he can use what I've put out on github (linked elsewhere) so no one else has to go through the phpcs listings and fix things all over again.

The one code statement that's brought me to a screeching halt is in the JuiceboxFormatter.php program in the function named styleimage (at line 293 in my version of the code and down at line 333 there: " $style_obj = ImageStyle::load($style_each);" ... by my reading this is saying "load parent" from Imagestyle and should probably be loading in a styles from a style object. I'm trying to figure out exactly what the context of this is. From the comment preceding the function I think that this function is only used when you are trying to use an individual image file that you've uploaded with the juicebox formatter. I never encounter this because I load my galleries whole using FTP and there should be no need to "style" individual images. That may be why I can run the code on Drupal 9 without issues too?

I will see if I can integrate your suggested code into my version of juiceboxFormatter and remove this problem. I'll be back.

Oops. Looking at your code @dk40 i can see you were working on the dependency injection issues in settingsform.php. Sorry: I've been totally consumed focusing on the issue in juiceboxformatter.php. I will switch gears and try your suggestions with settings form. The coding standards stuff is showing three dependency injection issues: one in juiceboxformatter and two in settings form. Once these are done we should be able to test against Drupal 9. No guarantees what we'll find.

@dk40 Testing your code for settingsform.php I am getting:

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\juicebox\Form\SettingsForm::__construct() must be an instance of Drupal\juicebox\Form\JuiceboxFormatterInterface, instance of Drupal\Core\Config\ConfigFactory given, called in D:\webpage\drupal8\core\lib\Drupal\Core\Form\ConfigFormBase.php on line 29 in Drupal\juicebox\Form\SettingsForm->__construct() (line 33 of modules\juicebox\src\Form\SettingsForm.php).

Drupal\juicebox\Form\SettingsForm->__construct(Object) (Line: 29)
Drupal\Core\Form\ConfigFormBase::create(Object) (Line: 28)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition('\Drupal\juicebox\Form\SettingsForm') (Line: 48)
Drupal\Core\Controller\HtmlFormController->getFormObject(Object, '\Drupal\juicebox\Form\SettingsForm') (Line: 76)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

I first "hand-merged" your code into mine, then when I had the error above I just copied and pasted your code entirely into mine. Still showing the error. My services.yml is:

services:
  juicebox.formatter:
    class: Drupal\juicebox\JuiceboxFormatter
    arguments: ['@config.factory', '@string_translation', '@url_generator', '@module_handler', '@path.current', '@request_stack', '@messenger'

which is only different from yours in including the messenger (which I think is needed somewhere).

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\juicebox\Form\SettingsForm::__construct() must be an instance of Drupal\juicebox\Form\JuiceboxFormatterInterface, instance of Drupal\juicebox\JuiceboxFormatter given, called in D:\webpage\drupal8\modules\juicebox\src\Form\SettingsForm.php on line 41 in Drupal\juicebox\Form\SettingsForm->__construct() (line 30 of modules\juicebox\src\Form\SettingsForm.php).

Drupal\juicebox\Form\SettingsForm->__construct(Object) (Line: 41)
Drupal\juicebox\Form\SettingsForm::create(Object) (Line: 28)
Drupal\Core\DependencyInjection\ClassResolver->getInstanceFromDefinition('\Drupal\juicebox\Form\SettingsForm') (Line: 48)
Drupal\Core\Controller\HtmlFormController->getFormObject(Object, '\Drupal\juicebox\Form\SettingsForm') (Line: 76)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

This is based on the code from commit c8b9d068 copied and pasted directly into my SettingsForm.php file in order to avoid an transcription/ copy/paste type errors. I'm back to working on it. I will look at unused variables issues once we get past these three dependency injection errors. I have a sneaking suspicion that other modules, and even core modules that have been "certified" for Drupal 9 may have these same type of errors generated in foreach loops. If not, I'll see how they fixed it.

I'll be working to see if I can figure out anything from your changes the rest of the East Coast U.S. time this afternoon. If we can get the two issues in settingsform and the one in juiceboxformatter fixed I think we will be in good shape.

@dk40 ... the document you listed on services and dependency injection does seem focused in the right area. I'll need to absorb it. I have two text books open also. I have been puzzling over "Argument 1 passed to Drupal\juicebox\Form\SettingsForm::__construct() must be an instance of Drupal\juicebox\Form\JuiceboxFormatterInterface" and trying to find work arounds. Where it gets (and inserts) the word "Form" in that puzzles me.

Tomorrow will be another day.

aha. So, I took a fresh look at your latest commit @dk40 and compared line by line with the code I had copied from it and tested with. Yesterday I "fixed" up the two standards suggestions from https://www.drupal.org/pift-ci-job/1898572

2 coding standards messages
	
src/Form/SettingsForm.php
line 9	Unused use statement
27	Data types in @param tags need to be fully namespaced

This morning I decided to take the error message generated when I tested the code seriously and work backwards. So I changed the construct statement to:

  public function __construct(JuiceboxFormatter $juicebox_formatter) {
    $this->juiceboxFormatter = $juicebox_formatter;
  }

where the commit code was constructing JuiceboxFormatterInterface. That seems to work on my test system when I go to configuration/juicebox and a configuration form is generated.

I'll post the full text of the code I'm using for settingsform.php in a separate post. Then I'll test some more and run things back through PHPCS. I'll have to study some on what merge requests do versus patches etc. I have a full version of the changes I'm making on my github page though I haven't updated it for yesterday and today's changes ... that are in flux.

11/30/2020 version of settingsform.php per #24 edited to fix two coding standards issues

 <?php

namespace Drupal\juicebox\Form;

use Drupal\Core\Form\ConfigFormBase;
use Drupal\Core\Form\FormStateInterface;
use Drupal\Core\Cache\Cache;
use Drupal\Component\Render\FormattableMarkup;
use Drupal\juicebox\JuiceboxFormatter;
use Symfony\Component\DependencyInjection\ContainerInterface;

/**
 * Defines a form that configures global Juicebox settings.
 */
class SettingsForm extends ConfigFormBase {

  /**
   * The Juicebox formatter service.
   *
   * @var Drupal\juicebox\JuiceboxFormatter\JuiceboxFormatterInterface
   */
  protected $juiceboxFormatter;

  /**
   * Constructs a new SettingsForm object.
   *
   * @param \Drupal\juicebox\JuiceboxFormatter $juicebox_formatter
   *   The Juicebox formatter service.
   */
  public function __construct(JuiceboxFormatter $juicebox_formatter) {
    $this->juiceboxFormatter = $juicebox_formatter;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container) {
    // Instantiates this form class.
    return new static(
        // Load the service required to construct this class.
        $container->get('juicebox.formatter')
    );
  }

  /**
   * {@inheritdoc}
   */
  public function getFormId() {
    return 'juicebox_admin_settings_form';
  }

  /**
   * {@inheritdoc}
   */
  protected function getEditableConfigNames() {
    return [
      'juicebox.settings',
    ];
  }

  /**
   * {@inheritdoc}
   */
  public function buildForm(array $form, FormStateInterface $form_state) {
    $library = $this->juiceboxFormatter->getLibrary(TRUE, TRUE);
    $version = !empty($library['version']) ? $library['version'] : $this->t('Unknown');
    // Get all settings.
    $settings = $this->config('juicebox.settings')->get();
    // If the base language list is not officially saved yet, we can get the
    // default value from the library settings.
    if (empty($settings['base_languagelist'])) {
      $settings['base_languagelist'] = $library['base_languagelist'];
    }
    $form['juicebox_admin_intro'] = [
      '#markup' => $this->t("The options below apply to all Juicebox galleries. Note that most Juicebox configuration options are set within each gallery's unique configuration form and not applied on a global scope like the values here."),
    ];
    $form['apply_markup_filter'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Filter all title and caption output for compatibility with Juicebox javascript (recommended)'),
      '#default_value' => $settings['apply_markup_filter'],
      '#description' => $this->t('This option helps ensure title/caption output is syntactically compatible with the Juicebox javascript library by removing block-level tags.'),
    ];
    $form['enable_cors'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Allow galleries to be embedded remotely (CORS support)'),
      '#default_value' => $settings['enable_cors'],
      '#description' => $this->t('Enable cross-origin resource sharing (CORS) for all generated Juicebox XML. This will allow all origins/domains to use any Juicebox XML requested from this site for embedding purposes (adds a <em>Access-Control-Allow-Origin: *</em> header to all Juicebox XML responses).'),
    ];
    $form['multilingual'] = [
      '#type' => 'details',
      '#title' => $this->t('Multilingual options'),
      '#open' => TRUE,
    ];
    $form['multilingual']['translate_interface'] = [
      '#type' => 'checkbox',
      '#title' => $this->t('Translate the Juicebox javascript interface'),
      '#default_value' => $settings['translate_interface'],
      '#description' => $this->t('Send interface strings to the Juicebox javascript after passing them through the Drupal translation system.'),
    ];
    $form['multilingual']['base_languagelist'] = [
      '#type' => 'textarea',
      '#title' => $this->t('Base string for interface translation'),
      '#default_value' => $settings['base_languagelist'],
      '#description' => $this->t('The base <strong>English</strong> interface text that Drupal should attempt to translate and pass to the Juicebox javascript for display (using the "languageList" configuration option). This text will be treated as a <strong>single string</strong> by Drupal and must be translated with a tool such as the Locale module. Note that this base string value will rarely change, and any changes made to it will break existing translations.'),
      '#wysiwyg' => FALSE,
      '#states' => [
        // Hide the settings when the translate option is disabled.
        'invisible' => [
          ':input[name="translate_interface"]' => ['checked' => FALSE],
        ],
      ],
    ];
    $form['multilingual']['base_languagelist_suggestion'] = [
      '#type' => 'item',
      '#title' => $this->t('Suggested base string for currently detected Juicebox version (@version)', ['@version' => $version]),
      '#description' => new FormattableMarkup('<pre>' . $library['base_languagelist'] . '</pre>', []),
      '#states' => [
        // Hide the settings when the translate option is disabled.
        'invisible' => [
          ':input[name="translate_interface"]' => ['checked' => FALSE],
        ],
      ],
    ];
    $multisize_disallowed = in_array('juicebox_multisize_image_style', $library['disallowed_conf']);
    $multisize_description = '<p>' . $this->t('Some versions of the Juicebox javascript library support "multi-size" (adaptive) image delivery. Individual galleries configured to use the <strong>Juicebox PRO multi-size (adaptive)</strong> image style allow for three different source derivatives to be defined per image, each of which can be configured below. The Juicebox javascript library will then choose between these depending on the active screen mode (i.e. viewport size) of each user. See the Juicebox javascript library documentation for more information.') . '</p>';
    if ($multisize_disallowed) {
      $multisize_description .= '<p><strong>' . $this->t('Your currently detected Juicebox version (@version) is not compatible with multi-size features, so the options below have been disabled.', ['@version' => $version]) . '</strong></p>';
    }
    // Mark our description, and its markup, as safe for unescaped display.
    $multisize_description = new FormattableMarkup($multisize_description, []);
    $form['juicebox_multisize'] = [
      '#type' => 'details',
      '#title' => $this->t('Juicebox PRO multi-size style configuration'),
      '#description' => $multisize_description,
      '#open' => !$multisize_disallowed,
    ];
    // Get available image style presets.
    $presets = image_style_options(FALSE);
    $form['juicebox_multisize']['juicebox_multisize_small'] = [
      '#title' => $this->t('Small mode image style'),
      '#default_value' => $settings['juicebox_multisize_small'],
      '#description' => $this->t('The style formatter to use in small screen mode (e.g., non-retina mobile devices).'),
    ];
    $form['juicebox_multisize']['juicebox_multisize_medium'] = [
      '#title' => $this->t('Medium mode image style'),
      '#default_value' => $settings['juicebox_multisize_medium'],
      '#description' => $this->t('The style formatter to use in medium screen mode (e.g., desktops and retina mobile devices).'),
    ];
    $form['juicebox_multisize']['juicebox_multisize_large'] = [
      '#title' => $this->t('Large mode image style'),
      '#default_value' => $settings['juicebox_multisize_large'],
      '#description' => $this->t('The style formatter to use in large screen mode (e.g., expanded view and retina laptops).'),
    ];
    foreach ($form['juicebox_multisize'] as &$options) {
      if (is_array($options)) {
        $options += [
          '#type' => 'select',
          '#options' => $presets,
          '#empty_option' => $this->t('None (original image)'),
          '#disabled' => $multisize_disallowed,
        ];
      }
    }
    return parent::buildForm($form, $form_state);
  }

  /**
   * {@inheritdoc}
   */
  public function submitForm(array &$form, FormStateInterface $form_state) {
    $library = $this->juiceboxFormatter->getLibrary(TRUE, TRUE);
    if ($form_state->getvalue('translate_interface') && !empty($library['installed']) && $form_state->getvalue('base_languagelist') != $library['base_languagelist']) {
      $this->messenger()->addWarning($this->t('Interface translations are enabled but the base translation string does not match the suggested value for your version of the Juicebox javascript library. If some parts of the Juicebox interface do not appear translated correctly please verify that your base translation string is correct.'));
    }
    $this->config('juicebox.settings')
      ->set('apply_markup_filter', $form_state->getvalue('apply_markup_filter'))
      ->set('enable_cors', $form_state->getvalue('enable_cors'))
      ->set('translate_interface', $form_state->getvalue('translate_interface'))
      ->set('base_languagelist', $form_state->getvalue('base_languagelist'))
      ->set('juicebox_multisize_small', $form_state->getvalue('juicebox_multisize_small'))
      ->set('juicebox_multisize_medium', $form_state->getvalue('juicebox_multisize_medium'))
      ->set('juicebox_multisize_large', $form_state->getvalue('juicebox_multisize_large'))
      ->save();
    // These settings are global and may affect any gallery embed or XML code,
    // so we need to clear everything tagged with juicebox_gallery cache tag.
    Cache::invalidateTags(['juicebox_gallery']);
    $this->messenger()->addMessage($this->t('The Juicebox configuration options have been saved'));
  }

}

re. coding standards ... I just ran a bunch of modules, both contrib and those that come in core/modules through the DrupalPractice option of the Standards. There are plenty of unused variables and many dependency injection issues. Most common is "t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and $this->t() instead". I think that I've eliminated that last one entirely from my version of Juicebox that can be found on my github site. I may not have done that elegantly since it was my first crack at dependency injection so a review by more experienced developers would be welcome as we move towards publishing this.

My github repository is at:

https://github.com/fkelly12054/

I will be happy to add anyone as a collaborator. My repository is just a stopgap measure ... I have no intention of trying to replace the official Drupal repository for juicebox that's here on drupal.org. Nor do I have the expertise to do so.

DK40 contributed code that got me 90 to 95 percent of the way to resolving the dependency injection issues in settingsform.php. After some fumbling around this morning (11/30) I made one more change that got us over the line ... at least on my local test system.

The only other dependency injection issue is in Juiceboxformatter.php. I'm working on that. I'm reading the book as I go, so if anyone can contribute that will be helpful.

I don't think there are a lot of other changes to make. Then we will need our maintainer to make a commit. I'm pretty sure we can do a commit that (a) resolves non-trivial coding standard issues, (b) takes care of all dependency injection issues (c) removes library dependency and (d) is Drupal 9 compatible. But we won't know it until we do it. I'm sure we'll want some kind of beta or test release so people can run it through the wringer. I don't use all the features of Juicebox and it's hard for me to test.

For at least the last week I've been able to run the code that's now on github on my localhost Wampserver. I have a Drupal8 (8.9.9) system and a Drupal 9.0.9 system set up. I think the reason I'm not running into issues on Drupal 9 so far is because I'm not executing the portions of code that have dependency injection issues. But we'll see.

just a quick progress report from #30. DK40 has resolved the dependency injection issues and we have cleared up almost all coding standards issues that are reported by phpcs (code sniffer). There are some inconsistencies within code sniffer that may keep us from getting to 100% but nothing remaining is critical.

My github page is a decent intermediate location for working things out but eventually we will need to get everything back on Drupal dot org.

Generally, as of 12/8/2020, we are making good progress on the "moving forward" project. There are a couple of Drupal 9 compatibility issues to be sorted out and one roadblock we just discovered on 12/7.

The roadblock is this: in the removing libraries dependency issue, I moved and revised all the code from the contrib libraries module that detected where the libraries js for Juicebox was located and built the appropriate $libraries variable. That's now inside the juicebox module in juiceboxformatter.php and the juicebox module. As far as I know, that works well.

The problem is this: there are two supported ways to build a Juicebox gallery. One is to embed it within a content item (often named Juicebox Gallery) but the name is irrelevant. Then use the embed instructions within each content item:

https://www.juicebox.net/support/embedding/

These instructions result in loading the juicebox library for each content item e.g.,
<script src="jbcore/juicebox.js"></script>

It works fine, though is perhaps a bit redundant. Separate longer term issue but I think this means should be replaced once we are safely on Drupal 9.

The second way to build a gallery is to use the Juicebox field formatter and add individual images (or media items) to the Gallery. Instructions for that are in the Juicebox documentation. The problem with this approach is that it doesn't assure that the juicebox js library is added to each item. The contrib library module took care of this.

So now the issue is: what's the best way of doing this. Options: (1) use the juicebox.libraries.yml file? It might work, but then I think it would be loading the library on every page load of a Drupal site. It would be better to only load it when an actual gallery is loaded.

(2) Duplicate the load that's used in the juicebox embed (above) and put it in juicebox-embed-twig-html script. I've experimented with that. But we allow the library file to be in either /libraries/juicebox or /sites/all/libraries/juicebox. So we'd have to have the embed load whichever of those locations was appropriate.

(3) Replicate some of the contrib module logic for loading a library over into the juiceboxformatter.php and or juicebox.module. There is a lot of code in there that we don't need: we've already detected where the library files are. Unfortunately it appears the contrib library module uses a deprecated function:

        // @todo Avoid the usage of _drupal_add_js() and _drupal_add_css()
        call_user_func('_drupal_add_' . $type, $data, $options);

Removing this is a todo in the libraries module and most likely something we need to do going forward. But how? I'm looking for recommendations.

(4) Another approach?

I'm open to suggestions. I (or my colleague DK40 who has been helping right along) will do the implementation and test over on my github site, test it there and we should be ready for @Neslee to move a copy back over here.

We have already removed almost all coding standards issues and dependency injection issues and tested on both Drupal 8.9.x and 9.09 and 9.1. This is still going to need further testing by the community here and at least one beta (dev) type release before it's ready for prime time.

The drupal_add_js function was for Drupal 7 and shouldn't be used here. I tried anyway ... just generates an error.

Sticking the <script src="/sites/all/libraries/juicebox/juicebox.js"></script> in the twig embed file seems to work. But we'd need to, at a minimum, make it a variable with the content based on where the library is stored. Seems ugly to me.

I'm not sure if putting the load in the libraries.yml is desirable. Think not.

In the juiceboxformatter.php getlibrary function we "discover" reliably where the library is. I just can't figure out how to load it from there.

Not sure it it would be okay to just copy the library js file to the juicebox/js directory and load it from there.

Kind of stuck.

Still looking into this:

https://www.drupal.org/node/2274843
Adding stylesheets (CSS) and JavaScript (JS) to a Drupal module

is the reference document we need. How to implement this is an open question (to me). I've tried a libraries.yml that looks like this:

juicebox:
  js:
    /sites/all/libraries/juicebox/juicebox.js: {minified: true}
juicebox.local:
  js:
    js/juicebox_load.js: {}
  css:
    theme:
      component:
        css/juicebox_styles.css: {}
  dependencies:
    - core/jquery
    - core/drupal
    - core/drupalSettings

But it's not at all clear to me when that file actually gets processed in the Drupal page loading sequence.

The old contrib module libraries (filename: libraries.module.php) had a load function. But that's deprecated. I'm having trouble even tracking down where it was executed in the old code.

We need to apply one or more of the techniques in https://www.drupal.org/node/2274843. But then we need to make sure they don't conflict or overlap the embed instructions for pre-built galleries.

One problem is that neither the Juicebox or the libraries module has been truly maintained in years ... like 3 of them.