pjv

add_action('admin_init', function(){
remove_menu_page( 'admin.php?page=wc-admin&task=payments' );
remove_menu_page( 'admin.php?page=wc-settings&tab=checkout' );
});

LOL: this will not be resolved so I’m going to mark it as resolved.

Nice doublespeak.

I just ran into this too. In my case, it was an out of memory (OOM) error resulting from attempting to activate on a site with tens of thousands of users. The activation function of the plugin tries to allocate an array of full user objects for every user on the site. That choked my server.

I made some changes to the activation function and sent you a PR.

Servers go down all the time. You can do the best you can, but there are always going to be server issues. The plugin should handle server request timeouts more gracefully than just failing completely. I don’t know what the right timeout is, 10 seconds? 30 seconds? 60 sixty seconds… whatever it is, the plugin should not wait forever for server requests to complete successfully and if they don’t, it should then do the default (non-optimized) behavior as though the plugin were not active so that it doesn’t mess up the user experience and cause users to believe they have not uploaded an image at all.

Hi @priyankajagtap,

You are right! I apologize right back to you for the bad bug report. It must be something else on my site that is causing the transients to be deleted. There had to be some interaction with this plugin as upgrading and downgrading it repeatably produced and fixed the problem at first, but now I am seeing the same issue while running v. 4.4.2, so again, it must be something else causing it.

Sorry!

Hi @ priyankajagtap,

Yup it “works fine” but the plugin is wiping out the WordPress transients on every request. That won’t make it not “work fine” but it will slow things down a lot and put a lot of unnecessary load on servers because it is clearing out everything that is cached in transients on every request.

I know this because I am also a plugin author and one of my plugins has an admin notification that can be dismissed by the user “forever”. When it is dismissed, I save state in the WP transients and my plugin knows not to keep displaying the notification after it has been dismissed.

When I updated to 4.4.3 of WooCommerce Print Invoice & Delivery Note, the notification appears on every request even after being dismissed. Downgrading to version 4.4.2 of WooCommerce Print Invoice & Delivery Note fixed this issue.

Therefore, v. 4.4.3 is doing something that is clearing the WP transients on each request.

I didn’t comment about 6.2.1. I commented about 6.3.2.

And in any case, you guys should really keep the full changelog going back to the most recent [semver] minor version viewable from within the plugin’s “view details” in the WP admin like you used to. Not doing so is making your users work too hard to update.

Hi @mihche,

I wasn’t as much asking for help as suggesting a new feature for a future update of WP Bruiser.

Hi @hgezim,

Yup, I upgraded to 4.9 and my site with a Timber-enabled theme is working fine with it.

Thanks.

Same. It’s not a WSOD and Jetpack is actually connected and working. It’s a problem going to either the settings page or the Jetpack dashboard which appear completely blank.

Here’s a related nginx error log entry (sanitized):

2017/04/06 10:55:39 [error] 4142#4142: *5960955 FastCGI sent in stderr: "PHP message: PHP Warning: Cannot modify header information - headers already sent by (output started at /var/www/example.com/htdocs/wp-includes/formatting.php:5078) in /var/www/example.com/htdocs/wp-includes/rest-api.php on line 513" while reading upstream, client: <IP ADDRES>, server: www.example.com, request: "GET /wp-admin/admin.php?page=jetpack HTTP/1.1", upstream: "fastcgi://127.0.0.1:9070", host: "www.example.com", referrer: "https://www.example.com/wp-admin/plugins.php"

We use this plugin: https://www.ads-software.com/plugins/multiple-packages-for-woocommerce/

It can be used to break orders up into multiple “packages” that can have different shipping options for each package. You don’t of course have to ship them separately, but it does let the cart calculate the total correctly when you have some products that are eligible for free shipping and some that are not.

There are many gotchas in trying to purge a cache on updates. One in particular that I found a bit hairy when contributing to nginx helper is that if WP is set up for paginated comments (Settings -> Discussion -> Break comments into pages…), then you need to either do some form of wildcard purge with the URL of the canonical post/page as a base, or you need to calculate how many pages of comments there are for a given post/page that changes and then loop through each of those comment pages to purge them individually by their URL which look like posturl/comment-page-1, posturl/comment-page-2, etc.

