Can you please enable the “WordPress Integrity Diff Utility” option available in the “Scanner” panel of the plugin’ settings page? Once this option is enabled, please go back to the plugin’s dashboard and click any language file that is marked as “modified” (one of the POT files if possible, since they are still in plain text). A window show appear showing the differences between the version that you have installed and the one provided by WordPress.
The data used to determine if a file was modified or not is provided by a public API maintained by WordPress, this API accepts a locale as a parameter, so if your website is in French the API should return the checksum for all the files associated to the French version of WordPress. If there is a modified file is surely because WordPress is incorrectly tracking those files.
That is why I suggest people to ignore those warnings for now, because we have little power over that information, we could include a hardcoded list into our own code, but if WordPress changes something in their files at any time, we would need to release a new version of the plugin immediately, which would make the development very erratic.
Yorman, thank you for the quick reply.
Here are some examples for the Norwegian version of WordPress:
https://www.dropbox.com/s/tjnhptospbb8wlc/Screenshot_21_09_2017__17_44.png?dl=0
As you can see the Norwegian admin-nb_NO.po file is a standard file included in the Norwegian version of WordPress. ( https://www.dropbox.com/s/050h07aw5q6r6he/Skjermbilde%202017-09-21%2017.46.58.png?dl=0 )
I am not sure if you are saying that there is no way for Sucuri to handle international versions of WordPress and changes, or if its a “bug”/problem with how WordPress makes the information about the files available to you.
Without knowing what it would involve, it seems like scanning the repo and the various international versions and making MD5 hashes of those would be one way to go?
This URL [1] is the one that is being used by the Sucuri plugin to check which files are corrupt or not. This API is maintained by WordPress itself, the organization, not Sucuri.
Your suggestion to create this list in the Sucuri servers was already tried some time ago, but it posed more problems than a solution because people would complain a lot after every new WordPress update because the database in our servers would not synchronize immediately, but it would take a couple of minutes to download the latest version of the CMS including all the tens of supported translations. I went ahead and decided to remove that code from the plugin and start using their public API, since they are the ones releasing the new version of their CMS it makes sense to wait for them to put up the checksums on their API instead of rolling our own solution.
If you access the URL linked below and search for any of the files flagged by the plugin as corrupt, for example, admin-nb_NO.po you will find this checksums [2]. Now, if you log into your server and obtain the checksum of the same file you will notice that the hash is different, that is what the plugin is reporting. So the solution to this problem must be implemented by Automattic, the maintainers of WordPress, be we [Sucuri] have no access to the source of that API.
[1] https://api.wordpress.org/core/checksums/1.0/?version=4.8.1&locale=nb_NO
[2] admin-nb_NO.po -> 81cdf0024fdcd95dece6fa18afbc46f8
I 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.
