mattwalters

My guess on it still scanning after being deactivated might be due to a caching plugin also being enabled? To perform the scan, the plugin loads itself as a CSS file, which means it also has to load WordPress itself, so that portion of the plugin doesn’t act like a normal plugin (meaning that portion alone bypasses the activated/deactivated check).

It shouldn’t have been continuing to send you emails without you dismissing the notification. My guess would be the files were continuing to be modified, but without looking into it myself it would be a little hard to determine the root cause.

Also, I agree, it’s getting too resource intensive and needs some efficiency work. Until I have time to do that though, about the best recommendation I can make is set the scan interval to zero and then you can run a manual scan whenever you would like from the settings page. Sorry, I know it’s not ideal but I haven’t had much time to focus on enhancing it recently. Development on it isn’t dead, I just need to get some free time to make some changes I’ve been thinking of.

How large is your site? (how many files are needing to be scanned)

And if you have suggestions, I’m of course willing to listen, but you weren’t exactly giving constructive criticism here ??

It’s included as a CSS include so that your site can continue to load while the scan takes place. Had I made it just run on a standard hook it could have caused your site to pause loading for a visitor while the scan was processed.

It’s not admin only because many users don’t visit their admin on a common basis. For instance, I can sometimes go a week or more without logging into my administration area, but I still want to be notified in a timely fashion if one of the files on my site were to be modified.

Thanks for the feature suggestion about making it configurable to be only run in the administration area, I’ll give it consideration. However I will mention that if this is a concern for you, you could set the cron to zero and just run it manually at your choosing. It wouldn’t stop it from being included on the visitor facing side (pretty sure it wouldn’t, I’d need to go back and look at my code), but it would prevent a potentially slow loading element. I’ll definitely add it in so that if the cron is set to zero then the include doesn’t happen if it’s not that way already.

And yeah, I was switching my site to a dedicated IP and DNS was messed up for a little bit because I forgot to change an A record. It’s straightened out now.

You should be able to fix this by changing your WordPress URL under Settings -> General to include the https. Due to the various setups you can have for WordPress, I find it’s best to rely on functions like this for URLs.

That should be plenty of detail for any reasonable host.

On various server configurations PHP runs under different user accounts. It could run as the user “nobody” or it might be running as the user that owns the file. It all depends on how they set up their server to determine what user PHP runs as for a given request.

Also, the plugin should not be throwing 404 requests. It is not monitoring URL’s, it is monitoring files in the file system. The only 404 that could possibly be getting thrown by the plugin is when it tries to include itself as a CSS file to perform the scan. Can you share what 404’s you are seeing (at least in part)?

The important part of my statement was, “Whatever user PHP runs as will need at least read permissions.”

You may have read permissions to it, but that doesn’t mean the group the user PHP is running as has read permissions to all of the files. Without knowing more about your hosting setup.

If I code in some error checking for this, it won’t totally solve your problem. It will still only be able to monitor files with the correct permissions.

The plugin does seem to be working fine with 2.8.6 on my site and others. You mentioned that you did some permissions changes. Whatever user PHP runs as will need at least read permissions to any files you need the plugin to scan. Otherwise it will error out. I need to add some error checking in for this probably, but it should not be a compatibility issue between 2.8.6 and the plugin. You might need to work with your web host to make sure that the user PHP is running as has the correct permissions to the files.

You’ll still probably need to give me more detail. I just tested it and am so far unable to reproduce the error you’re seeing.

Perhaps try emailing me the text you’re trying to paste in, in case that has something to do with it.

Can you add any more information regarding this? WordPress File Monitor doesn’t touch the add/edit post/page screen so I’m not sure how it could be interfering with that area. Have you tried disabling the plugin and running your test to see if it works then?

How many files are you trying to scan?

You’re probably going to have in increase the amount of memory for PHP (your webhost might have to help you with this depending on your hosting setup)

As others have said, make sure you’re getting your FTP password changed. A site I worked on was hacked with almost the exact same code recently and they were getting in via the FTP account. Also make sure you have no key loggers / viruses, etc on your computer (or the computer of anyone with access to your account).

I wrote a plugin to help monitor for things like this in the future if you’d like to take a look at it:

https://mattwalters.net/projects/wordpress-file-monitor/