The message was added to help... imagine how hard it was before the helpful message... :)

in my case I only saw the message AFTER I had found the problem

yes - because Historically Joomla has never checked if a server is already going to gzip the sites output once PHP hands the response back to apache, before apache once again gzipping (and therefore corrupting) the output.

I guess the change you are after is finding a way to tell if a server is going to gzip the output after Joomla with a crystal ball ahead of time, and therefore not firstly (unperformantly) first gzipping using PHP code.

There are several things that can enable GZIP

0. Joomla. This gzips the HTML response if gzip is enabled in Joomla Global Config.
1. .htaccess - in Joomla 4 will attempt to serve, precompressed, gz asset files if found.
2. .htaccess - this can be configured to gzip the HTML response AND all other assets
3. .htaccess - configured by copy and paste from most online FAQ questions - this gzips the JS/CSS responses only
4. Web Server - can be configured a myriad of ways, to gzip some, all, or most assets depending on mime type

I vote for removing GZIpping in Joomla Global Config, all the other options are far more performant than compressing in PHP.

But that still leaves your problem... a myriad of ways a server can be configured, and config overruled by .htaccess rules...

and remember i have no console errors

and remember i have no console errors

You dont actually report what the problem you had was...

Im going to guess you had the same issue as #32892

In SOME browsers you would see:

and if you tried to go direct to one of those JS files - does your browser refuse to show the JS file? with a ERR_CONTENT_DECODING_FAILED across the middle of the page?

as i said no problems

Are you even sure your issue is a gzip issue? As the content type in that screenshot is just plain js

as soon as I comment out these lines it works correctly

	RewriteCond "%{HTTP:Accept-encoding}" "gzip"
	RewriteCond "%{REQUEST_FILENAME}\.gz" -s
	RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

But do you have *.css.gz files next to your *.css files or are they missing?

Strange as your screenshot has the JS tab selected and not the css tab !?

What's the css tab look like?

ok problem solved (i think)

I just deleted the entire css folder and rebuilt with npm

there are now no gz files at all

So I am going to guess two thing (before checking)

1. the build script overwrites the existing css - it does not delete the folder and rebuild from scratch
2. the build script no longer builds the gz files on my system

As a result the gz css files that were being loaded were just old and out of date

dont have any more time today to look into it

So I am going to guess two thing (before checking)

• the build script overwrites the existing css - it does not delete the folder and rebuild from scratch
• the build script no longer builds the gz files on my system

You're right for both, the build tools just rebuild the css/js without recreating the .gz neither refreshing the hash for the invalidation. For those 2 you need to run the commands separately (npm run gzip and npm run versioning)

The reasons that these commands are not executed directly on npm install are:

• the process will be longer
• it's harder to debug/develop with both the .gz and a fixed version (you need to constantly invalidate the static assets)
• both these commands are supposed to be part of the build process for the release

That said, I find it kinda weird that you had .gz files in a cloned repo, but as a final solution for everything npm related: delete both the media folder and the node_modules and re run npm install (templates also need extra step here till everything static is finally served from the media folder [talking about the child templates])