🇨🇭Switzerland @florianmuellerch

Hi @alex.bukach, thanks for reaching out!

I have a hard time understanding the issue deep enough. This module only does one thing, which is to override the libraries at `core/jquery` and `core/jquery.once` (readding the latter), see jquery_once.module. The other thing it does is seperately providing the files as new dependencies called `jquery_once/jquery` and `jquery_once/jquery.once`.

I could only assume that this could happen if you both declare a dependency on `core/jquery` and `jquery_once/jquery` or `jquery_once/jquery.once`, leading to both loading the jQuery library seperately (`core/jquery` and `jquery_once/jquery`).

Can you check your dependencies that you for example only ever use `core/jquery` and `core/jquery.once`, and never `jquery_once/jquery`? Keep in mind that the core itself at this point still loads `core/jquery` sometimes automatically.

Let me know if this helps!

Someone with a bit of time on their hands should create a guide on drupal.org (I don't even know how that would work) and start a comprehensive documentation about how render arrays are working and how they're supposed to be used. Therefore I suggest to leave it open until we find that "someone".

@quietone Thanks for the engagement :-)

I raised the issue out of the experience that all developers that I newly introduced into the Drupal ecosystem seem to struggle to grasp this concept, and still to this day, I didn't find neither a really comprehensive guide, nor an absolute overview over possible render array keys.

This does not only need to be in documentation: Imagine a contrib module that goes through all modules and lists their render array keys. However I'm not sure if, as a contrib module, you would have access to list all the types and themes built into the core itself.

There's just guidance and overview that is still lacking. If you have good resources (maybe also from elsewhere) please feel free to share!

@enchufe that is simply pure gold, thank you so much! You saved me a loooot of headache!

And for the issue, I now use the dev branch and the change works absolutely fine, so I think it could be released. Could this be closed, or RTBC?

@enchufe thanks for the issue, was looking for this!
How do you solve the delayed loading of any given script provided by a module (when consent was not yet given), simply by its attributes? Any hook I don't know of yet?

Hi @bvoynick

Thank you very much for your inputs and efforts for the merge request! :-)

I very much like the idea of handling cache properly. However I don't quite understand the use case in this particular example.

Could you provide an example where this comes into play? At the moment, the config is read directly on call, and then held in local memory. How does cache metadata affect this process?

Hi @brockfanning, thank you for your interesting question!

I personally assume that Drupal Core aims to remove jQuery alltogether, leading to both core/jquery and core/jquery.once libraries being dropped out. I plan to keep this module as compatible as possible for as long as possible because I simply like the way jQuery and jQuery.once work.

The only way this module would not be future-proof is if core decided that under core/jquery they release a piece of software that is different from default jQuery versions, and would be missing as we simply override it. But this would in fact break a lot of existing installations even more, so I don't see any evidence of this.

As a last resort, you could always take the code of this module (which is really fairly simple) and put it in your own module and adapt some changes, if you need something urgently. However I would assume that others might encounter the same issues, raising the need for an issue here in the issue queue to tackle the problem for everybody.

Have a great sunday and a nice week,
Florian

Hi @dusandelucia

The short answer is: "It depends" :-)

I personally would not migrate any custom code, if you just started and then installed this module. Every jquery.once usage will continue to work as usual, so there's no need to change your code.

However all other modules most likely already have changed their own code and use the built-in Drupal.once(), which is also fine.

I would avoid using both jQuery.once() and Drupal.once() in the same module, let alone in the same file. I would decide on one of the two and then consistently only use that, to avoid problems.
In fact, I also have a project running that uses now both Drupal.once() and jQuery.once() in the same large module, but it runs just fine - if the two libraries do their own jobs and don't intersect with each other.

Hope that helps - happy site building!

Well well how the turntables...
Apparently it was all a mistake again. I later found out that even when using 3.6.3 again, it wouldn't work anymore.
Root cause was something completely different: Another module included another instance / version of jQuery which ultimately caused the issue.

