mauriciomorales

Yes, but not a man-in-the-middle CDN. It has a different DNS name (cdn.staging.site.com), so we only load assets from it.

Wonder if there’s some page generation pipeline that the CDN plugin calls “done” and never gets to Autoptimize (you can start to tell that I’m not the WordPress wiz kid of our team).

@optimizingmatters I know the Apache error log had nothing, and I didn’t even try to find another error log specifically for php.

At first I thought this may have something to do with the fact that our staging site is hosted as a WordPress docker service template with the html folder mapped to a docket volume.

But yesterday one of our developers disabled all other plugins and discovered Autoptimize started working. By slowly adding all other plugins back he found CDN Enabler to be the culprit.

That plugin combination actually works fine in production, so something about the staging CDN is causing this. But the good news for you then is that Autoptimize may be off the hook then :).

Thank you so much for the support. We love Autoptimize!

• This reply was modified 4 years, 5 months ago by mauriciomorales.

There do seem to be some files (from today even)… in /js at least:

root@a6ea1da024a2:/var/www/html/wp-content/cache/autoptimize# ls -la *
-rwxrwxrwx 1 www-data www-data  189 Sep 17 21:17 index.html

css:
total 12
drwxrwxrwx 2 www-data www-data 4096 Sep 28 20:05 .
drwxrwxrwx 4 www-data www-data 4096 Sep 29 17:07 ..
-rwxrwxrwx 1 www-data www-data  189 Sep 17 21:17 index.html

js:
total 12
drwxrwxrwx 2 www-data www-data 4096 Sep 29 17:07 .
drwxrwxrwx 4 www-data www-data 4096 Sep 29 17:07 ..
-rwxrwxrwx 1 www-data www-data    0 Sep 29 17:07 autoptimize_d41d8cd98f00b204e9800998ecf8427e.js
-rwxrwxrwx 1 www-data www-data    0 Sep 29 17:07 autoptimize_fallback.js
-rwxrwxrwx 1 www-data www-data  189 Sep 17 21:17 index.html

Also, the best I can tell, the www-data user has access to those folders.

root@a6ea1da024a2:/var/www/html/wp-content/cache/autoptimize# ps auwx | grep apache
root         1  0.0  0.6 238556 24556 ?        Ss   Sep26   0:13 apache2 -DFOREGROUND
www-data  3536  0.0  2.3 322980 93532 ?        S    17:08   0:04 apache2 -DFOREGROUND
www-data  3583  0.0  2.3 322640 92788 ?        S    17:38   0:02 apache2 -DFOREGROUND
www-data  3602  0.0  2.3 322352 92632 ?        S    17:53   0:01 apache2 -DFOREGROUND
www-data  3629  0.0  2.2 322064 88108 ?        S    18:23   0:00 apache2 -DFOREGROUND
www-data  3631  0.0  2.3 322612 92476 ?        S    18:23   0:01 apache2 -DFOREGROUND
www-data  3643  0.0  2.3 322584 93484 ?        S    18:38   0:00 apache2 -DFOREGROUND
www-data  3657  0.0  2.3 322480 92108 ?        S    18:53   0:00 apache2 -DFOREGROUND
www-data  3670  0.0  2.0 317796 82832 ?        S    19:08   0:00 apache2 -DFOREGROUND
www-data  3671  0.0  1.9 243784 76316 ?        S    19:08   0:00 apache2 -DFOREGROUND
www-data  3672  0.0  2.0 317788 83008 ?        S    19:08   0:00 apache2 -DFOREGROUND
root      3684  0.0  0.0   3080   896 pts/0    S+   19:13   0:00 grep apache

In fact, this is what the Cache Info section of AO reads:

Cache Info
Cache folder /var/www/html/wp-content/cache/autoptimize/
Can we write? Yes
Cached styles and scripts 2 files, totalling 0.00 B (calculated at 19:17 UTC)

Done, thanks @optimizingmatters
No Cache nor optimized CCSS after restoring staging site

Thanks @optimizingmatters, well I didn’t state it but our production version (the one we took the backup from, it does have a lot of AUTO rules (just like @bcupham stated ?? ).

Not really, our staging (and production) only cache assets in a separate CDN url (which we also configure using Autoptimize)… these requests should be getting to WP for sure… BUT, and we noticed this this morning, the Autoptimize cache is mostly empty (2 files, 0.0KB). I wonder if for some reason Autoptimize simply isn’t being triggered by the WP request handling somehow…

We’ve tried deactivating/reactivating AO and also tried removing and readding the CCSS API key… no luck.

We thought it must be that with the restoring of a production backup into a different site name and port (staging.<originalsite>.com:30000) maybe whatever state it had just wasn’t compatible… but reinstalling the plugin didn’t seem to fix that so here I am asking for help.

Hi Frank,

We have this exact same issue with a staging backup/restore of our production website. We’ve been navigating thru the site with anonymous sessions and we can’t get anything other than the is_front_page AUTO rule.

We also tried enabling the debug mode, but we only get a message about the API Key validation and some queue locking logs… but no new auto rules created. Our production site does in fact have multiple AUTO rules for all of those pages, so wonder what’s keeping the _staging_ restored instance from creating them.

2020-09-28T23:15:07+00:00 - [DD] criticalcss.com: API key is valid, updating key status
2020-09-28T23:17:23+00:00 - [DD] criticalcss.com: API key is valid, updating key status
2020-09-28T23:23:51+00:00 - [DD] Queue control started
2020-09-28T23:23:51+00:00 - [DD] Queue control locked
2020-09-28T23:23:51+00:00 - [DD] Queue control unlocked
2020-09-28T23:23:51+00:00 - [DD] Queue control finished

• This reply was modified 4 years, 6 months ago by mauriciomorales.
• This reply was modified 4 years, 6 months ago by mauriciomorales.