Items Submission – Tainacan - this is showing an error for me on multiple browsers and devices.
Happy to raise bug on Github, thought I’d report here first.
Merhaba, aynı sorunu ben de yaşadım ve şu şekilde çözdüm:
Kullandığınız önbellek eklentisinin ayarlarından, hata aldığınız koleksiyonlar sayfasını önbellekleme (cache) işleminden hariç tutmanız gerekiyor. Böylece sayfa her ziyaret edildiğinde veriler canlı olarak çekilecektir. Bu yapılandırmanın ardından, önce sitenizin önbelleğini, sonrasında ise hosting paneliniz üzerinden sunucu önbelleğini tamamen temizleyin. İşlemleri tamamladıktan sonra sayfayı gizli sekmeden kontrol ederseniz sorunun çözüldüğünü göreceksiniz.
English
Hello, I experienced the exact same issue and found a solution for it:
You need to exclude the collections page (where you are encountering the error) from your caching plugin’s settings. This ensures the page fetches live data every time it is visited, rather than serving a cached version. Once you have configured this, clear your website’s cache, and then purge the cache from your hosting control panel. After completing these steps, check the page in an incognito window, and the issue should be resolved.
Aaand it was cache! Nut again on our side, due to our Cloudflare services.
Please give it a try again, maybe using CTRL+SHIF+R to also clear your browser’s cache.
Hi , @mateus.m.luna glad we caught the culprit! 
Since this seems to be a recurring headache with Cloudflare or local caching plugins like LiteSpeed, I did some deep diving into why this specific cache conflict happens so often.
The root cause is actually tied to the Webpack chunking architecture. When Tainacan generates or updates new JS chunks, the old JS files are physically deleted from the server. However, caching systems (like Cloudflare or LiteSpeed) keep serving the old, static HTML that still tries to call those deleted .js chunks. When a visitor’s browser tries to fetch them, it hits a 404 `ChunkLoadError` and the UI breaks.
While excluding the page or clearing the cache works as a temporary workaround for us users, maybe the team could consider a permanent solution under the hood? A few ideas that came to mind:
1. Cache Purge Hook: A built-in trigger to automatically clear popular caches (Cloudflare, LiteSpeed, WP Rocket) whenever Webpack JS chunks are regenerated.
2. Grace Period: Keeping old chunks on the server for a short transition period (e.g., a few days) instead of deleting them immediately.
3. Fallback Mechanism: A retry/fallback mechanism on the frontend if a JS chunk fails to load.
Just wanted to share these findings in case it helps make Tainacan even more stable in future updates. Thanks for all your hard work. 
Thanks @ARS61 @mateus.m.luna all working now 
Hi @ARS61!
Yeah this has been a challenge for us for years, we’ve tried some alternatives but have not found a good solution yet. We have a sophisticated way of lazy-loading assets with conditioner.js. Applying ?ver= to the end of the parent scripts already tells caching servers that things should be reloaded, but if the HTML page itself is cached, then even the link to the new asset is lost.
A purge when Tainacan updates sounds right, but most of the caching plugins people hit this with already purge the whole site on any plugin update. Doing it again from Tainacan would not cover Cloudflare unless that site already has the Cloudflare plugin connected, and it would not cover the browser cache. That part is why the component already suggests a hard reload.
Keeping the previous chunk files in the package would let an old cached page keep loading the files it was built with: this the one I think would work most. But there is a cost… those hashed chunks are about 7 MB, shipped again on top of the new ones, and they would have to stay for at least one release.
I’ve also considered fixed filenames, including a ?ver= on the chunk, but that does not avoid the mismatch. The cached page still runs the old loader, and that loader then receives the new file from the same path. Dropping the split and shipping one big script would avoid the missing file, at the cost of every Tainacan page downloading every block.
So the suggestions are on the table, and each one trades a broken load for a size, cache, or coverage problem we have not picked between yet. We will follow up here when we do.