This may be an old bug that is probably already fixed, install the development version of the plugin [1] and try again. If that does not solve the issue then you will need to check if the options table is being locked by other procedures.
[1] https://downloads.wordpress.org/plugin/sucuri-scanner.zip
I tried the development version with no other plugins active, and I still can’t save my new alert settings.
Even if you have deactivated all the themes/plugins, WordPress still can make queries to the database for multiple things.
During all these days I have been trying to reproduce the bug without luck, I have tried with clean installations of WordPress, with Multi-Site instances, with big and small sites, with empty databases as well as databases with many entries (specially in the options table).
I recommend you to contact the hosting company where you have your website hosted to see if they have knowledge of any issue related with the database that could be causing this issue. Generally this happens when the tables are locked by other queries.
wn nj
(@waseemnaikgmailcom)
I do not know why you are marking these tickets resolved when the issue is not resolved?
I have this issue on two different hosts. WP Engine and Network Solutions. Considering that these are one of the biggest in their own ways, the problem is not with the host or the db.
I realize the frustration of a random issue and your diligence in trying to replicate the issue.
I will be willing to help if you post a way so that all of us who are encountering the problems on unable to save the setting can help you isolate the issue.
I’m still having this problem in the most recent version, on a site with WestHost. As the whole multisite network goes down when this plugin erases the standard WordPress rewrite rules, I’ve had to remove it.
I will create an account in one of the hosting companies mentioned above and will try to reproduce the issue. I will also ask for help to one of my co-workers to see if he can work on this ticket because I have to work in other products inside the company, so I may not have sufficient time to fix this issue this week, I will keep this ticket updated.
Reopening ticket to investigate this once again.
This issue was addresses with commits added between version 1.7.8 and 1.7.9, it was not really related to the code of the plugin as I explained in my previous comments, it was more like a mis-configuration of some sites with custom table prefixes and other things that (at the moment) I do not remember.
I added some error handlers in the code of the plugin to consider these scenarios, although I should not have done this because it proliferates the bad standards in the development of WordPress-based websites.
Anyway, hopefully this will make some people happy, I will mark this ticket as resolved as the issue was fixed and the manipulation of the settings in the database is working correctly.
