I am forking a DB clean up plugin just to keep my brain


I am forking a DB clean up plugin just to keep my brain sharp and ran into an issue that I used to know the answer but for the life of me I can't remember.

The plugin as it is works as expected on a new MS install but if it is used on a install that was WPMU converted to MS it won't save options.

I have done all the standard debugging stuff: deactivating all plugins and default theme.

So, I am pretty sure it is a coding or permissions thing.

Given that I am confident that I used to know this answer a few years ago when MS first came out I figured someone a bit younger than me with sharper memory could help me recall.

I appreciate any help you can provide.

Dr. Pat

  • Tyler Postle

    Hey Pat,

    Hope you're doing well today!

    I'm thinking my memory may not be sharper, or I'm not younger lol. I'm having a bit of trouble understanding the issue here.

    I'm assuming MS is Multisite? I'm confused on the WPMU converted MS part. Not sure how that is different from the new multisite install in this context.

    Also, which DB cleanup plugin is it?

    Look forward to hearing back! Hope you enjoy the rest of your weekend.


  • wlpdrpat

    Hey Tyler,

    Were you around when wpmu was separate installation from wp? Prior to wp 3.0 is was a separate installation and thereafter it was rolled into the core. In the first few upgrades from 3.0-3.1 it was a bit of a disaster for people that had an original wpmu installation as they hadn't worked out the kinks. I think that all happened in 2010. Of course, wpmudev was there to help us through the transition and did a great job of assisting plugin developers with understanding how to make their plugins MS compatible.

    Anyway, the plugin I am forking (and it is not an official fork as I am doing it for myself and sharing it with the current developer) is http://wordpress.org/support/plugin/rvg-optimize-database

    They have done a good job of documenting their code but have used a lot of php and sql stuff where they could have used more native wp coding. Their bigger issue IMHO is that on MS they didn't use a Network Admin page and chose to use an admin page on the primary blog and that is where the WPMU > MS upgrade takes affect as in the db for those with the WPMU > MS upgrade the primary blog is not the same as in a new MS install they are wp_1 and wp_, respectively.

    My recollection was that there was a simple tweak that can be made to fix this which is a check for WPMU and then defines the primary blog or something to that effect.

    If you are not familiar with the debacle of WPMU to MS it could be a fun bit of learning for you or you could bump the question to one of the developers that was around in 2010.


  • wlpdrpat

    Hey Tyler,

    I dug through a few of my older plugins and found it. Of course, once I saw it it was a total V-8 moment.
    It is creating a unique function for get, update & delete options. Then inside these functions using an if multisite.

    Here is an example of the delete option:

    function my_plugin_delete_option( $option ) {
    	if(is_multisite() && function_exists('is_plugin_active_for_network') && is_plugin_active_for_network('my-plugin/my-plugin.php')) {
    		return delete_site_option( $option );
    	} else {
    		return delete_option( $option );

    Again this is important for old multisite installs that have been around since before multisite. Why? Because their primary blog doesn't use base_prefix in the db it uses wp_1.


Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.