should work perfectly on 7.4 really … do you have a staging-site where we could test?
Thread Starter
Superb
(@themeeverest)
@optimizingmatters that was fast, thanks for getting back to me so quickly.
I found your beta version link and installed it, it seems like that sorted out the issue – weird!
Marking it as done, thanks for creating an outstanding product
Well, if you were using “inline & defer CSS” then there were issues in 2.7.5 which are fixed in beta (which I’ll release as 2.7.6 today).
Thread Starter
Superb
(@themeeverest)
Apparently “Aggregate inline CSS” was the trigger, it mixed the order of some stylesheets which bugged out.
That together with removing the CDN base url did the trick, we are using a CDN enabler instead now and that works.
Not sure I completely understand why the errors suddenly started showing after upgrading PHP to 7.4 though :/
had a quick look and AO now seems not to be active?
Thread Starter
Superb
(@themeeverest)
Hey @optimizingmatters yes it is active, but you’re right it seems like it’s not minifying anything currently, that’s very odd.
In the interface it says: Cached styles and scripts 2 files, totalling 0.00 B (calculated at 14:30 UTC)
I have activated following:
– Optimize JavaScript Code?
– Aggregate JS-files?
– Optimize CSS Code?
– Aggregate CSS-files?
– Optimize HTML Code?
– Save aggregated script/css as static files?
– Minify excluded CSS and JS files?
– Enable 404 fallbacks?
– Also optimize for logged in editors/ administrators?
It seems like minify HTML works fine but the rest doesn’t 🙁
ok, also configure AO with the CDN base domain, if not AO can’t know it can aggregate the JS/ CSS on that other URL.
Thread Starter
Superb
(@themeeverest)
If I type in https://b9w4c2c6.stackpathcdn.com/ as the root then all CSS stops working.
It creates a minified file, but it takes a while for stackpath to catch up I think, so for a long while it just leads to a 404 error that looks something like this:
https://b9w4c2c6.stackpathcdn.com/wp-content/cache/autoptimize/css/autoptimize_6833187de64c366ecc1368911501549c.css
I assume thats the issue, at least it just gives a 404 error
Have you experienced that before?
-
This reply was modified 5 years, 10 months ago by
Superb.
weird, a pull cdn normally just pulls the file in and all is fine. maybe check stackpath settings or ask their support?
in the mean time; try with the “404 fallback”-option ticked maybe?
Thread Starter
Superb
(@themeeverest)
I just spoke with Stackpath support, they say that it’s a common error that their service don’t work together with Autoptimize.
They recommend that I use WP Rocket or W3 cache instead. :-/
Anyways I thank you for your awesome service, I really appreciate it.
Have a great day
that doesn’t make sense … they’re a pull CDN, right? so a file that is created on the origin server and that is requested from the CDN will cause the CDN to pull the file from the origin server?
I see no reason why it would not work and I have seen a great number of sites with AO on stackpath CDN actually ..
If the CDN is disabled, does AO work?
Thread Starter
Superb
(@themeeverest)
Well I’ll be honest and say that I have no experience regarding this, so I’m not the right person discuss it with sadly.
I can confirm that AO works fine when the CDN is disabled.
Thread Starter
Superb
(@themeeverest)
Yes that’s correct, what’s weird is that Autoptimize creates multiple files, some of them are working fine in Stackpath but the main CSS one gives a 404 – It makes no sense to me
And if you activate that “404 fallback” option?
