when doing the import:
1. is the page cache cleared/ disabled?
2. is there a very high load on the server (cpu/ mem)?
3. does the full CSS 404 (not found) or is it empty or wrong or …?
4. does ticking the “404 fallback” option change anything?
frank
1. I have tried clearing the cache when importing – no difference
2. cpu max 20% mem max 32% vs 7% & 23% without it running
3. Nearly all content appears (except footer) but none of the styling is there – it is just oddly formatted text
4. this changes nothing
I can run it for you at some point if this helps?
Thanks
Jason
for starters maybe run the importer while doing a couple of tests on webpagetest.org to try to capture what is happening and share the resulting webpagestest URL’s here? that way you don’t depend on my presence.
also interesting question: when/ how does this get fixed?
Very weird; https://www.truckpages.co.uk/wp-content/cache/autoptimize/css/autoptimize_c5f7bbda16eb1ec6e198fbf55567d4a5.css loads OK in the first test and in the 2nd repeat test, but the exact same (static) file does not load in the other tests. Likewise the autoptimized JS-file sometimes loads but sometimes does not.
Now these are static files, AO writes them to the cache directory and then it’s up to the webserver to serve them tens or hundreds or thousands of times without AO having to intervene. Only when an page is requested that is not in the page cache (or not fresh), AO kicks in again and will either create new files (if things changed) or simply re-use cached files.
Based on what I’m seeing in the webpagetest-results either:
* there is a problem with the webserver not being able to “see” the files
* or something (the import process) is removing the autoptimize cache
Can you contact the developers of the import process to hear if they do anything insdie wp-content/cache either directly on filesystem level or using PHP-code hooking into Autoptimize?
Do you think a CDN would help here?
It might; a file that is removed from the server is (generally) not removed from the CDN + the CDN is not impacted by anything running on the server (the import). So yeah, could be worth a try.
I would still check with the developers of the import mechanism though 🙂
Hi
CDN did not help here – will get on to sofly who make the WP AllImport plugin
Thanks
Hi this is what they said, but I guess it doesn’t help?
The only method to clearing cache that we have in WP All Import would be opt-in (using our “wp_all_import_reset_cache_before_import” filter), and even enabling that doesn’t result in the cache files being cleared.
The only thing I can think of is that while WP All Import itself isn’t clearing this cache, there may be something else hooking into the import process. The only way to know, though, would be to do a conflict test: https://www.wpallimport.com/documentation/troubleshooting/plugin-theme-conflicts/
I can confirm that the opt in filter has not been selected as above.
I also have WP Super Cache installed.
Thanks
Will
could indeed be a butterfly effect, wpallimport triggering plugin X, which triggers WP Super Cache, which triggers AO. if you have filesystem access, try monitoring wp-content/cache for changes when wpallimport is running maybe?
I have looked into this – it appears the AOCache folder is being deleted when AllImport runs. It also looks like the contents of the supercache folder are deleted, but the folder itself was not.
This looks like the code they use but it is above my knowledge level (ctrl f cache on this page)
https://pluginarchive.com/wordpress/wp-all-import/v/3-4-6
wp_cache_flush(); only flushes WordPress core’s object cache, so that code is not the culprit no .. :-/
not sure what to do here then – I suppose I have to troubleshoot all plugins?
what might be happening is that WP Super Cache clears it’s own cache when all-in-one runs for some reason and that would cause AO’s cache to vanish as well. Test with WPSC off to confirm?
Looks like that’s the cause…
Any thoughts on how to prevent this happening, (short of turning off the WP Super Cache?
Thanks
