yorman
Forum Replies Created
-
Ah okay! There is an unhandled exception during the file system scan.
I already worked on this case, the fix is already in our development repository [1], but I cannot release a new version of the plugin before the QA testing is finished, my co-workers are still reviewing the changes, not only for this bug but also for other things that we decided to modify since the last version.
Feel free to install the development version of the plugin for now [2].
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/2795c7e
[2] https://github.com/cixtor/sucuri-wordpress-pluginA “500 — Internal Server Error” is a very ambiguous and hard-to-track error.
Troubleshooting a 500 Error usually requires to have access to the server to make modifications in the code in order to find the origin of the problem, and I cannot ask you to provide administrative access to your website to do this as this would create liability.
Please disable the plugin for now, I will try to reproduce the issue and include a patch during the next update that hopefully will fix the problem. If you are willing to try the development version of the code (code that includes multiple bug fixes since the latest release) feel free to download a copy from here [1] I will mark this as resolved and move it into our internal issue tracker, my project manager will assign a priority to this case and notify me when I need to work on the fix.
The data is loaded via Ajax, you will need to inspect the HTTP request by yourself (because obviously I don’t have access to your website) and then check if there is any error in the console. With this information we can continue the investigation, usually when someone reports issues with Ajax requests, it’s a problem with the server itself more than the plugin, so rather than falling into a rabbit hole with this ticket that may lead to the same conclusion I will ask you to provide more information.
Marking as resolved for now, feel free to re-open when you have additional information.
I had Coming soon/maintenance mode active, so the first problem could be because of that
Yes, you are correct.
The malware scanner in the plugin relies in a remote API service to collect information in your public website to determine if there is an infection in the code. This service [1] has some rules that will immediately stop the scan if no relevant data can be found during the first request, one of those rules was triggered by the text referring tot he maintenance mode that you activated.
Consequently, the service cached the result of the scan, and because it was unsuccessful the subsequent scans returned the same error message even if the website as not in maintenance mode anymore. The cache is automatically reset after 48 hours unless someone manually request a fresh scan from the official API.
Just installed wordpress, with all default settings/themes. What is modified
It’s hard to tell. I know that some hosting providers like to offer a custom version of the WordPress installer which includes either additional features designed by them, or less features to reduce the interference with their own system. I cannot say much about this specific question because I don’t know how your website was installed, but surely something in your server was modified in order to trigger the warnings in the integrity checker.
There is an option in the settings page, under the scanner section, to allow you to see what were the changes on each flagged file. Feel free to enable that option and click each file in the WordPress integrity table, you will see a box with red/green color showing what was the original content and what is the new one, respectively.
It seems like such a simple integration to add, why hasn’t it been done yet? It’s a simple htaccess rewrite.
I know that it is easy to implement. But I am not the owner of Sucuri so obviously the business decisions cannot be taken by me. The features that are implemented are intended to complement the features that we are already providing through premium services like the Sucuri Firewall [1] and/or the rest of the Security Platform [2].
The features provided by the Sucuri Firewall are much more powerful than the ones provided by the plugin, and technically speaking it would be impossible to reimplement them into the plugin without asking for additional access to the server, something that obviously a free customer will not provide. So instead of implementing a simple feature (like the rewrite in the htaccess file that you are suggesting) we want to provide a good implementation through an affordable platform that does much more than many people think.
Give the Sucuri Firewall a try, many of our customers are happy with it.
[1] https://sucuri.net/website-firewall/
[2] https://sucuri.net/website-security-platform/Sure, why not.
Here is the implementation [1].
Feel free to install the development version of the code from here [2] or wait until the official release of the next version of the plugin, this will happen in a couple of weeks, so if you need an immediate solution I suggest you to download the code from the development repository. My co-workers will conduct a QA test and we will release the update when all my changes are reviewed, not only this one but also other changes implemented since the last update.
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/cb1cd3e
[2] https://github.com/cixtor/sucuri-wordpress-pluginThis option was already on by default in previous versions of the plugin.
Many — MANY — people complained to me saying that it was a bad default value because in many cases they were publishing/editing multiple articles through out the day, which obviously would cause the automatic refresh of the cache, consequently making their websites slow (until the cache was regenerated). I decided to revert this option to reduce the number of tickets, that way I can focus on writing code rather than resolving tickets.
I will consider to reimplement this option by leveraging a new API endpoint in our Firewall that allows to specify which page we want to flush the cache, that way when you edit a page the plugin will only request the refresh of that specific page rather than the entire website.
However, there are many edge cases that I need to take in consideration before writing the code, this is easy for the “edit” action, but when you create a new page there is no URL to refresh, and depending on how the layout of the website was implemented the plugin may need to request the refresh of the home page, the internal post listing, custom pages defined by the webmaster, etc.
I will move this into our internal issue tracker and let my project manager decide when to implement this feature. Once I finish my work in other tasks that have a high priority I will move into this. Thank you for the suggestion.
You can change the path to the storage directory setting a constant
SUCURI_DATA_STORAGEin your configuration file. This is explained in the “Data Storage” section under the general settings page. You can read the code that is generating the directory here [1] and if you notice the “SUCURI_DATA_STORAGE” overrides all the default behavior.[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/13de2f4/src/sucuriscan.lib.php#L252-L276
Please contact your hosting provider and ask them about the status of the mail queue in the server where your website is being hosted. Technically speaking, it’s impossible to tell — using PHP — if the mail that went through the
mail()[1] function will actually arrive to your inbox, we can barely check if the function sent the message to the mail queue in your server, but the rest is part of a chain of actions that the plugin has no access to, only your hosting provider can guarantee the delivery of the messages.Hello @scartinh I already worked on this case, the fix is already in our development repository [1], but I cannot release a new version of the plugin before the QA testing is finished, my co-workers are still reviewing the changes, not only for this bug but also for other things that we decided to modify since the last version.
Feel free to install the development version of the plugin for now [2].
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/acae69d
[2] https://github.com/cixtor/sucuri-wordpress-pluginHello @ale5000 — @harzens I already worked on this case, the fix is already in our development repository [1], but I cannot release a new version of the plugin before the QA testing is finished, my co-workers are still reviewing the changes, not only for this bug but also for other things that we decided to modify since the last version.
Feel free to install the development version of the plugin for now [2].
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/b88fd35
[2] https://github.com/cixtor/sucuri-wordpress-pluginMy project manager has agreed to implement some of the suggestions in this ticket. I have moved them into our internal issue tracker and will work on them once I finish my other tasks with more priority. Thank you once again for the suggestions.
Hello @tylerdca I already worked on this case, the fix is already in our development repository [1], but I cannot release a new version of the plugin before the QA testing is finished, my co-workers are still reviewing the changes, not only for this bug but also for other things that we decided to modify since the last version.
Feel free to install the development version of the plugin for now [2].
[1] https://github.com/cixtor/sucuri-wordpress-plugin/commit/b88fd35
[2] https://github.com/cixtor/sucuri-wordpress-pluginI reviewed this ticket once again after additional reports from other users about problems with the WordPress integrity checker. It seems that during the installation of the language files WordPress is not resetting the WP_LANG constant, which is the one used by the plugin to retrieve the checksum list from their API. This small problems causes the plugin to download a copy of the checksums that doesn’t includes the language files that were installed in the website.
We will release an update with the fix in the next couple of weeks.
Hello @tuscanytrace were you able to find the trigger for the memory allocation issue between the Sucuri plugin and Caldera Forms?
I have tried to reproduce this problem in multiple servers and it never happens. I wonder if there is something else in your website that is contributing to the exhaustion of the memory and so coincidentally something in one of these two plugins is just adding the last drop of water into the almost full glass, which would explain why it happens inconsistently.
I will mark this ticket as resolved as this may just be an edge case, it doesn’t seems to be affecting any one else. Feel free to re-open the ticket if you have more information to share so I can continue the investigation. I also suggest you to report the problem to the developers of Caldera Forms so they can also take a look.