@InaW sounds promising!
When I tried something similar, I ran into issues when I saved the node - Drupal threw an error that "untranslatable fields cannot be changed and must be changed on the original language" or something similar... Did you test that solution? Works fine?

@InaW I didn't find a solution to this particular problem yet. Instead I decided that editors on our platform actually probably want asynchronous translations, that's why I enabled translation on the paragraphs field instead, despite being unsupported. However in your particular case, there's no solution for that and I think there should be.

florianmuellerCH → created an issue.

florianmuellerCH → created an issue.

I've just released official 1.0 of the module, however I'm totally fine if you get a tested and working solution in your MR, I would merge that and release 1.1 from that.

I just would like more feedback from people on this, and the MR would have to be adapted.

Hi @demonde
Thanks for your suggestion!
I wasn't aware that there were any more regularly used libraries that relied on jQuery. Apart from jquery.cookies, there were apparently also a lot more, like jquery.ui, jquery.joyride, jquery.form etc...

I focused the module on jQuery.once as I was in need for that, and it's also quite prominent in the name. Therefore I think I cannot extend the modules scope to bring back "all" jQuery libraries.

However I would love to link it on the project page if someone does a module like this, e.g. "Bring back jQuery" :-)
Feel free to use and re-use this module's code if it's of any use to you, if you want to develop such a module.

Hi @stox!
Good idea :) I just needed the module asap, that's why I threw it together like that.
I'm not entirely sure how I could control composer dependencies in particular, especially as Drupal itself does add a composer file when the project is released and packed... Would you or anyone else mind making a PR or a patch with a draft?

Thanks!

Confirming that #53 did the trick for me on 2.0.1, while #56 didn't solve the problem?

I'm running Drupal 10.1.0 and I had the issue as well with the table headers being repeated, so I can confirm this is still an issue.

Also +1 from me, patch removed the error "Invalid address: (Sender)". Thank you!

Thanks for the initiative and the MR!

Thank you very much @audacus for bringing this issue to my attention and fixing it!

Thank you all for your work! #21 and the info in #22 helped me a lot!

I added a JS behavior to make the selected elements sortable. To do that I had to add my library and a class in the base element:

    $element = [
      '#type' => 'details', // I added this directly here
      '#open' => $default_open, // I added this as a parameter
      '#title' => $title, // I added this as a parameter
      '#attributes' => [
        'id' => Html::getUniqueId('entity-browser-' . $entity_browser_id . '-wrapper'),
        'class' => [
          'entity-browser-form-trait-element', // NEW CLASS for JS behavior
        ]
      ],
      '#attached' => [
        'library' => [
          'my_module/entity-browser-trait' // ATTACH new library
        ]
      ]
    ];

Be sure to add the dependency to core/sortable in your libraries.yml.

(function ($) {

  Drupal.behaviors.entityBrowserTraitSortable = {
    attach: function (context, settings) {
      $(once('sortable-entity-browser-images', '.entity-browser-form-trait-element table.responsive-enabled tbody')).each(function() {
        let $tbody = $(this);
        let $parent = $tbody.closest('.entity-browser-form-trait-element');
        $tbody.find('>tr').css('cursor', 'move'); // This is a convenience thing and could be moved to CSS
        Sortable.create($tbody[0], {
          onEnd: function (e) {
            let $to = $(e.to);
            let list = [];
            $to.children('tr').each(function() {
              list.push($(this).attr('data-entity-id'));
            });
            $parent.find('input[type="hidden"].eb-target').val(list.join(' '));
          }
        });

      })
    },
  };

})(jQuery);

As this affects core and I have the need to apply multiple patches, I created a patch for 10.x to apply.

I would love to offer my time as I love Adminimal on all my projects.
I can opt into security advisory policy and also have already multiple own and co-maintained contrib modules as a background.