When you receive a notice about the existence of a WordPress core file that is discovered to be different from the original, or missing, you have a choice.
- Immediately repair the file (i.e. replace its content with the original WordPress.org source)
- Investigate and repair the file manually so it is aligned with WordPress.org
- Set the scanner to automatically repair files when the scan next runs
- Completely ignore the notice and continue to receive the same email each day when the scan runs again
Clearly we don't want option #4. So to resolve this issue, you must do #1, #2 or #3.
The plugin provides the built-in option to automatically repair any files that are discovered to be different/missing. This is by-far the easiest method and approach to the issue and you should only be scared about doing this if you have the practice of modifying core WordPress files - which is frankly not very wise.
If you don't like this automatic approach and you prefer manual labour, you can dig in and find what the differences are.
Our opinion is this: Your files should ALL be identical to the WordPress core files. If they're not, they should be immediately replaced to be so. Your role as a WordPress administrator is to resolve this discrepancy. You can do it manually, or you can trust the website has been constructed in line with WordPress best practices and have the plugin automatically fix this for you.
The choice is entirely up to you, which is why we don't enable the automatic file repair by default.
How to identify a specific file reported as a threat
If you receive notification email with information like this
"The contents of the core files listed below don't match official WordPress files:
- index.php ( Repair file now / WordPress.org source file"
and you want to identify the specific index,php file being reported on, please look for it at the top of the WordPress directory.
The paths start at the top of the WordPress directory. So if that file hasn't got any subfolders, it's at the top of the WordPress installation.