I see no errors in Networkanalysis as above… only in Console as above that
sorry & thx
Dan
What happens if you try to open the URL of the failing requests directly (should be possible from the network tab?
Nevertheless this is something where whoever maintains the webserver (Apache, Nginx) configuration of your webserver, will be best able to assist you with this as this seems a lot like an issue one layer above Matomo
my admin is on it, but others seem to have the same issue and my admin so dar has no idea, too
My admin tells me:"I don’t see any stylesheet requests arriving to the server from the page I landed … "
"yep … not sure what happened it seems like the stylish part of the code is inactive … when I inspect the source code of the page I see no CSS instructions from a virst view … I am still digging though …
…
"probably yes … which proves the theory of auto updates of piwik that most of the users tended to have issues after … "
"I see no significant or related errors in the error log that can lead to such an issue … and most of everything I see no css requests in the access log … which leads me to the conclusion that either those are being sent to another server and cut of as a cross site script attack … or they to not exist at all … and when I also debugged the html code … saw simply no css instructions at all … "
found the next simialr issue:
interestingly the mobile version seems to work
at least partly, never used it before
my admin:"yes the mobile works just because it detects different user agent ( browser ) that the code is designed to react differently than the computer’s browser … anyway this is psychedelic … … "
"mate it seems that we deal with a ton of bugs in here … try to report a bug with having as tools our conversation elements … as I was very descriptive on what I saw and examined … "
SO: We from our end are not able to solve this NO CSS issue, it is on the Matomo level… help pls
In that case it might be the easiest if you could share the URL to your Matomo instance (I assume the same issue also occurs on the login page when not logged in, so should be easy to see there) either publically here or per direct message to me if you prefer.
This makes me think that it could possible be specific to your browser. Have you tried another browser on another device?
That issue indeed seems similar. Do you by chance also use Windows and IIS on your server?
Already on the login page you should see a style tag like this in the HTML:
<link rel="stylesheet" type="text/css" href="index.php?module=Proxy&action=getCss&cb=45c7492d2e9b303f2bf2e2f3ff0bed4f" />
Indeed, most issues occur after updates, but that’s mostly because often things don’t break by themselves and the updater has to work in many weird environments and things like the PHP process being killed during the update happen sometimes (e.g. with a timeout). And of course Bugs/Regressions happen, even though we try to avoid them by releasing beta/release candidate versions as we can’t test Matomo in every possible setup that exists in the world.
HI Lukas, thank you… will contact you per PM with my details…would you need login too? Server login?
No, am on Centos, no Windows or IIS … am mostly on newest FF, but also checked on Edge
this is the code
<link rel="stylesheet" type="text/css" href="index.php?module=Proxy&action=getCss&cb=69a5194929f5640a1b09977284bb7d20" />
Thank you
Dan
Okay, I can reproduce the issue when accessing your server and I think I know what goes wrong.
When accessing /index.php?module=Proxy&action=getCoreJs Firefox just gives a general “Content-Encoding-Error” without more helpful information. Chromium shows net::ERR_CONTENT_DECODING_FAILED which brought me to
Weirdly enough curl https://piwik.yourmatomo.example/index.php?module=Proxy&action=getCoreJs works perfectly fine. But this brought me to the solution:
When a client requests that the server sends the respond compressed (which all browsers do with a Accept-Encoding: gzip, deflate, br header), your server responds that it compressed the response with gzip (Content-Encoding: gzip) but the actual data it sends is not actually compressed but still plain text.
You can reproduce this with curl -v https://piwik.yourmatomo.example/index.php?module=Proxy&action=getCoreJs -H 'Accept-Encoding: gzip, deflate, br' and you will see both the Content-Encoding header is set and the response is still plain text.
Or you do a curl https://piwik.yourmatomo.example/index.php?module=Proxy&action=getCoreJs --compressed where curl fails to decompress the stream as it is not actually compressed.
* Error while processing content unencoding: incorrect header check
* Failed reading the chunked-encoded stream
As to why your webserver would do this, I can’t give a clear answer, but I would check your Apache config exactly (especially the parts related to gzip and compression). Maybe something is set up strangly there.
1 Like
HI Lukas, wow, thank you for your help … as this is a bit beyond me, I will relay this to my admin … again thank you for taking your time - on a Easter sunday!!
Will be back when I have more info…
THx a million and Happy Easter
Dan
1 Like
Thank you, that was the key clue.
The option
zlib.output_compression=1
was the problem. zlib.output_compression must be deactivated.
1 Like
Hi, hmmm…thank you…first I set to zlib=off … nothjing changed … than set server to php 7.4 didnt change zlib for 7.4) … site works now … set back to php 8 …site works now+
very strange… but somehow this did the trick
THANK YOU ALLL
Thx
Dan
Thanks everyone ! Changed to php 7.4 solved my problem too 
1 Like
To everyone who had this issue (@Dan70, @nfc, @rkids):
Thanks to @SteveG we now know the source of this issue:
My description of the issue in Matomo Website broken - #30 by Lukas was correct (only the JS/CSS requests return non-gzipped data, but claim that the data is gzipped), but the issue is in fact not caused by a broken Apache setup.
Instead, this is a bug in PHP (versions 8.0.17, 8.0.18, 8.1.4 and 8.1.5):
https://github.com/php/php-src/issues/8218
So the proper fix is to update your PHP version to one that is newer than the listed versions.
It turns out there is currently no newer version of PHP, so for now disabling output compression is the only solution.
3 Likes
Lovely you (all) find the cause.
Now, for us on shared hosting the solution is editing the PHP.ini file in our Matomo installation folder and turn off the compression.
Thanks
HI, today out of the blue the site broke again… no changes on my side
was there an update? last one was a few days ago if i remeber correctly
Hi,
Did something change on your server? (eg. Apache version, PHP version, etc.)
Can you share the screenshot of the HTTP console from browsers Firefox and Chrome?
shoot: sorry, for a project I installed Ghostery add-on and it blocked something…
so false alarm, sorry and thx!!
Dan
1 Like