websavers
Forum Replies Created
-
Forum: Plugins
In reply to: [Sezzle Woocommerce Payment] Fatal Errors with version 6.0.1Confirmed! Updated and the missing file in the includes folder is now there.
Forum: Plugins
In reply to: [Sezzle Woocommerce Payment] Fatal Errors with version 6.0.1Same issue here. Worked around it by commenting out line 39 here: woocommerce-gateway-sezzle.php
Forum: Plugins
In reply to: [Docket Cache - Object Cache Accelerator] Critical Error logging suppression?Thanks @nawawijamili 🙂
Would you be able to elaborate on this part for me?
The error probability when reading the cache that the reason disabled the object cache solved the issue.Â
Forum: Plugins
In reply to: [W3 Total Cache] Option to load CSS files directly via web serverHey Mario,
As you probably know, the default for most hosting environments with WordPress is to pass all non-existent files directly to index.php.
This presents a performance problem: what happens if you’ve got one (or more) static file(s) that’s included one very page and suddenly turns into a 404? Every single page load is going to generate PHP processing, for absolutely nothing: simply to say “this file doesn’t exist”. Now magnify this on a very busy site and you’ve got dozens, maybe hundreds of PHP processes being launched just to say a file doesn’t exist. I’ve seen this in practice and it’s not pretty.
It makes no sense to do that.
And so we – along with other WP performance optimized hosts – have either server-wide nginx or apache rules (it was easier to do it in apache for us) that explicitly check for 404s for static files and immediately serve a simple 404 page rather than allow it to be passed to PHP.
The problem, as I’ve now discovered, is that W3’s minification system requires the first load of any css or js file to be sent to PHP, which the above noted rules will not allow. This hasn’t been a problem with other optimization plugins because they all appear to generate their minified files when the *page* is generated, not when the static file is loaded.
I’ve written an exception for this into our apache rules that detects if the static file request is for a non-existent file within a ‘minify’ folder and sends it through to PHP after all. I’d rather not have to do this though. And I suspect you’ll find better support for your minification system if you’re able to link the minfication process to the page and not the static file load.
Hey Marija,
Thanks for the update! Coincidentally I noticed this in the changelog yesterday and updated it – so far so good!
Cheers,
Jordan
Forum: Plugins
In reply to: [W3 Total Cache] Option to load CSS files directly via web serverThanks @vmarko
Your notes above indicate that there should be static files in
wp-content/cache/minify/And I’m finding now why this isn’t the case for me. Those files only exist if I turn off “Rewrite URL structure” which uses requests like this:
https://schelew.com/?w3tc_minify=a5ff7.css
That definitely gets passed to PHP becuase it’s a query string.
If I then disable “Rewrite URL structure”, the static files remain and are loaded by the web server (great!) until the minified cache is cleared, at which point they are again not written to the minify folder, so they can never be loaded by the web server (not so great).
With Rewrite URL structure ON someone needs to request those static resources once to get them generated in the first place, then after that first load of the file, they’re fully static. This means only the first load would require PHP.
This method of JS/CSS file generation creates problems in a performance optimized environment because of two optimizations:
- Those using Plesk with nginx’s static file handling enabled may never hit the rewrites, and
- Those using an apache 404 handler for static files that keeps those requests lightweight (to avoid repeated 404s bogging down the server/website) will not hit those rewrites and instead will be served a 404.
I propose an option where you disconnect the static file generation process from loading the static file itself. Instead when a page’s cache file is generated, *also* generate connected static files at the same time. This way you don’t rely upon rewrites for the static files to work for *any* static file loading to function in these environments.
Meantime I’ll get working on adding the minification rewrites in nginx, as I now see that with the right config, it doesn’t *need* to hit PHP every time – just the first load after new minified files are generated.
Forum: Plugins
In reply to: [W3 Total Cache] Option to load CSS files directly via web serverYour rewrites 100% push all static files to PHP like I indicated at the start. Here’s the complete rewrite code:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /wp-content/cache/minify/
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteRule .* - [E=APPEND_EXT:_gzip]
RewriteCond %{REQUEST_FILENAME}%{ENV:APPEND_EXT} -f
RewriteRule (.*) $1%{ENV:APPEND_EXT} [L]
RewriteRule ^(.+\.(css|js))$ /index.php [L]
</IfModule>For optimal performance these should *never* rely on PHP. Think about scenarios where there’s thousands of new simultaenous visitors. nginx can handle that kind of traffic for static files all on its own, but these rewrites make it so that nearly every page load of every single static file requires PHP to serve. (Minus browser cached of course, but this doesn’t help with there’s a lot of unique traffic)
This is why I’m asking for the option for a direct link to the file on disk in the static HTML output – doing it that way will ensure better performance AND simpler compatibility with Plesk’s default nginx config.
Keep in mind that this is the same priciple as why you already have static HTML page output working that way – to avoid PHP processing. It should be the same for static files that were like that from the start – it shouldn’t be *more* PHP processing necessary than before W3 got involved.
Forum: Plugins
In reply to: [W3 Total Cache] Option to load CSS files directly via web serverHey @vmarko
I mean it’s definitely better than what I was saying above! And I see what you’re saying about the conditional serving – that could indeed improve performance in some cases.
While you’re checking on that, I’ll see if I can get some nginx equivalent rules to apply specifically for this case.
The tricky thing is we use Plesk which has its own nginx static file handling option. When it’s enabled, no additional nginx rules can override it (from what I’ve tried), so to get CSS and JS rewrites to work with Plesk+nginx we have to instruct users to exclude CSS and JS from that static file handling option, and then also add custom rewrites to handle it. It’s possible, but just not something that is particularly user friendly.
Forum: Plugins
In reply to: [W3 Total Cache] Option to load CSS files directly via web serverHey @vmarko,
What I’d like to see is the option to directly reference these files in the cached page HTML rather than use rewrites to load them.
This will make it compatible with nginx reverse proxies that pick up static files directly, prior to passing on to apache+php, as well as automatic 404 handling that’s used to reduce server load on 404s (ie: 404 on a static file extension results in simple reply, not dynamic one).
Any chance of getting that as an option in the settings?
Right now, when I enable minify using W3, all my CSS files become a 404 because of those other optimizations, but other caching/minify plugins don’t do it this way, so they don’t end up with a 404.
Forum: Plugins
In reply to: [W3 Total Cache] Option to load CSS files directly via web serverThanks @vmarko!
Thanks for the confirmation on that Marko!
Thanks @rymerakristel !
Forgot to mark resolved, doing so now.
Now fixed, thanks to @ryanhungate 🙂
This was a result of the local domain’s SSL certificate missing an intermediary certificate in the chain between the domain and the CA. I have to assume web browsers already had this particular COMODO intermediate certificate installed, since the site loaded with no SSL errors.
If someone else encounters this issue, you can verify it by checking your site URL with an SSL Certificate checker like https://www.sslshopper.com/
The solution, as with all intermediate certificate issues, is to re-download the SSL certificate’s CA certificate bundle, reinstall the bundle on the web server, and of course reload it. Immediately after doing so the remote support option worked as expected.
Hey @nawawijamili no worries! Easy enough to have it disabled until it’s fixed up 🙂