Uncaught ReferenceError: loadjs is not defined after drupal core upgrade 9.5.1

There is a syntax error with JavaScript on that site. Turn off JavaScript aggregation to find out the full details.

I also have this. I use advagg. When I disabled aggregation on /admin/config/development/performance I don't have error. But with enabled (even if Advagg js minification disabled) I see the error in console and any view edit page is broken

But with disabled advagg all works

Ok, let's move this to that contributed project.

Related to Advagg Bundler module

I am also having this error. Disabled AddVagg didnt fix the issue, I had to disable both AdvAgg AND core js minification, so this does not seem to be isolated to this module.

I was able to fix my issue by just adding core/loadjs to my theme libraries dependencies

Move the issue to drupal/core.

The issue is related to default Drupal aggregation. The Loadjs library is used in drupal.ajax to add Js files. Added weight to loadjs file to move up the code in the aggregation file.

I created a patch that is working well for me on Core 9.5.3. I am attaching it here for use while we wait for the code to be added to the core branches.

Hope it works for you all.

Someone please add clear steps to reproduce to the issue summary so we can characterize the bug and test the solutions.

🐛 Ajax.js commands stuck when adding JS with nomodule attribute Active

Fixed syntax error from #14

Just to be clear: we don't comment out lines. Just change the code as needed.

Someone please add clear steps to reproduce to the issue summary so we can characterize the bug and test the solutions.

My issue that I was seeing was the following:

- Drupal Core 9.5.3
- Running PHP 7.4 and MySQL 5.7
- Poll Module installed at version 8.x-1.5

When placing a new poll styled in my theme in the footer of a site, the poll would not display at all for anonymous users. It worked perfectly fine for logged in users.

The console error was "Uncaught ReferenceError: loadjs is not defined in site"

Let me know if you need more information.

Interesting! Please add those steps to the issue summary, then we can remove the tag and move this along.

Can you reproduce that on https://simplytest.me/ ? That’s a quick way to ensure the bug reproduction is valid. It’s admin/admin to log in one of those sites.

Thank you!

Same here with views_infinite_scroll 2.0.1 (drupal 9.5.x, PHP 8.0).
When logged in it works though. I noticed the loadjs library gets added much later as anonymous.
The patch seems to solve the issue.
I will investigate further when I have some time.

Seems the poll module is not available on https://simplytest.me

That is unfortunate. I commented on #3314942: Missing project(s) from dropdown → .

It looks like infinite scroll is available.

could be similar to #1988968-322: Drupal.ajax does not guarantee that "add new JS file to page" commands have finished before calling said JS → ?

Is the dependency to loadjs declared properly in the libraries that uses it as said in #9? Using weight is usually a indication that dependencies are not declared properly

Stumbled upon this issue when having the same problem. Can confirm setting the proper dependency fixes the issue, so this issue is probably works as designed.

Interesting, in my case it is not a dependency missing but some custom JS behaviors had the "use strict" directive directly in the file, in the global scope as follows:

"use strict";

(function ($, Drupal, once) {
  // some custom JS behavior.
})(jQuery, Drupal, once);

Moving this directive within the function solves the issue.
I guess this is due to the fact that loadjs doesn't declare itself using var?

loadjs = function() {...}();

Why is it like this?

I was getting this in 9.5.0 on a site. I had to disable aggregation and clear the cache. After that I could use the core media library modal again.

By adding core/loadjs in custom theme, error was gone (same as #9)

Just ran into this issue. For me it occurs when adding any JS asset via asset_injector → .

Adding a console.log('X'); is enough.

I created an issue there: 🐛 Getting "loadjs is not defined" error when adding any JS asset Closed: won't fix
But I guess this issue is the root cause.

Glad to hear @Anybody!
I think a lot of people are having this issue because of that.
Raising/changing the dependencies is only a workaround which pushes the loadjs definition above the strict directive.

To anyone who had or have this issue: please double check and ensure that you do not have any "use strict" in the global scope.

I think the problem is because the variable is not defined and if we run JS in a strict mode that error jumps.
I just created a simple patch to fix the issue and the fix is only defining the variable.
It worked for me on Drupal 9.5.x.

Well #30 is definitely the case and it's something that can happen in any library or module and break the site. So I'm not against looking for fixes like #32, but
It should then happen in the loadjs library I guess (https://github.com/muicss/loadjs ?)
Code-wise I don't var loadjs would be correct, instead I'd tend to window.loadjs?

But proof me wrong and I guess there's a reason for the current implementation (hopefully)? ;)

@Anybody (#33) having that the loadjs script is loaded in the global scope we don't need to use `window.loadjs = ...` because `var loadjs = ...` will be in the same scope and `window.loadjs === loadjs`, so we don't need to define the variable directly in the window object.

And you are right that's fix should be done in the LoadJS Library instead.

I made a quick example here https://codepen.io/diarcastro/pen/BaqQwxg

Can confirm #31.

In our case, we have compiled JS in modules/themes whose output automatically gets a file-level "use strict";. This makes sense if the compiled JS is evaluated on its own (e.g. added via its own script tag, or eval'ed on its own).

But since that compiled JS is added as a library, it is subject to aggregation. Drupal aggregation is just a simple "concat a bunch of JS" operation, which means ANY JS that's aggregated together with one that has a file-level "use strict"; is evaluated in strict mode entirely - and will break some arbitrary library that wasn't expecting it.

Also, for regular scripts, "sloppy mode" is the browser's default execution mode while strict mode is opt-in. Although strict mode is encouraged, one cannot assume all scripts are written in strict mode. This may be the case for loadjs.

- https://developer.mozilla.org/en-US/docs/Glossary/Sloppy_mode
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict...

So to sum it up:
- Aggregation can cause scripts declaring strict mode to be concatenated with ones that don't expect strict mode, breaking the latter.
- Therefore JS included in libraries SHOULD NOT have a file-level "use strict"; to avoid breakage.
- Any JS that is explicitly enforcing strict mode should move "use strict"; from a file-level to a function-level (e.g. wrap your script in an IIFE with "use strict";)
- No changes are needed for loadjs. Instead, fix the code introducing "use strict"; with the suggestion above.

#9 worked for me: addding theme dependancy "core/loadjs"

Just hit this, was driving me bonkers. I'm going to try the latest patch.

Patch #32 works for us, thank you!

I do not know how exactly to reproduce the issue because it only affected some of our environments, very strange. The patch #32 fixes the glitch.

Settings this to NR for #32, still I'm not enough JS expert to tell about possible side effects. Is here someone who can tell?

@joseph.olstad did you grep your code for #30 / #35 as root cause?

Still I think it would be better to be safe this can't happen even with strict mode enabled in global space. We now have clear steps to reproduce described in #30-35

Will need a test case but not sure we should be patching an asset library. Could be wrong there but I really doubt it.

@Anybody,
I did grep my code for #30 / #35 as a root cause, wow, that was intense!

The fix should be done in the loadjs library, all you have to do is try to fix this in your project without the patch and then lose your marbles.

The simple fix proposed by patch #32 vastly improves "developer experience".

Re-rolled #32 for 10.3.1.