Michael

Malay, thanks for fixing this! It works again.

I contacted you but didn’t hear back from you. Anyone interested in fixing this serious bug?

The plugin bug still exists. It appears to happen less frequently, but this can have other reasons. It might be an incompatibility with the popular W3 Total Cache plugin. But this is only a wild guess.

Note that we use countless other plugins that store their options in a similar way and All in One SEO Pack is the only one that constantly resets its settings.

I think you need to completely rewrite the procedure that tests whether the plugin is loaded the fist the time.

Michael, thanks. I just updated. It will take a little until I know if the problem is fixed.

This is bug is still not resolved in version 2.5. Only if I disable aioseop_mrt_mkarry() does All in One SEO Pack keep its settings.

I tested now on a second relatively new site with the new version 1.12.0. Same results. Notifications don’t work.

I skimmed through your notifications.php in modules/notifications. There seems to be a problem with the hook pp_send_notification_status_update. Only if I manually invoke send_notification_status_update() is this function ever called (instead of do_action(‘pp_send_notification_status_update’, $args);).

The problem then in send_notification_status_update() is that the recipients are note loaded which is probably caused by bugs in get_notification_recipients(). For instance, you use the $admins variable in this function that you never define. I suppose this variable is supposed to store the admin email address?

If I manually set email addresses for $recipients in your send_email() function, the notifications are sent properly.

I suggest you test on a fresh WordPress installation and load PublishPress from www.remarpro.com, so you are sure you test with the same release.

Thanks for the fast reply. I just sent the screenshot.

Thanks!

I have evidence now that this problem occurs when the traffic is high. During the holidays the plugin worked just fine, but now as we have more traffic the plugins resets everything every 3-5 days or so.

When I remove line 45 in /inc/aisop_functions.php (aioseop_mrt_mkarry()), no more resets occur.

I wonder why you call this function while the plugin is running? Shouldn’t you call it only when the plugin is activated or when the user manually resets? If the plugin can’t find the current settings for some reason during normal operation, you should throw a meaningful error message and not just silently reset everything, so admins have a chance to figure out what went wrong.

David, thanks for fixing this quickly! It works!

It is a bug because it breaks the “start by me” feature and it probably was introduced in version 2. 1.9.4 doesn’t have this bug. Any chance you fix this?

Thanks! I skimmed a little through your code and I doubt that this is a plugin conflict. More likely is that the error occurs under special conditions like when a sever is very busy.

I wonder why you don’t try to read the options from the database right before you initialize the settings to defaults in aisop_functions.pho. Wouldn’t that be safer? If $aioseop_options gets lost somewhere along the way, you will overwrite existing user settings. I would always double-check before you overwrite user settings.

Thanks for the reply. This procedure does not work in this case because the problem only occurs occasionally. What I need to know is the location where the plugin stores its settings, so I can track down possible conflicts.

But this is the support forum, right? So this is the place where users report issues with your plugin. Gitub is certainly not the right place where end users should report problems.

Michael, I already opened a new issue on www.remarpro.com. The environment is simple: WordPress 4.8.1, Twenty Fifteen theme, All In One SEO Pack 2.3.15.3, WP Ulike 2.8. No other plugins were active during the test.