• I was running file monitor for a while. Don’t believe I got any file change emails, even when plugins were updated. But I noticed my site was having a LOT of problems. wp-options was getting corrupted all the time and the blog was VERY slow or offline due to corrupted tables.

    I found that my wp_options table was over 500MB!!!! Turns out this was due to almost 650 wpfm_listing entries with the hash keys for every file in the site (it’s a big site – lots of plugins) When I deactivated the plugin and removed all of the wpfm_listing entries, suddenly my wp_options table returned to a much more sane 1.8MB.

    Why so many entries? Seems like you’d only need a couple. Also – looking at the way the data was stored, there is a TON of redundant data stored in the entries – namely the root directory, which should never change. If you extract that out into a separate DB record, it would likely trim the hash entries WAY down. You may also want to consider checking the size of a hash before you insert it into the DB so you can perhaps split them up into manageable chunks.

    Now there seems to be some other issues going on with duplicate entries in wp_options from other plugins as well. But File Monitor was the worst by far. And trimming down teh size of the blob may make thigns much easier on larger blogs.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author mattwalters

    (@mattwalters)

    It sounds to me like you have some other issue going on with your WordPress installation and/or database since you mention this is happening with other plugins as well. WordPress File Monitor only attempts to create one wpfm_listing in the database and it uses the standard add/get/update option functions in WordPress to maintain it. So it sounds like there’s an issue here with WordPress or the database causing WordPress to have issues reading from it.

    Thread Starter baptiste

    (@baptiste)

    Agreed about the multiple entries – as I found other plugins with the same problem. Just got finished cleaning up that mess. However the sheer size of the file listing records caused the DB corruption and (thankfully I guess) brought the issues to my attention.

    That said – the wpfm_listing record is still excessively big. Now that I’ve cleaned up wp_options, the table is around 1.8MB with 600 or so entries. The wpfm_listing entry by itself was almost 800KB. I’d still suggest looking into removing the ‘root path’ from every single file entry to trim the hash WAY down.

    Plugin Author mattwalters

    (@mattwalters)

    It’s as small as it can be at the moment, it’s essentially just:

    filename => timestamp [or] hash

    I do have plans/hopes to chunk it up into multiple entries at some point, but regardless, all that data is needed in order for it to perform its job so it will be no less data overall even after I do this.

    Thread Starter baptiste

    (@baptiste)

    Sorry I guess I Wasn’t clear. The entry I had each filenaem listed like this:

    /home/11111/users/.home/domains/mydomain.org/html/wp-content/plugins/cforms/pluginfilesblahblah.php

    Now a wordpress installation won’t (or certainly should not) have files located outside of it’s root path, so basically the ‘/home/11111/users/.home/domains/mydomain.org/html/’ is repeated for every single file in the hash. When you have thousands of files on a large site, that adds up. Just seems like it would be more efficient to store the filenames relative to the WP root directory (stored in another key) It’ll also reduce the memory footprint of the plugin when it’s functioning and has to load the entire file hash in.

    Plugin Author mattwalters

    (@mattwalters)

    Yeah, it’s a good idea. It would need to be relative to the root defined on the configuration page for the plugin, not necessarily the root of WP.

    I’ll need to give it some thought to see how switching from a absolute to a relative path could have an impact.

    Thanks for the suggestion.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘[Plugin: WordPress File Monitor] Excessive wp_options entries’ is closed to new replies.