midwestE

Will post on Github. Marking as resolved

For reference, here are the defined shop permissions that are relevant:

delete_others_shop_orders
delete_private_shop_orders
delete_published_shop_orders
delete_shop_order
delete_shop_orders
edit_others_shop_orders
edit_private_shop_orders
edit_published_shop_orders
edit_shop_order
edit_shop_orders
publish_shop_orders
read_private_shop_orders
read_shop_order

Sorry, I shouldn’t say custom permissions, but they should be mapped to the corresponding woocommerce permission:

-Dashboard should use read_shop_order
-Shipments should use read_shop_order
-Settings should continue to use manage_woocommerce

Reviewed!

That makes sense, thank you so much for your prompt response. Trackship is notifying on shipment (tracking number) statuses changes, not post/order status changes.

Now to make sure that we don’t have any other plugins that are sending email on “Delivered” post/order status ??

Following up here. Hoping there has been some discussion to improve/fix this issue.

The main reason I am interested to participate in the development of this fix is that I know Siteground hosts many many smaller sites and there are so many customers with smaller sites that could really benefit from these changes.

In our case, we were updating our products on average 15-20 times per day and clearing the cache that often gave us a cache efficiency in the 50-60% range on good days. It routinely operates at 90%+ when only clearing related content.

For our site alone over the last 7 day period: 28GB served by cloudflare at a 92% hit rate, and at 32% higher cache efficiency, a savings of 8GB that did not have to be served from SG. 418GB less SG traffic over a year. That’s a lot of energy and capacity saved across the SG site portfolio.

https://i.snipboard.io/8ntP7W.jpg

Would be more than happy to discuss the details over chat/phone.

Any consideration here as to future development?

Understood on the interlinked pages. I do understand that the amount of urls is highly variable, but as an example, for our shop, updating a product seems to clear 50-80 related urls. Per the cloudflare purge urls endpoint, it can purge 30 urls per request so for our limited example, thats only two requests – well worth it.

Consider that when using the cloudflare wordpress plugin in tandem with sgo, the related pages are already cleared on a specific url basis, see method getPostRelatedLinks

https://github.com/cloudflare/Cloudflare-WordPress/blob/55017a3c33ac3db6183ca6fbfe7a64e892e27c1b/src/WordPress/Hooks.php#L188

If used with the cloudflare plugin, the sgo plugin could piggy back the filter ‘cloudflare_purge_by_url’ adding any related links that sgo has determined internally and that do not exist already in the list cloudflare is compiling.

There’s a filter for modifying the specific urls that cloudflare is going to purge

https://github.com/cloudflare/Cloudflare-WordPress/blob/55017a3c33ac3db6183ca6fbfe7a64e892e27c1b/src/WordPress/Hooks.php#L150

When users don’t have the cloudflare module installed – the method getPostRelatedLinks looks to be purely wordpress functions without referring to external methods and could be used directly in the sgo plugin per license https://github.com/cloudflare/Cloudflare-WordPress/blob/master/LICENSE.md

Appreciate the good work sg has put in making the sgo plugin!

Thanks for responding so quickly. Not sure why that hadn’t crossed my mind, and you’re right, that would cause a lot of problems!