The MU forums have moved to WordPress.org

Custom Plugin duplicating options (8 posts)

  1. webmaestro
    Member
    Posted 15 years ago #

    D'oh! I've created a home grown plugin/theme combo, and upgrading to wordpress-mu-2.6 exposes a bug which causes my options to duplicate on some blogs, with the 2nd option populating with the defaults. At first I thought I lost data, but upon analyzing the database, I could see that the options are just duplicated.

    Here's how they were called:

    add_option('freedom_sitedomainsub', 'www.','Sub domain value--useful if subdomain is different from http://www.','';);

    In troubleshooting, I removed the description and set autoload to 'yes':

    add_option('freedom_sitedomainsub', 'www.','Sub domain value--useful if subdomain is different from http://www.','';);

    Finally, I've changed it to this, since the optional description has been deprecated, and I don't care about autoload:

    update_option('freedom_sitedomainsub', 'www.');

    my data before loading in wpmu 2.6 shows:

    73, 0, freedom_sitedomainsub, 'www.', ''

    after loading in wpmu-2.6 it shows:

    73, 0, freedom_sitedomainsub, 'www.', ''
    14567, 0, freedom_sitedomainsub, 'www.', 'yes'

    Any ideas?

  2. MrBrian
    Member
    Posted 15 years ago #

    I'm thinking you would need to delete_option for every blog, then re-add. I'm confused though, because it's fine if the autoload is blank i believe. Do these options have to apply for each blog, or could you make them sitemeta? I think you have a lot of options, i just don't understand exactly what you want.

  3. webmaestro
    Member
    Posted 15 years ago #

    All blogs share the look & feel of their 'parent' site, so they appear to be extensions of their parent sites. I created the Freedom Options plugin to integrate with some themes I created, so they could easily maintain their look & feel, and I can upgrade one or two themes, and all blogs benefit from the upgrade.

    FWIW, our bloggers don't have the option of really 'choosing' their theme. Because each blog is monetized according to values they specify in the 'Freedom Options' plugin, they have to have use their parent site's theme.

    All of our blogs use this 'Freedom Options' plugin to integrate with one of three themes:

    • Theme 1 (the old style, where they can 'build' the theme's HEADER, FOOTER, NAV, CSS & other values via Freedom Options values)
    • Theme 2 (Theme 1 plus remote includes() HEADER and FOOTER from the LIVE site via Freedom Options values)
    • Theme 3 (remote includes() a cached version of their main site's template into which wp_head(), wp_foot() and 'the loop' are inserted)

    I can't imagine how the delete_option() could help here. I need those values in perpetuity. The fact that these values replicate when I upgrade to wpmu-2.6 in the wp_XX_options table, means that get_option('freedom_sitedomainsub') sees two of the same options (or perhaps sees only the 2nd value). This means the blogs in question effectively lose theme customizations (their CSS values, monetization values, analytics values, etc.). The data isn't lost, but the front-end uses the 2nd, newer value.

    I use add_option() to create the values initially, then I use the following code to update/delete from the table.

    function freedom_add_theme_page() {
    	global $wpdb;
    ...
    	if ( $_GET['page'] == basename(__FILE__) ) {
    		if ( 'save' == $_REQUEST['action'] ) {
    			if ( isset($_REQUEST['njform']) ) {
    				if ( isset($_REQUEST['defaults']) ) {
    				} else {
    					if ( isset($_REQUEST['freedomsitedomain']) ) {
    						if ( '' == $_REQUEST['freedomsitedomain'] )
    							delete_option('freedom_sitedomain');
    						else
    							update_option('freedom_sitedomain', attribute_escape($_REQUEST['freedomsitedomain']));
    					}
    ...
    			}
    			//print_r($_REQUEST);
    			header("Location: themes.php?page=freedom_options.php&saved=true");
    			die;
    		}
    		add_action('admin_head', 'freedom_theme_page_head');
    	}
    	add_theme_page('Freedom Options', 'Freedom Options', 'edit_themes', basename(__FILE__), 'freedom_theme_page');
    }

    The above code has been in PRODUCTION and working this way since March, 2007 (wpmu-1.2.1). We are currently usingwpmu-1.3.3 and I haven't upgraded to 1.5.1 yet (not upgrading to 1.5.1 could be an issue).

    BTW, thank you for your help (and for your assistance for all of us wpmu-dev'ers!).

    Clay

  4. webmaestro
    Member
    Posted 15 years ago #

    D'oh! I just noticed that this should've been in the Plugins and Hacks section... My apologies!

  5. webmaestro
    Member
    Posted 15 years ago #

    I just noticed this:

    Updating WordPress Plugins for 1.5.1

    Where they recommend this sort of action before activating the plugin:

    // Run setup after the pluggable functions have loaded
    add_action('init', 'myplugin_setup')
    
    function myplugin_setup()
    {
    	// Code lives here
    }

    Might this be the issue?

  6. webmaestro
    Member
    Posted 15 years ago #

    Ahem... I had a momentary lapse of reason in my troubleshooting... I can't have those initial steps be update_option() calls, as that'll replace the values before we begin...

  7. webmaestro
    Member
    Posted 15 years ago #

    UPDATE: If I restore the database (or just the wp_XX_options table), the first time I load the blog from the front-end, it shows correctly. However, when I look at the database, the options have been duplicated, and subsequent of the front-end for that blog show the default/2nd option. So the front-end loads the values, but after it loads them, it overwrites them with the default values.

  8. webmaestro
    Member
    Posted 15 years ago #

    UPDATE:

    I added the following around my add_option() calls, and moved them into what gets called on the front-end wp_head() (it no longer gets called in wp_admin_head() or whatever it's called):

    $exists = get_option("freedom_sitedomain");
    if($exists == "MyDefaultDomain.com") {
    	add_option('freedom_sitedomainsub', 'www.');
    	...
    }

    Loading the front-end no longer causes the double options but doesn't populate in the admin section. Also, I'm concerned this will decrease performance...

About this Topic

  • Started 15 years ago by webmaestro
  • Latest reply from webmaestro