First, it’s not my blog post – it’s Cloudflare’s and I don’t work for them.

Second, the new version of the CF plugin is not actually doing anything to rewrite URL’s anymore. That’s why I pointed to that blog post – the URL re-writing is happening at the actual Cloudflare layer of things (not within your WordPress site anymore). And to over-simplify things that are spelled out in more detail in that blog post, you could say that Cloudflare is only re-writing specific URLs that are on a giant list somewhere (that’s what they “KNOW”). And some of your URLs are on the list and some aren’t. The plugin doesn’t do anything to let them KNOW what to re-write and what not to re-write.

I’m not personally convinced that is the best way to do it for any given site, but I think for Cloudflare in general, trying to make something workable for every site in the interwebs, it’s probably the best they can do.

@abigailm, it’s because Cloudflare doesn’t KNOW that those images can be loaded over https. It doesn’t matter whether they CAN be loaded over https, it matters whether Cloudflare KNOWS it.

The way they KNOW (or don’t) is detailed in this blog post: https://blog.cloudflare.com/how-we-brought-https-everywhere-to-the-cloud-part-1/

Thanks for the reply and for providing all the context. It yielded an understanding of why you made the architectural decisions, though I still think they were/are poor decisions.

I meandered through the repos you linked and the amount of abstraction and the heaviness of the frameworks you are leveraging to attempt to use a single codebase for multiple platforms still seems bonkers to me.

Here’s why from two different points of view:

1. Developer’s POV

I think at very best the end result on each platform you are supporting will be a massively over-bloated plugin that maybe kinda, sorta works but will likely be very brittle specifically because you are trying to support multiple platforms with one giant codebase and when you make fixes (for example) for WordPress, you are going to end up creating new issues for Magento.

I think you will always be chasing your tail and fighting with the scope of the abstractions and complexity of the dependency-tree in your codebase just to make really simple fixes that would take a couple lines of code and 10 seconds in a native plugin.

Again, I understand why you are trying to consolidate all your integrations into one codebase and I hope it ends up working out for you, but I think it’s unlikely. When I think of how streamlined and simple a WP Cloudflare plugin could be, leveraging the new v.4 CF API, it makes me feel tempted to write it myself ;^).

2. End User’s POV

So I am someone who writes a blog on WordPress and a techy friend of mine told me I should use Cloudflare to speed things up and protect me from DOS’s (whatever that means). So I signed up for Cloudflare and figured out how to set up all that DNS stuff and then I installed the Cloudflare plugin in my WordPress. Now my admin area takes forever to load, at least the first time. Maybe I’m not using it right, but I thought Cloudflare was supposed to speed things up. And the settings page for the Cloudflare plugin also kind of acts weird – at least it doesn’t look and act like all the other plugins I use.

I’m not really sure how to stress how out of proportion it seems to me to force a 1.3 Mb .js filled with code abstractions supporting WP, Magento, cPanel, Plesk, Joomla, Drupal, whateverthehellelse, to download and be parsed by the browser for one obscure plugin that doesn’t really do much more than let me turn on and off CF features (which I could otherwise manage directly on the CF website) from within my WP admin. For crying out load, all it needs are a few buttons that shoot off a php-curl request! It’s a single Class file with a few hundred (at most) lines of code.

And now speaking as a non-metaphorical admin who runs a bunch of WP sites, you are at 3.0.6 and I have tested each release from 3.0 on and I am still running v. 1.3.25 on all my production sites.

You are listing HTTP2 push as a feature but as far as I can read in your changelogs, you disabled it in 3.0.2 and have not yet re-enabled it (though I think there is a workable, though not ideal, fix for the bloated headers problem that you can find here: https://github.com/daveross/http2-server-push/commit/ae95e8149ae131d07a71fa35ec2d0f7e88d7d03f).

You are no longer making use of spam submissions and I can’t tell whether you are still doing anything about re-writing IP addresses for server logs as that has been dropped from the plugin description.

If you subtract out stuff that you could otherwise do on the CF website, can you tell me what the CF WP plugin is actually providing at this point?