Michael

David, thanks for the update!

The problem is that with each update, there is a concern that crucial features may become dysfunctional. This can make maintenance of the plugin quite costly since one must always test it thoroughly on a separate system before deploying it to a production environment. It’s unfortunate because the plugin is actually quite impressive.

It is is really pitty because the plugin itself is great.

You add bugs to your free version to force users to buy the commercial edition? That’s brilliant! Seriously, you badly hurt your brand by abusing the WordPress community for debugging.

And blaming the WordPress team for your own bugs is the lamest excuse of a plugin developer I have ever heard!

There is only one reason why the Tribulant Newsletters plugin is full of bugs. Your developers simply don’t care. I only report a fraction of the bugs here. Obviously, your developers never looked at the WordPress error log, which is full of Newsletters error messages.

This bug is a good example. Someone made a major change and obviously didn’t test at all whether the corresponding feature still works.

I recommend your management emphasizes the following statement to all Tribulant developers:

PROFESSIONAL SOFTWARE DEVELOPMENT IS 1% CODING AND 99% TESTING.

Bounce management works now in 4.8.8. But it only works properly if admin notification is disabled.

If admin notification is enabled, admins are not notified if an email bounced. Other admin notifications like for new subscriptions work.

However, the main problem is that if you enable admin notification bounces are not counted correctly. The plugin somehow gets in an endless loop counting multiple bounces even if there is only one bounce notification until the bounce limit is reached and the subscriber is deleted.

The bugs are in newsletters-lite/wp-mailinglist-plugin.php. This is from our PHP log:

PHP Fatal error: Uncaught Error: Attempt to assign property “email” on null in wp-content/plugins/newsletters-lite/wp-mailinglist-plugin.php:9580

PHP Fatal error:? Uncaught Error: Attempt to assign property “mailinglists” on string in wp-content/plugins/newsletters-lite/wp-mailinglist-plugin.php:8742

Another bug is Number.php. I don’t know if it is related to bounce management. I didn’t check the code, but this appears in our PHP log:

PHP Fatal error: Uncaught Error: Call to undefined function Leafo\ScssPhp\Node\each() in wp-content/plugins/newsletters-lite/vendor/leafo/scssphp/src/Node/Number.php:293

Thanks. Looking forward to test the new version. If we still have issues, I will report back.

You are telling me that you can replicate the error on one server, but not on a second server and therefore there is no bug?

You said you already fixed the bugs? How can you fix it, if you don’t understand the bugs?

No offense, but what you say makes no sense.

In bounce_driver.class.php in line 430-431 you have this:

$hash['Content-type']='';
$hash['Content-type']['type']=strtolower($multipart_report[0]);

Do you see something here? Obviously, you don’t need any information about our sites to fix this. In fact, you can replicate the error without WordPress:

<?php
            $hash['Content-type']='I am the bug because I should be two dimensional';
            $hash['Content-type']['type']='This cannot work';
            echo $hash['Content-type'];
            echo $hash['Content-type']['type'];
            echo "I will never be displayed because the script already crashed in line 3.";
?>

Run this script on a server with PHP 8.1 and then check the PHP error log. You will see this:

Got error ‘PHP message: PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /test/bug.php:3\nStack trace:\n#0 {main}\n thrown in /test/bug.php on line 3’

You have several of these type errors in your code. I fixed a few in bounce_driver.class.php and then bounce management worked again. But I guess you have many more of these type errors in the plugin.

• This reply was modified 2 years, 1 month ago by Michael.
• This reply was modified 2 years, 1 month ago by Yui.

Bounce config:

Subscriber Delete on Bounce: Yes
Bounce Count: 5
Admin Notify on Bounce: Yes
Bounce Handling Method: imap

I can’t share the info from the health status. There is a ton of security relevant info there.

You mean you are unable to see the fatal errors in the WordPress debug.log? This is an example:

PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in wp-content/plugins/newsletters-lite/vendors/bounce/bounce_driver.class.php:431

You have some very obvious type errors in bounce_driver.class.php.

Thanks for the update! Looking forward to try the new version.

I can’t give third parties admin access to our site, but I can help you with debugging.

PHP 7.4 is no option because there are no security updates anymore.

I don’t see any errors from WordPress with PHP 8.1. We have a ton of plugins and all work with well PHP 8.1. Your plugin is currently the only exception.

I just tried it now with PHP 8.0 and I see the same fatal error messages in the WordPress debug.log when bounce management is active.

I already fixed the bugs in bounce_driver.class.php and in mailinglist-plugin.php.

In bounce_driver.class.php, you just have to correct a few assignments of the multidimensional arrays. My fix is quick and dirty, but I guess it is not a big deal for the developer who wrote the original code.

I am unsure what causes the issues in mailinglist-plugin.php, but my guess is it is also related to arrays. After you fix bounce_driver.class.php, you need to check if admin notification works and if the bounce count works properly.

Just tested with PageSpeed Insights. Google reCAPTCHA significantly drags down site performance on mobile pages. You can see it under Reduce unused JavaScript. So the end result is that you get rid of a few spammers, but you will loose many real visitors because Google will downgrade your rank. Thus, you really need to remove reCAPTCHA on all pages where you don’t really need it.

Then it sounds more like a bug than a feature. I removed the code now from posts with the Plugin Organizer plugin and made the logo disappear with CSS on the rest. I hope this won’t break the captcha feature.

I wonder what this “feature” is for on pages without forms? Does this prevent bots from loading pages? I can’t find anything about this in Google’s documentation.

Yeah looks like I use v3. What’s the point in adding the captcha code on all pages? And what is the purpose of the logo?

Thanks for the update. Do you know if bounce management still works with PHP 8.0?