Forum Replies Created

Viewing 15 replies - 196 through 210 (of 360 total)
  • In _theory_ if you’re running v1.9.0+:

    1.9.0 – JANUARY 29, 2019
    Added Product Advertising API (PA-API) response caching feature. This feature will prevent PA-API throttle by caching PA-API response and updating the cache asynchronously.

    So looks like Amazon have given us some way around this! 🙂

    See: https://wordpress.org/plugins/amazon-associates-link-builder/#developers

    Thread Starter Will Stocks

    (@willstockstech)

    Nice one – thanks @vmarko. I thought I had the query string forwarding enabled, however I will triple check this!

    Plugin Contributor Will Stocks

    (@willstockstech)

    Ahhh, that’s great! Version 2 is sounding good! Hashes as the file name would definitely alleviate having to invalidate URLs (long run, also a money saver as AWS charges for > 1000 invalidations)

    Plugin Contributor Will Stocks

    (@willstockstech)

    Hey @jomisica
    Yes, it seems w3tc_cdn_purge_files might be a good catch all for any of their CDN integrations, not just S3/CloudFront. Some investigation might be necessary – I’m happy to spin up a staging version of my site for testing if that would help?

    Thread Starter Will Stocks

    (@willstockstech)

    Thanks @macmanx – very strange!!

    Any idea why (even though it is ticked) the post never actually “Publicized” to Facebook? At all…

    It went to Twitter and LinkedIn, but it did not go to Facebook. I’ve checked the connection and it’s still valid/working in theory, but Publicize didn’t actually “Publicize” to Facebook for some reason?

    Thread Starter Will Stocks

    (@willstockstech)

    Hi @vmarko – Apologies, it was a red herring! Not actually the issue I was seeing 🙂

    My cron job is a very simple one, it’s just wget‘ing wp-cron.php?doing_wp_cron every 5 mins, but it didn’t seem to be executing. Was not a caching issue

    Plugin Contributor Will Stocks

    (@willstockstech)

    Nice one – thanks @jomisica. Let me know if you need any translations as well and I can assist with those.

    Thread Starter Will Stocks

    (@willstockstech)

    Thanks @vmarko – can you confirm that this would only invalidate the file/URL in Cloudfront and not PURGE the file?
    I only want to call the invalidate path, when an image is updated (it would have the exact same URL).
    An example of what I’m trying to do:
    https://cdn.willstocks.com/wp-content/uploads/optimum-gravatar-cache/avatar/2.jpg?d=thb95k
    This image is a user/commenter/author avatar. A daily check occurs to see whether a Gravatar has updated (using @jomisica’s OGC plugin) and I use W3TC to push those images up to my CDN (AWS S3 + Cloudfront, where I store all of my other image assets). If an image is updated, it gets a new query string on the end, to denote the datetime of the change. However, I saw yesterday that regardless of this query string, Cloudfront was still caching 2.jpg as the old image until I invalidated that specific URL.

    Thread Starter Will Stocks

    (@willstockstech)

    I have also had to put together a fairly nasty function to strip out all of the scripts and styles that were being applied to the frontend of my site:

    function remove_aalb_frontend_bloat() {
    	if (!is_admin) {		
    		//Scripts
    		wp_dequeue_script ('handlebars_js');
    		wp_dequeue_script ('jquery-ui-tabs');
    		wp_dequeue_script ('thickbox');
    		wp_dequeue_script ('aalb_admin_js');
    		wp_dequeue_script ('aalb_credentials_js');
    		wp_dequeue_script ('aalb_sha2_js');
    		wp_dequeue_script ('codemirror_js');
    		wp_dequeue_script ('codemirror_mode_xml_js');
    		wp_dequeue_script ('codemirror_mode_css_js');
    		wp_dequeue_script ('codemirror_js');
    		//Styles
    		wp_dequeue_style ('jquery_ui_css');
    		wp_dequeue_style ('aalb_admin_css');
    		wp_dequeue_style ('font_awesome_css');
    		wp_dequeue_style ('thickbox');
    		wp_dequeue_style ('aalb_credentials_css');
    		wp_dequeue_style ('codemirror_css');
    		wp_dequeue_style ('aalb_basics_css');
    	}
    }

    I have now reverted to v1.8.0 and all error logging has stopped and frontend bloat has disappeared.

    Thread Starter Will Stocks

    (@willstockstech)

    I get hundreds (if not THOUSANDS) of the following errors (I’m talking 10MB+ of plaintext errors per day – it’s bogging down my logs!):

    PHP access logs: [04/Feb/2019:06:38:52 +0000] "POST /wp-admin/admin-ajax.php?action=aalb_update_table&nonce=ea32cd6f3d" 200 0 - 11882 12668 22.770 29360128 1.41% 0.44% "/wp-admin/admin-ajax.php?action=aalb_update_table&nonce=ea32cd6f3d"

    PHP slow logs: [04-Feb-2019 06:25:20] [pool clusternamehere] pid 11895 script_filename = /my/super/secret/server/public_html/wp-admin/admin-ajax.php [0x00007fc3dd41c5d0] usleep() /my/super/secret/server/public_html/wp-content/plugins/amazon-associates-link-builder/cron/update_table_cron_task.php:105 [0x00007fc3dd41c530] exponential_backoff() /my/super/secret/server/public_html/wp-content/plugins/amazon-associates-link-builder/cron/update_table_cron_task.php:82 [0x00007fc3dd41c450] task() /my/super/secret/server/public_html/wp-content/plugins/amazon-associates-link-builder/vendor/a5hleyrich/wp-background-processing/classes/wp-background-process.php:303 [0x00007fc3dd41c3a0] handle() /my/super/secret/server/public_html/wp-content/plugins/amazon-associates-link-builder/vendor/a5hleyrich/wp-background-processing/classes/wp-background-process.php:177 [0x00007fc3dd41c330] maybe_handle() /my/super/secret/server/public_html/wp-includes/class-wp-hook.php:286 [0x00007fc3dd41c250] apply_filters() /my/super/secret/server/public_html/wp-includes/class-wp-hook.php:310 [0x00007fc3dd41c1e0] do_action() /my/super/secret/server/public_html/wp-includes/plugin.php:453 [0x00007fc3dd41c0e0] do_action() /my/super/secret/server/public_html/wp-admin/admin-ajax.php:114

    Apache access logs: [04/Feb/2019:06:26:24 +0000] "POST /wp-admin/admin-ajax.php?action=aalb_update_table&nonce=ea32cd6f3d HTTP/1.0" 200 439 "https://willstocks.co.uk/wp-admin/admin-ajax.php?action=aalb_update_table&nonce=ea32cd6f3d" "WordPress/5.0.3; https://willstocks.co.uk"

    Apache error logs: [Mon Feb 04 06:26:02.930398 2019] [proxy_fcgi:error] [pid 12251] [client 127.0.0.1:53407] AH01071: Got error 'PHP message: <h4>You are submitting requests too quickly. Please retry your requests at a slower rate. For more information, see <a href=http://docs.aws.amazon.com/AWSECommerceService/latest/DG/TroubleshootingApplications.html#efficiency-guidelines target=_blank>Efficiency Guidelines</a>.</h4>\nPHP message: <h4>You are submitting requests too quickly. Please retry your requests at a slower rate. For more information, see <a href=http://docs.aws.amazon.com/AWSECommerceService/latest/DG/TroubleshootingApplications.html#efficiency-guidelines target=_blank>Efficiency Guidelines</a>.</h4>\n

    nginx status logs: [04/Feb/2019:06:35:57 +0000] POST /wp-admin/admin-ajax.php?action=aalb_update_table&nonce=ea32cd6f3d HTTP/1.1 status_code:200

    Note: all IP’s and server names removed.

    • This reply was modified 7 years, 4 months ago by Will Stocks. Reason: Formatting
    • This reply was modified 7 years, 4 months ago by Will Stocks. Reason: Code formatting
    • This reply was modified 7 years, 4 months ago by Will Stocks.
    Thread Starter Will Stocks

    (@willstockstech)

    Or should that be: `W3TC\CdnEngine_S3_Cf->invalidate(array(‘\wp-content\myimages\image1.jpg’));

    Thread Starter Will Stocks

    (@willstockstech)

    Thread Starter Will Stocks

    (@willstockstech)

    thanks @macmanx – that makes sense 🙂

    Clearly I need to brush up on accessibility 😉

    Plugin Contributor Will Stocks

    (@willstockstech)

    @jomisica – I will let you know how those little PHP bits work for me 🙂

    My CDN is Cloudfront (AWS S3 with a Cloudfront distribution), so I think what I might need to do as part of the W3TC page cache purge is also invalidate the files in Cloudfront – I just have to work out how:
    https://plugins.svn.wordpress.org/w3-total-cache/trunk/CdnEngine_S3_Cf.php (line 162 – function invalidate( $files, &$results )) – it looks like instead I might need to grab the “changed file path” and pass that instead of the postid (should be fairly simple as I think I’ve seen a function that you use already?

    Thanks for the clarification @roselldk 🙂

    Unfortunately for me, it doesn’t seem to be working 🙁 Even when I request the jpg/png the first time, a webp variant never seems to be generated or saved on later requests. I’ve checked both my local server and my CDN (https://github.com/rosell-dk/webp-express/issues/161) but I don’t find a webp version of the image anywhere.

    I will continue to fiddle/play to see what I can come up with in the meantime

Viewing 15 replies - 196 through 210 (of 360 total)