Will Stocks

I can confirm – the issues still exist with 1.9.2 (I’ve moved hosting and have access to lower level logs).

@amazonlinkbuilder – can you provide some sort of ETA for a fix please?

I setup a fresh install of WordPress (and dupe of my site) on a domain that only I would hit/know. I’m getting rate limiting errors. Why am I hitting the rate limit with no traffic/no views on pages with Amazon products?!

AALB also retains a steady level of CPU usage, which is strange… considering again no pages with products are being viewed/hit to justify needing the level of processing power it’s currently using (or outbound requests it’s making).

I’ve reverted back to 1.8.0 and it has “somewhat” normalised, but is still consuming a steady and consistent 2% CPU minimum, and I’m still getting API throttling errors (again – no pageviews).

If the API calls are to update product info, shouldn’t that be being doing via a _single_ cron job and updating all relevant products in a single call rather than multiple simultaneous calls out or high frequency cron jobs?

The /wp-admin/admin-ajax.php?action=aalb_update_table&nonce=ea32cd6f3d confuses me because I’m not going anywhere near posts or the AALB plugin to justify this POST being made?

It’s all very confusing! Lol!

@amazonlinkbuilder – is there any info I can provide to assist with rectifying? My PHP skills are fairly limited but I will do what I can!!!!

I have recently switched hosting, directly with DigitalOcean now, so I have full control over my nginx.conf file.

I will retry upgrading now. My nginx conf at the moment has the following in it relating to caching:
`
set $skip_cache 0;
set $skip_reason “”;
proxy_cache_key $scheme$host$request_uri;

if ($http_cookie ~* “comment_author_|wordpress_(?!test_cookie)|wp-postpass_” ) {
set $skip_cache 1;
set $skip_reason Cookie;
}

if ($request_uri ~* “/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|sitemap(_index)?.xml”) {
set $skip_cache 1;
set $skip_reason URI;
}
add_header Cache-BYPASS-Reason $skip_reason;

location / {
try_files $uri $uri/ /index.php?$args;
proxy_buffering on;
proxy_cache edge-cache;
proxy_cache_revalidate on;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_cache_bypass $skip_cache;
proxy_no_cache $skip_cache;
proxy_cache_valid 200 301 302 500m;
proxy_cache_valid 404 1m;
add_header X-Cache-Status $upstream_cache_status;
#add_header X-Handled-By $proxy_host;
add_header Cache-BYPASS-Reason $skip_reason;
}

location ~ \.php$ {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://127.0.0.1:8080$request_uri;
add_header Front-End-Https on;
proxy_redirect off;
proxy_buffering on;
proxy_cache edge-cache;
proxy_cache_revalidate on;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;
proxy_cache_bypass $skip_cache;
proxy_no_cache $skip_cache;
proxy_cache_valid 200 301 302 500m;
proxy_cache_valid 404 1m;
add_header X-Cache-Status $upstream_cache_status;
#add_header X-Handled-By $proxy_host;
add_header Cache-BYPASS-Reason $skip_reason;
}
`

I did originally have Apache set to use mod_disk_cache as well, but that broke my entire site completely (every single URL would point to a single file – whichever was visited first and cached) which I’m still yet to work out why/what’s happening there.

Hi @vmarko – I will have to speak to my host, as the nginx conf isn’t something I have access to (I use Cloudways for hosting).

I will ask them to confirm the current ruleset that is applied, to try and clarify this for you.

Please also see: https://github.com/futtta/autoptimize/issues/229 as it is not only me seeing this issue, and with 0.9.7 I don’t have this issue at all and AO hasn’t updated in 2 months/doesn’t really touch nginx as far as I’m aware – so it’s clearly some change/incompatibility between the two with 0.9.7.1/0.9.7.2. I tried looking at the diff (https://plugins.trac.wordpress.org/changeset?sfp_email=&sfph_mail=&reponame=&new=2018481%40w3-total-cache&old=1864400%40w3-total-cache&sfp_email=&sfph_mail=) but the changes are fairly extensive and I got lost halfway through!

Right…

So I can’t replicate it in staging for some reason (it’s an EXACT copy of my site, but I wonder whether it’s because it’s fresh and has had no data updates since), but:

GET https://willstocks.co.uk/wp-content/cache/autoptimize/js/autoptimize_edd71b4828d50f10e8224220bf9763fc.js net::ERR_ABORTED 404
/wp-content/cache/autoptimize/css/autoptimize_b198bdb91c81033d22d83caf5514df6d.css:1 GET https://willstocks.co.uk/wp-content/cache/autoptimize/css/autoptimize_b198bdb91c81033d22d83caf5514df6d.css net::ERR_ABORTED 404

I see these errors (current AO file is: autoptimize_5fe0923896125bd1965e86d0cfe3cf96.css and autoptimize_a64f6e008422fbabbb7a3ec5536062bc.js)

I opened my site (logged in to wp-admin) and everything loaded fine. I cleared all caches (just to make sure – AO AND W3TC) and reloaded – everything was fine. So I continued to open an incognito tab and boom, the error is there. I also noticed one of my recent posts was missing, so I emptied Chrome cache and reloaded – same again. I checked the W3TC comment at the bottom of <body> and it was showing the last updated date as 07-01-19.

I have now reverted to 0.9.7 and things work perfectly fine… I truly don’t understand as the sites are like for like (literally copied all site files and DB!!!!)

I’m happy to arrange access for you (I have setup an account in the staging environment) if someone wants to get in touch with me via email? (will@willstocks.co.uk)

@amazonlinkbuilder – are you able to confirm whether upgrading to 1.9.2 will resolve the above issues. The massive amount of logging bogged down my entire server resource, to the point I had to restart Apache, PHP and nginx!

Everything seems OK to me at the moment, on 1.8.0 and I’m hesitant to upgrade 🙁