ChunkLoadError on front-end Faceted Search block (v1.0.3)

Suporte
1

The Faceted Search block fails to mount on the front-end with the following console error:

ChunkLoadError: Loading chunk 4179 failed.
(error: /wp-content/plugins/tainacan/assets/js/4179.js?ver=f83d9a311f4cc74248d1)

Other chunks also return 404: 9681, 9557, 1224, 9413, 2268, 5220, 4824, 6458, 2702, 3153, 834, tainacan-chunks-blocks-faceted-search-theme.js.

The block displays: “An error occurred while loading some Tainacan components. Please reload your page (CTRL+SHIFT+R).”

Steps already taken:

  • Cleared browser cache and tested in private mode in Brave, Firefox and Chromium

  • Disabled WP Rocket and deleted all its cache directories

  • Purged the host server cache (o2switch / LiteSpeed)

  • Flushed Redis object cache (wp cache flush) and deleted all transients

  • Deactivated all security and cache plugins (including SecuPress)

  • Regenerated permalinks

  • Fully uninstalled and reinstalled the plugin via WP-CLI

  • Tested versions 1.0.3, 1.0.2, 1.0.1 and 1.0.0 — same error on all

  • Tested with a brand new page and a freshly inserted Faceted Search block — error reproduces immediately

Environment:

  • Tainacan: 1.0.3

  • WordPress: 6.9.4

  • PHP: 8.4

  • Hosting: o2switch (shared, LiteSpeed)

  • Theme: Medicity Pro

Thanks in advance
Best regards

2

Hi @e.lito, how are you?

That is weird. To be honest I don’t know what could be causing this and I was unable to reproduce. Maybe could you give a try with a development build from a release that we are about to put out this week?

I would recommend after installing clearing the cache again, specially the browser-side one. Let us know if this solves it.

3

I installed the dev build but the issue persists. After investigating further, I found a clear mismatch between the runtime expectations and the packaged files:

Runtime expects (from tainacan_blocks_common_scripts.js):

js

r.u = e => (({...}[e] || e) + ".js?ver=" + {4179:"f83d9a311f4cc74248d1",...}[e])

So it requests 4179.js?ver=f83d9a311f4cc74248d1.

Files actually shipped in the ZIP in assets/js/:

10.1209a5281dcd6ce649b3.js
1035.8e825042d42d85befd12.js
1070.3a1b24314a7167bf77c5.js
...

All 170 chunk files use the format [id].[hash].js (hash in the filename), and none use [id].js. So every chunk request returns 404.

Looks like a webpack config mismatch between output.chunkFilename (which produces hashed filenames) and the runtime URL builder (which expects bare [id].js with the hash as a query string). Either the chunk files should be renamed to drop the hash, or the runtime should construct URLs with the hash inside the filename.

Happy to test any patch.

4

Hi @e.lito!

I think your `tainacan_blocks_common_scripts.js` is being served a cached version. I’ve opened the .zip that is in the Drive and search for this 4179 reference (in the tainacan_blocks_common_scripts.js), it is not there.

5

I was seeing if I could debug something for you here @e.lito. It seems weird to me that your page is requesting this scripts with the `?ver=…` at the end:

image
image1585×388 246 KB

We do not add those versions, the version hash is in the end of the file. Which to me reinforces the idea that some caching plugin is changing those requests. This is the expected behavior in version 1.0.3 (and 1.1.0, which I sent to you)

image
image1585×388 162 KB

6

Solved! The culprit was XtremCache, a proprietary caching system on o2switch (French shared hosting).

Empty XtremCache for the site fixed it.

Thanks @mateus.m.luna for the help!