colmtroy

also seeing lots of these:

Undefined index: HTTP_USER_AGENT in /snip/public_html/wp-content/plugins/urvanov-syntax-highlighter/util/class-urvanov-syntax-highlighter-util.php on line 763

that would be super!
Any eta for a release?

@robert681 this is a pretty severe css bug as it breaks any wp admin screen that uses Select 2 in WooCommerce (which is a lot of ’em!).
Have you narrowed down a specific eta for a release on this yet?
And/or is there a temp hotfix available?

Awesome Nabil ?? Looking forward to it!
Colm

hey @mrclayton that was fast!
Yes encountered it while testing it out for a potential switch to using it on a large WooCommerce store.
Re: lazy migration – good to know. So is there any downside to NOT running the migration right now in production if we can’t circumvent the CF 100 second timeout? (which you can only do on Enterprise CF plans).

@isaumya awesome thank you!

@isaumya yip I understand that for 99.99999% of use cases it makes sense to remove the worker upon deactivation. It would be useful to have a filter to override that behaviour for developers in my scenario or even for people who do other similar edge cases like temporary plugin deactivations when looking for plugin conflicts etc. who don’t want to lose their worker stats in CF etc.

And wouldn’t you know – I’ve been scratching my head on this for hours and as soon as I posted this I think I have an idea whats happening ??
I have a bash script that builds a failover instance of our site on a different server. Part of that script deactivates this plugin in the failover environment using wp cli – just to avoid the worker potentially caching/indexing our failover url. Is there any way the plugin can be deactivated without it deleting the CF worker (assuming my theory is indeed correct!).

thanks for the really useful reply @isaumya !
I’ll give Argo a shot and see if it helps.
Shame Uptrends didn’t want to help support you!

@dougaitken not the original poster, but your solution worked for me to complete the connection (thanks). Shouldn’t that step really be required so? (otherwise the default outcome is a failed connection).
Can you tell me why the connection needs the “Manage your business” permissions level?

Hey @isaumya
Re: cache settings still working in worker mode – that’s interesting! How does the worker figure out that a product page should be bypassed (assuming I’ve ticked that option in the plugin?). I couldn’t figure that out looking at the worker script.

Re: API endpoints – great ?? I would also recommend adding support for legacy WC api endpoints “wc-api/v3” as documented here
https://woocommerce.github.io/woocommerce-rest-api-docs/v3.html#schema

There’s still a ton of people who rely on those.

Re: page rules – great thanks for confirming that!
Colm

Thanks @isaumya – I’ll keep an eye out for the updated worker script ??

@eva2000 yip it’s ct_roy ?? you are everywhere ??
Your solution is a super solution if you’re not concerned about utm’s and attribution. So I’ll be using that on some of my sites (thanks again!). But for sites where they need the utm to follow through to the client browser (so GA can pick it up for example), the 302 strips the utms/query params from the url completely and therefore you lose that attribution.

I was looking at how Runcloud handle this particular problem and they have a nice solution. The obvious difference here is that they’re using fastcgi_cache as the cache store but here’s an example of what they do:
https://0bin.net/paste/L5yWSjwu#c-kV4L4yVR5qRIT3aI4mOF+EYcBlgf8Ipue1ISJkbrZ

The utm’s etc. end up being preserved, so I guess I’m wondering if there’s some way with Cache Enabler that we could serve the url from cache but preserve the relevant params rather than redirecting them.

scratch that @gabelivan – must be a weird quirk of my local environment (which uses https://chassis.io/ ) on product your code works perfectly fine ??
thanks!
Colm

Hey @gabelivan – thanks for the patch. There’s a small problem with it though.
Your $targetUriAfterSiteUrl gets a value of “-json/wc/v3/products?per_page=50” when it gets trimmed for my requests to https://mysite.local/wp-json/wc/v3/products?per_page=50

I tweaked the code to be:

		if (strpos($targetUriAfterSiteUrl, '-json/wc/') === 0) {
			return true;
		}

and that seems to solve it.