This usually happens when the options table in the database is being locked by other queries, but it is very rare and hard to debug because that error depends on the environment of the server where your site is being hosted.
Do you see any error message after the submission of the form? Are the “Alert Settings” the only options affected? If you disable/enable one of the file system scanners (from the scanner settings panel) or change one of the options in the general settings panel, are the changes saved?
Sorry for the delay. I was ‘out of the office’ for a bit. I tried changing the scanner settings and that didn’t work. I then tried to change the email address that the alerts go to but I am still getting emails at the original address.
As far as the server environment, the site is hosted by my own Managed VPS server if that helps.
Thanks,
Terry
Sorry for the delay. I was ‘out of the office’ for a bit. I tried changing the scanner settings and that didn’t work. I then tried to change the email address that the alerts go to but I am still getting emails at the original address.
As far as the server environment, the site is hosted by my own Managed VPS server if that helps.
Thanks,
Terry
This seems to be related with this other ticket, it seems that the database is not storing the settings of the plugin correctly, so the variables that control the sending of the notifications are acting as if they are being reset every time.
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).
The function that sends the emails in the plugin is called in two different parts, one is when you reset the password of one/more user accounts using a tool available in the “Post-Hack” page, and the other is when the plugin will send a notification. In this last case the function retrieves the destination email address from the options table, the name of the option is sucuriscan_notify_to which can be updated using an option located in the general settings panel in the plugin’ settings. If this option does not exists then the plugin retrieves the administrator email address.
So, the only solution I can give you (considering that I am unable to reproduce the bug to give you 100% accurate response) is to set the email address as [email protected], this will force the plugin to send the notifications to a non-existent email address. And I recommend you to contact the hosting company where you bought he VPS to see if they have knowledge of any issue related with the database or the SMTP/IMAP servers.
Your efforts are much appreciated. I have since installed your plugin one 3 other sites that I host on the same server. All 3 of those sites are not demonstrating the same email issue.
Are you suggesting that I change the email setting to [email protected] in the main dashboard setting (administrator) of WordPress? I have already changed the email address in the plugin but that has had no effect, the email still goes to the administrator address.
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.
Now that you mention “WP-Engine” I remember that some of our clients were reporting something similar in our internal support system. Unfortunately in our system when a ticket is marked as “closed” it became unreadable so I can not search them to know how the issue was fixed. I remember that the issue was related with the configuration of the STMP server in the machine where the websites involved in the error were being hosted. I will continue investigating this issue.
Marking as “not resolved” again.
wn nj
(@waseemnaikgmailcom)
Yes, and I went back to my notes and emails to see if there was any discussion on this how it was resolved, but have no record.
wn nj
(@waseemnaikgmailcom)
Just to follow up on this, I did revert all the settings on hardening and tried again to save the changes in the emails alerts but no luck.
wn nj
(@waseemnaikgmailcom)
the problem, at the present, cannot be in the smtp, because, I have not changed anything in the older system.
and just to go over, the older system was broken, it “got” fixed and now it is broken again.
fyi, the older system was on WP-Enginge and I have the installs on different boxes on different IP addresses.
When someone unchecks the ‘send email notification’ does that not trigger an action in the database? My depth of knowledge on these issues is not great but it seems to me that if an option is ‘on or off’ there must be something that records that choice? Since my problem is only with one installation of Sucuri among the 4 sites, on the same host, is there something in that database that I can compare the 4 databases to? I can see that the database, with the problem, has a record of where I changed the ‘send to’ email address but it is not using that email.
As a random thought, the 1 site with the issue is the first one that I installed Sucuri on and the only one that is not responding to the change.
wn nj
(@waseemnaikgmailcom)
Yorman has been very responsive on this issue.
I gave him access to my installation and he has reported a few issues back to me.
This in turn led me to cross check with another installation.
In short, I think he has got this narrowed down and hopefully will be able to post update soon enough.
keeping my fingers crossed.
The quality of a plugin is always relative to the support the developers give it. I am very happy to see them make the effort. Thanks to you as well for coming onboard to assist with this.
Happy New Year to all.
I fixed the issue with the help of wn nj. I found that this only happen if the plugin is installed in a website using Multi-Site (aka. Network). Sometimes the documentation of the WordPress core functions is confusing, and the error that we are discussing here was caused because I confused the functionality of get_option and get_site_option. And there must be another bug with the update of the settings because WordPress also has update_option and update_site_option.
I will add the patch for this bug to the development repository so you can replace the current plugin with the development version, do not download that archive now, I would like to polish the code a little bit, maybe at the end of the day or tomorrow.
