Caching Plugins and ContentHash

[ajgagnon]

Using Webpacks contenthash in the filename doesn't work well with most caching plugins. This is because when a plugin is updated, best practice is not to clear site cache. This can cause 404 errors with javascript files, since the filenames can change on each release and the page html is cached with the previous files.

I would propose removing the [chunkhash:8] from the webpack config and instead rely on plugin version query variables to invalidate the cache.

wp-webpack-script/packages/scripts/src/config/WebpackConfigHelper.ts

Line 238 in 73e1702

this.isDev ? '[name]' : '[name]-[contenthash:8]'

This will ensure plugin javascript does not break in the case where caching plugins are preset.

As a workaround, perhaps there could be an option to disable the hash portion with an option. Would be curious to know your thoughts.

[swashata]

I understand what you are saying, but I do not think having an option to remove contenthash:8 would solve it. The reason is simple. The output and order of output by webpack itself can change, depending on how you are importing and doing code splitting.

In such cases, trying to enqueue older files from older version of manifest can lead to bigger errors.

One solution would be to completely remove runtime chunk and split chunks. But that would deny the very purpose of this tooling. We do want to be able to

1. Load shared chunks among different entries.
2. Split code with lazy imports.
3. Have different webpack runtime so that it works with other plugins using the same tooling.

I hope I am making sense. Let me know what you think.

[ajgagnon]

Ah, makes complete sense. Very helpful explanation. I didn't know the order could change with Webpack, so definitely a no-go. I really wish caching plugins would invalidate cache on plugin update, but for some reason that's not best practice. Seems there's no good solution here, unless we can get caching plugins to change their behavior.

[swashata]

What caching plugin are you using? I have used WP Super Cache and it does exactly that.

[ajgagnon]

WP Rocket is one specific one:

https://docs.wp-rocket.me/article/78-how-often-is-the-cache-updated

But I've also experienced this with Cloudways/Breeze. I think some standard behavior for some of these is not to clear cache when a plugin is updated.

[ajgagnon]

Just had a random thought on this (after 6 months 🤣 ).

It sounds like content hash could be changed to a query parameter (much like how WordPress versions files):

filename: `${this.appDir}/[name].js${!this.isDev && '?v=[contenthash:8]'}`,

Interested to know your thoughts on this. If you think it's worth exploring I'm happy to open a PR.

[bonakor]

I think I do have the issue. What would you recommend to fix it?