mojamba

Thanks. I have updated the plugin. Unfortunately, as I wasn’t really doing anything to trigger the email the first time (and haven’t received another since), I don’t know of anyway to test that it is working. But, of course, I will be sure to let you know if somehow I do get another warning email.

Thanks. I did as you suggested and created a new topic.

I just received a similar warning from the WordPress built-in feature that detects when a plugin or theme causes a fatal error on your site:

An error of type E_ERROR was caused in line 9 of the file /[…]/wp-content/plugins/easy-pricing-tables/includes/settings.php. Error message: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /[…]/wp-content/plugins/easy-pricing-tables/includes/settings.php:9

@jonhoohmspa
On the right side of the main plugin page (below the Version, language, tags info) there is a link called ‘Advanced View.’ Click that and scroll to the bottom where you will see a ‘Previous Versions’ section. Download the 5.3.2 version to your computer and add it manually to your site. Before installing WordPress will ask you to confirm you want to replace the existing version with an earlier version. Agree and you should be set.

Updating the WP memory limit seems to have offered marginal improvement but not much. Still failed most of my multiple site plugin updates. I did one 16-site update individually (but somewhat quickly so 5+ were working simultaneously) and some of those got stuck as well.

Now, most of my sites are on two different hosts (with one stie on a third host), with more sites on one than the other. Would updating these same settings on the target server help or could there be something else (security setting maybe) that would also explain the issue? I should note that the server is relatively new as I switched hosts (both of my main hosts, actually) a few months ago. I can’t be sure that the timing was exactly coincidental with this issue or not, but probably a good guess.

Here are my settings (all show Pass status):

PHP Max Execution Time: 14400
Curl Timeout: 300
PHP Memory Limit: 256M
WP Memory Limit: 64M

For two plugin updates that spanned 6 sites it crapped out at 4 (one) and 5 (other). For a plugin update that spanned 3 sites, no problem. For another that spanned 11 sites, it stopped showing a status past 2 updates but in fact ended up updating 10 sites (when I hit close and the page refreshed it showed only 1 site needing to be updated vs. the original 11). Then for another plugin update that spanned 15 sites it stopped showing the status at 8 updates but when I closed and refreshed the page it in fact updated all 15 sites. Very inconsistent – which I guess maybe could be a function of how big the plugin being updated is?

• This reply was modified 4 years, 4 months ago by mojamba.

FWIW, my local server didn’t work without the fix (and I haven’t tried it with the fix) but yes, I am using SMTP. Anyway, as requested, I just opened a ticket.

I did a little debugging and seem to have found the problem in the new code. Your line 9265 in wp-mailinglist-plugin.php (at least, for the paid version) is:

$phpmailer = new PHPMailer\PHPMailer\PHPMailer\PHPMailer(true);

but it should be:

$phpmailer = new \PHPMailer\PHPMailer\PHPMailer(true);

With that change things seem to be working again for me (and the test email feature works again as well).

Thanks for the update. I noticed you updated the plugin (at least, the paid version I am using) but unfortunately, it is still not working now. I did try testing with the local mail option and that also did not work (the testing working icon appears but never goes away with either success or failure).

Glad to hear that and thanks for the fast response.

Sorry to take so long to report back. I can confirm that using wp_rest as an ESI nonce for LiteSpeed Cache does seem to work.

It’s been a while, but here’s my update. As the WPP developer suggested, I needed to use wp_rest for the ESI nonce.

wpp-*
wpp_*

may be necessary for implementing the widget or a shortcode but as I don’t rely on those I am not sure. For actual logging of the views, however the wp_rest nonce seems to work.

On a related note, I noticed that there is a Cache REST API setting on the first tab of the cache settings page. Unfortunately, the documentation for that is quite sparse and I cannot understand what that actually does. I thought maybe it would be the solution instead of using an ESI nonce but when I tried it I didn’t see any difference.

Thanks. I’ll give that a try.

Thanks. I heard back from him. He says “it’s the REST API -and not WPP- that validates the nonce whenever it receives a POST request.” Then he said that according to WP documentation that nonce should be wp_rest

I had known about ESI but didn’t realize there was a nonce option. That’s cool. I have asked the developer which nonce name to use. I notice in your latest version you added a wildcard option for that nonce feature so I think something like wpp* might do the job but I’ll let you know what specific name(s) he provides.

Speaking of that, assuming that both approaches (changing nonce lifetime and ESI nonce) solve the issue, which would be preferred? I would think changing the lifetime would have a somewhat negative effect on security but wouldn’t affect server performance or page speed at all. I am not sure what kind of performance/speed hit ESI adds compared to default setup. Any opinion on the matter?