yorman
Forum Replies Created
-
Hello @raywpa
I apologize for the inconveniences setting the timezone.
Dealing with dates in a distributed system is tricky. I’ve added the setting in the plugin because it was clear, after several attempts to fix this problem, that the WordPress setting was not working for the audit logs. There must be something somewhere in the code messing up the timestamps, probably removing the timezone tag, and so when the date is formatted it shows a different time because there is no timezone to translate.
For now, I recommend you to set the timezone to +0 UTC. This is considering that the dates are showing up +10 hours ahead of time, and you configured the plugin to show the dates in UTC+10.
Let me know if that works for you.
Hello,
> Is there any way I can fix this issues as I like using your plugin too.
I would need to modify the code to make it compatible with whatever code the other plugin is using. Can you tell me the name of that plugin and what version are you using? This will allow me to include it into our testing environment to investigate where the conflict is happening.
I will wait for your reply.
Hello @edfoc you can ignore these alerts:
- Visit the plugin settings page
- Click on the “Alerts” tab
- Scroll down to “Post-Type Alerts”
- Add the ID of the post-type that you want to ignore
- Click “Submit” to save your changes
Let me know if you need more information.
/wp-content/languages/ does exist and can be written to.
If this statement is true, then I suggest you consult with your hosting provider to investigate possible I/O failures.
When you choose the “Restore” action, after selecting all the files marked as “Deleted”, the plugin opens a connection with WordPress to download a fresh copy of each of these files, then it writes the code into the disk in the corresponding location. The only failures points for this operation are:
- The destination directory is missing,
- The destination directory is not writable,
- The destination is a symlink to a non-accessible resource,
- The server couldn’t connect to the external WordPress API,
- Your web browser reset the connection to send the list of files,
Let me know if you would like to have more information.
The red flag means “Deleted”.
Files marked with a “deleted” flag are files that are supposed to exist in a normal WordPress installation. Of course, if the file doesn’t exist, you will not be able to find them either using FTP or a file manager. You also cannot use the action “delete” because they already do not exist.
The only thing you can do is to either mark them as fixed or select the option to restore them. If the option doesn’t work, like in your case, is because
/wp-content/languages/either doesn’t exist or PHP cannot write inside.You’ll have to fix this manually before proceeding with the restoration.
The plugin uses WordPress’ function
get_site_url[1][2][3] to get your website’s address. Then it sends this address to Sucuri SiteCheck and that’s when the malware scan starts. If SiteCheck is unable to scan your website then it’s because WordPress is reporting an incorrect address via “get_site_url”. In this case, you’ll need to report this bug to WordPress itself.You can, however, change the address that the plugin is sending to SiteCheck and stop the plugin from using the broken “get_site_url” WordPress function. You can do this from the “Scanner” panel located in the plugin settings page, under “Malware Scan Target”.
Let me know if you need more information.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ee73775/src/sitecheck.lib.php#L48-L63
[2] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ee73775/src/base.lib.php#L551-L567
[3] https://developer.wordpress.org/reference/functions/get_site_url/people are comenting that they will not update the plugin until after you have finished testing the plugin’s compatibility with the new version of wordpress
That’s correct.
The warning that you see in your WordPress installation is because WordPress is comparing the version number that we have defined here [1] with the number 5.0.3; because the version is lower, WordPress advices the admin to be careful using the plugin as it could be using API endpoints that may be deprecated in your installation.
Rest assured that this is not the case. The wrote the code in such a way that makes the plugin fairly independent to WordPress’ API. It would take a significant breaking change to make the plugin incompatible. The current version of the code is fully compatible with WordPress 5.0.3.
I’ll let @ycampo decide if it’s okay to bump the version number up now.
I’m marking this ticket as “resolved” one more time, as the purpose of the ticket has been addressed. Let me know if that’s not the case and we can re-open it to continue the discussion.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/blob/ee73775/readme.txt#L6
Hello @terry777
Thank you for your concern about the compatibility of the Sucuri plugin with the latest version of WordPress. I personally haven’t found any incompatibility with WordPress 5.0 nor with 5.0.3. However, catching bugs with breaking changes in WordPress’ API takes some time.
I can assure you that a significant percentage of the functionality in the plugin still works, there may or may not be some edge cases, but we haven’t received any report that would make me consider the code incompatible.
That being said, @ycampo is in charge of bumping the version number up.
If you find any bug with WordPress 5.0.3 let me know and I’ll fix it.
Thank you.
Hello @adil1641
Please refer to my comment on this thread [1].
I’m marking this ticket as “resolved”, but I’m actually intending to mark it as “duplicated” as this is being discussed in another ticket. However, this forum doesn’t provides with other status for tickets.
WordPress has a clever way to prevent two or more authors from modifying the same post or page at the same time. They do this by monitoring, every few seconds if the editor has been open by two or more users.
Along with this, WordPress also automatically saves every change as a special type of post called “Draft” which are automatically removed once the post that the user is modifying is saved.
The Sucuri plugin detects these two events and actively reports the suspicious changes. But it is up to the website administrator to decide if the reports are useful or not. If you don’t want to receive the auto-draft alerts, you can opt to turn them off following these instructions:
- Visit the plugin settings page
- Click on the “Alerts” tab
- Scroll down to “Post-Type Alerts”
- Click the “Show Post-Types Table” button
- Uncheck anything with the “auto-draft” label
- Scroll to the end of the table and click “Submit”
Let me know if you need more information.
Hello @nicklock you can ignore these alerts:
- Visit the plugin settings page
- Click on the “Alerts” tab
- Scroll down to “Post-Type Alerts”
- Click the “Show Post-Types Table” button
- Uncheck anything with the “auto-draft” label
- Scroll to the end of the table and click “Submit”
Let me know if you need more information.
Someone is using a feedback form that’s embedded somewhere in your website to send spam. The change of IP address may indicate that the offender is using either a proxy to mask their real location. And the change in the title may just be a way for them to mark which batch of requests are resulting in successful attempts.
It is up to you to decide what to do with the information that the plugin is sending. You can either install an additional plugin to block or filter these requests, or place a web application firewall in front of your website to take care of this and other type of attacks.
Let me know if you need more information.
That was just a temporary issue in your website that our scanner just coincidentally picked it up before it was fixed by either you, your web developer, or your hosting provider. You can see here [1] that everything appears to be free of malware, at least superficially.
Note: it may take a few hours for the cache in your website to refresh the results of the scan. You can go to “Settings > Data Storage” and reset “sucuri-sitecheck.php” to force the plugin to run a new scan if you don’t want to wait.
Let me know if you need more information.
[1] https://sitecheck.sucuri.net/results/german-gluhwein.com
Hello @tzeldin88
This site does not have either of those files, so a 404 would be valid. But why did Sucuri attempted to find it?
There is a family of malware that hides itself by masking the response to the HTTP request with a “404 Not Found” code. Sucuri attempts to discover these hidden scripts by sending a simple request to random files, not necessarily the ones that you mentioned in your comment.
That being said, I believe the warnings in your website were triggered for a different reason than the warnings in @loosefast ’s website. I have to agree with you that the error gives no helpful information. I’ll pass this to the team that maintains SiteCheck (which is what the plugin uses to scan the websites) so they can consider to improve the error messages.
Thank you.
The fixes have been submitted [1] and is now up to the other project maintainers to review and test the changes. They will be released with a future update.
[1] https://github.com/Sucuri/sucuri-wordpress-plugin/pull/69
Thank you.