Bug when creating autoptimize_404_handler.php

Hmm, that could indeed lead to the check if the fallback file exists not testing for the right child site and could lead to an existing fallback file not being used ..

I’ll have to chew on this one though, hang on there .. ??

Maybe create one autoptimize_404_handler.php file per site (in /3 directory) and then use that file. The site id is probably already known as it is (re)written in the file.

• This reply was modified 3 years, 5 months ago by DSmidge.

that would be the easiest solution, but the problem is that a lot of security components (plugins or otherwise) don’t like PHP-code in /wp-content/cache .. :-/

I tried to analyze this a little bit – but I see that the whole wp-content/cache/autoptimize/{site_id} is periodically deleted and recreated (and autoptimize_404_handler.php also in the same process). Why is this happening?
Wouldn’t it be better to delete only old cache files and rewrite the existing files only when the content is different?

Is 20c1b5fefb08ce868c55390873fa3296 in autoptimize_snippet_20c1b5fefb08ce868c55390873fa3296.css a (css file content) hash or a random id? With a hash, you would instantly now is the content has changed and not delete/rewrite the file.

I do not mean to criticize – only to help. And as I didn’t analyze the code I may not now if what I wrote is feasible or possible.

And maybe add an option so that autoptimize_404_handler.php is not created when when user doesn’t want to use autoptimize_404_handler.php but autoptimize_fallback.css/js instead.

And regarding this deletion of {site_id} cache directories. In mean time – then the directory is deleted and before the new one is recreated, all the cache files are missing – even autoptimize_fallback.css/js. So it would be better to just overwrite he files and delete the old ones.

I see that the whole wp-content/cache/autoptimize/{site_id} is periodically deleted and recreated (and autoptimize_404_handler.php also in the same process). Why is this happening?

AO never removes it’s own cache unless it is told so by either the user or a plugin/ theme (Divi, for example), so I assume the latter is what’s happening in your case?

Wouldn’t it be better to delete only old cache files and rewrite the existing files only when the content is different?

It does not work that way, as;
1. AO does not know about “old cache files”, all cache files are treated equal
2. cache-files are reused between different page if possible
3. the filename is indeed based on a hash of the content (so if the filename is the same, then the content is too

And maybe add an option so that autoptimize_404_handler.php is not created when when user doesn’t want to use autoptimize_404_handler.php but autoptimize_fallback.css/js instead.

When the “Enable 404 fallbacks?” option is not active, the 404-handler PHP will indeed not be created, but if the option is active, both the fallback-files and the 404-handler are indeed created. Having the fallback-files but not the 404-handler will be useless (except when WordPress is handling 404’s).

I will try to disable 404 to solve my missing autoptimize_404_handler.php file problem. Although my 404 errors are handled by WP.

I do not now why, buy at my installation, the whole wp-content/autoptimize directory gets deleted periodically. I will have to live with that, as it would take too much time to find the cause.

I know that the folder gets deleted by using “cd wp-content/cache/autoptimize” and then waiting and running “ls” after a few minutes. I get an empty result. Buy when I type “ls ../autoptimize” I get the list of files/dirs. So (at least) the “autoptimize” was removed and then created again.

That you for your help, D.

OK, I think I have a fix for the child ID issue in autoptimize_404_handler.php (it works on my local multisite installation).

It would be great if you could download the beta zip from github and install that instead of 2.9.2 to test? ??

I have installed it. The file was present at one time, than it was missing. Than it appeared again with the same site id. It is the same with the cache/autoptimize dir. Both cache/autoptimize dir and autoptimize_404_handler.php have the same date and time.

File list:
14:15:14.737380087 +0200 2/
14:15:31.393455343 +0200 3/
14:15:14.737380087 +0200 ../../autoptimize_404_handler.php

After refresh:
14:15:57.661574035 +0200 2/
14:15:53.869556895 +0200 3/
14:15:57.661574035 +0200 ../../autoptimize_404_handler.php

After another refresh:
14:18:31.922271051 +0200 3/
14:18:31.922271051 +0200 ../../autoptimize_404_handler.php

And another refresh:
14:19:16.102470701 +0200 1/
14:19:01.478404621 +0200 2/
14:18:31.922271051 +0200 3/
14:18:31.922271051 +0200 ../../autoptimize_404_handler.php
The autoptimize_404_handler.php has different site id now.

Maybe it is something wrong with may installation with enabled multisite (I am using different autoptimize configurations for different sited – not one per whole WP installation).

I have 27 active plugins on the WP site. One of them is WP Super Cache.

I will try one day to enable settings on the multisite config only. Maybe that will fix the problem.

That you again for all your help and sorry for taking away your time, D.

the fact that autoptimize_404_handler.php had a hardcoded child site ID is not a problem, as the file contains logic to change the hardcoded ID to the one used in the 404’ing request;

if ( true === $multisite ) {
    preg_match( '#\/([0-9]{1,3})\/(?:js|css)\/[a-z0-9]*_fallback\.(?:js|css)$#', $fallback_target, $child_site_id );
    $ao_root_cache_dir = preg_replace( '#[0-9]*\/$#', '', $ao_cache_dir );
    $ao_cache_dir      = $ao_root_cache_dir . $child_site_id[1] . '/';
}

so even if you see the file being recreated, it should work for all child sites now? ??