CUNY Academic Commons

Hi Marilyn,

Can you pass us some links so we can take a look?

I've asked Joe to provide that. Will update ASAP.

Thanks, Marilyn.

I'm seeing the behavior described on this sandbox site owned by Joe https://joessandbox2.commons.gc.cuny.edu/ and also on other sites. I believe he's right that the '@wordpress/interactivity' module issue is related. I bisected the issue down to a7a7a833cff7c2e1f95fb307ddd38f123c612893, which is where we updated to WP 6.4.x to 6.5.2 (this is where the interactivity API was introduced). I've begun to look for underlying causes but haven't figured it out yet. Adding Jeremy as a watcher.

I think I've solved the problem, though I'm not sure I can fully explain the underlying causes. Here's the fix: https://github.com/cuny-academic-commons/cac/commit/2cc7263785418385b70b20abcd50d8dbc32e3381

Briefly, the incorrect use of wp_enqueue_script() caused the "cac-shoelace-copy" script to be loaded in the header rather than the footer. At the same time, we are filtering the script tag for cac-shoelace-copy to force it to load as type="module". When this script was loading in the head, it was causing the browser to initialize all required modules. But this happened before WP had a chance to load its own importmap, which includes @wordpress/interactivity. As a result, when the browser reached WP's importmap, it threw an error, saying that modules had already been loaded for the page.

Moving the 'cac-shoelace-copy' script to the footer appears to fix the navigation problem. And in my tests, it seems that the Help dialog is still working as expected, though I would like Ray to have a look at this.

It seems like there should be a centralized way to register modules, in the same way that we enqueue scripts and WP sorts out the dependency tree. But I couldn't see this at a glance, and my understanding of how browsers recognize and load modules is quite limited. Any insight from the team would be welcome.

Thanks for catching my mistake, Boone!

It looks like WordPress 6.5.0 introduced script modules -- https://make.wordpress.org/core/2024/03/04/script-modules-in-6-5/ -- so it looks like we can switch to using wp_enqueue_script_module() for cac-shoelace-copy. I've done some testing locally and this works well so I've committed this here: https://github.com/cuny-academic-commons/cac/commit/2a41ecb2014809f6f0aa35c53d381a1277334985 .

Working now - Joe writes:
Thank you, but I just went through and it's working now, and console doesn't return this error anymore. I don't know what got changed or updated, but it seems resolved. Thanks!

Thanks!