yorman
Forum Replies Created
-
Hello @aprosen,
I suggest you run a test from the “Alerts” section located in the “Settings” page of the plugin. Select the email addresses that you want to test and then click the “Test Alerts” button, this forces the plugin to send an email with a random message to the email addresses that you selected.
I am no longer receiving email notifications when I or someone else logs into my cpanel
I don’t think there’s any connection between cPanel and WordPress, so I doubt this event is ever reported. I suppose you are clicking a button in your cPanel account that’s triggering the creation of a WordPress session. We do not support this type of login, unless the session is being created using the same API that the plugin is using.
No settings have changed and my plugins are current, however WP did have an update last week.
WordPress 5.0 was released a few weeks ago.
Many things have changed in the new API, and it’s difficult to say if all the plugins that you have installed are compatible with the new libraries. I have meticulously tested the Sucuri plugin with WordPress 5.0 and haven’t found any error. However, other plugins may be broken and may consequently cause problems with the email alerts.
You can try reverting to WordPress 4.9.9 [1] to see if it fixes the issues.
Let me know if you need more information.
Hello, sorry for the delay.
If you are still experiencing the same problem with the IP address, you can fix that following this guide [1]. If you installed the plugin, it will automatically fix this for you as long as your website continues running behind the Sucuri Firewall as you can see in the code [2].
If you continue having problems, please contact us here [3].
[1] https://kb.sucuri.net/firewall/Troubleshooting/same-user-ip
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ee73775/src/interface.lib.php#L43-L56
[3] https://support.sucuri.net/Marking as “resolved”.
I’ve installed both plugins in a fresh installation of WordPress and they both work as expected without showing the error message reported by the original poster. If anyone else is experiencing the same issue and can provide a step-by-step of how to reproduce it, please post it in a comment.
Thank you.
That error message indicates the plugin is working correctly.
The problem is in your website. When the plugin starts the malware scan it sends a HTTP request to the home page to gather initial information. If the home page redirects the request to another page then the plugin follows the redirection. However, if the next page redirects the plugin to the home page again it falls into a redirection loop:
- home-page -> next-page
- next-page -> home-page
- home-page -> next-page
- next-page -> home-page
- etc…
If you inspect the HTTP headers that your website is responding with, you’ll be able to investigate where the redirection loop is happening. Fix it, and the plugin will start reporting the malware status as it was doing before.
Let me know if you need more information.
Yes, that’s a good option too.
If you mark them as fixed, please be sure to review them later when you decide to update your website to Gutenberg, otherwise, if there are modifications in the files after the update, the scanner will not be able to pick them up.
Cheers.
I just installed WordPress 4.9.9 in a new website and the Sucuri Scanner reports no inconsistencies in the source code. I believe your website got updated to 4.9.9 but it also inserted new files to prepare for Gutenberg. At least from the screenshot, it seems that all the new files are part of the “blocks” API which is one of the pieces that implements features for WordPress 5.0.
If you are comfortable with staying at version 4.9.9 you can delete all the files with the green flag. But be careful, if these files were really inserted by a broken update, deleting them will break your website. I, for example, tried to do that in my test website and it broke, I had to replace the entire “admin” and “includes” folders manually.
Marking as resolved, let me know if you need more information.
ClassicPress developers decided to break the Semver that WordPress was following. Their release page shows version 1.0.0 as the newest [1] even though their code is based on WordPress 4.9.8 [2].
They went even further to modify the content of the “version.php” file [3] which WordPress uses to control the deprecation of features in the entire project, something that the plugin ecosystem inherited by using the
$wp_versionvariable to check if their code is compatible with the website installation. In fact, that variable doesn’t exist anymore in their code. They replaced it with$cp_versionwhich seems unnecessary.I’ll pass this to the rest of the development team.
Personally speaking, I think the warning is correct.
[1] https://github.com/ClassicPress/ClassicPress/releases
[2] https://github.com/ClassicPress/ClassicPress/blob/f059778/README.md#contributors
[3] https://github.com/ClassicPress/ClassicPress/blob/f059778/src/wp-includes/version.php#L2-L30I haven’t found any problem with the plugin on WordPress 5.0.
If you notice any incompatibility, please let me know.
We will keep testing the plugin for a few days, once we are 100% sure that everything works with the new version of WordPress we will update the compatibility information. If we don’t find any errors after testing all the features, we will update the information without releasing a new update.
wpephpcompat_jobsstands for “WP Engine PHP Compatibility Jobs” [1].According to the documentation:
The WP Engine PHP Compatibility Checker can be used by any WordPress website on any web host to check PHP version compatibility.
This plugin will lint theme and plugin code inside your WordPress file system and give you back a report of compatibility issues for you to fix. Compatibility issues are categorized into errors and warnings and will list the file and line number of the offending code, as well as the info about why that line of code is incompatible with the chosen version of PHP. The plugin will also suggest updates to themes and plugins, as a new version may offer compatible code.
I don’t know what “Executable PHP widget” and “Email Address Encoder” are.
My theory is, you have one or more plugins that are offering these two tools. When WP Engine runs, it checks for the compatibility of the code in these plugins or tools. Somehow this compatibility check triggered the execution of whatever action they are running, and so the Sucuri Scanner ended up reporting the suspicious event.
You can ask the developer of “PHP Compatibility Checker” here [2] for details.
[1] https://github.com/wpengine/phpcompat
[2] https://wordpress.org/plugins/php-compatibility-checker/Yes, that’s possible.
Add this to your active theme:
if (class_exists('SucuriScanOption')) { SucuriScanOption::updateOption(':maximum_failed_logins', 10); }I’m not going to add an option to set numbers lower than 30 but the code above should work just fine. I recommend you to execute it only once, then remove it once the value is set so you don’t have to be constantly writing data into the settings.
Let me know if you have more questions.
Perfect! Good job.
I believe there are so many scheduled tasks (aka. cronjobs) in your website that the script is taking longer than expected to run, consequentially the server may be killing the script after the maximum execution time is exceeded.
The code in itself is not buggy, memory issues are just difficult and some times impossible to deal with using a scripting language like PHP. I guess I can add a pagination in that table so the plugin doesn’t has to load all the extra data associated to each cronjob when rendering that page.
If you don’t mind, please keep that line commented.
I will modify the code to handle big cronjobs more efficiently.
Thank you for the report.
Hello @justin-bigscoots
I am unable to reproduce the issue.
If you feel comfortable editing PHP code, please open this file [1] and comment all the array assignments inside
function sucuriscan_settings_page()as referenced by the yellow lines in this page [2]. Then, one by one, start uncommenting each line, and each time test if the page loads.Doing this, you’ll eventually find the line that’s causing the issue.
Tell me which line is it and I will continue the investigation.
[1]
/wp-content/plugins/sucuri-scanner/src/pagehandler.php
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ceaf0d2e4ff46c4ec32a2c069f2138643809e52e/src/pagehandler.php#L121-L176Hello @ashucg
The error comes from this function [1] used here [2].
When you visit “Settings > Scanner > Scheduled Tasks” the plugin calls a function provided by WordPress called “wp_get_schedules” [3] which is supposed to return a list with all the active scheduled tasks (also known as cronjobs).
According to the documentation, each item in the list contains an attribute with the arguments that will be passed to the corresponding functions that will run once the cronjob is executed. This attribute is supposed to be an array, but there seems to be an inconsistency in your website because one or more of the values is a string.
Thank you for the bug report and the suggested fix.
I’ve created a request to merge this fix into the code [4].
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ceaf0d2e4ff46c4ec32a2c069f2138643809e52e/src/base.lib.php#L871-L891
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ceaf0d2e4ff46c4ec32a2c069f2138643809e52e/src/settings-scanner.php#L155
[3] https://codex.wordpress.org/Function_Reference/wp_get_schedules
[4] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/66That’s okay, the cronjob on itself doesn’t do much.
WordPress runs all the cronjobs as long as they exist, but if you really uninstalled the plugin then there is no PHP script to execute. You have nothing to worry about.
Thank you.
Hello,
Re: purelatitude.com […] 404 Not Found
Right now it appears to be clean [1].
[…] are you saying that sitecheck only works over SSL?
No, but the scanner attempts to connect to the HTTPS version of the website anyway, because some times web developers forget to add HSTS [2]. The problem is, if your website(s) doesn’t work over HTTPS, the connection should fail, but your server(s) replied to the handshake successfully because some hosting providers serve these requests with a default page.
The scanner doesn’t knows that your website is not available via HTTPS, it just knows that the connection worked and the hostname in the SSL certificate doesn’t matches the hostname.
The expected behavior is one of these:
- Scanner checks “example.com”, the website is available over HTTPS, the scanner executes the TLS connection, the operation succeeds and the hostname in the SSL certificate matches the domain name.
- Scanner checks “example.com”, the website is not available over HTTPS, the scanner executes the TLS connection, the operation fails and so the scanner continues checking only the HTTP version.
If the website fails outside of these two cases, then a warning is triggered.
[…] this was only a sample of sites, I have dozens […]
I understand, but I cannot say with confidence that the scanner is failing to scan all your websites for the same reason. Some of them may have different misconfigurations, I prefer not to generalize, but I would say this is a cache issue. If you send me the entire list of domains, I may be able to tell you if all of them are failing for the same reasons or not.
[1] https://sitecheck.sucuri.net/results/purelatitude.com
[2] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security