YD Network-wide Options

This WordPress 3.0 multisite and WPMU plugin automatically replicates any plugin option network-wide in WordPress 3.0 multisite, or site-wide in WPMU.

Description

Automatically replicate any plugin settings network-wide

Centralized management of your site-wide deployed plugins

Turn any standalone WordPress plugin into a WordPress multisite plugin

This WordPress MU plugin installs a new option page where you can choose which plugin options you want to replicate network-wide to all your children sites.
Any change to those options on the mother site admin pages can be copied to all the sub-sites at will, either automatically over time, as a one-shot process, and/or when new blogs are added to the network.

Your main blog can thus serve as a new blog template.

The plugin has its own admin options page.

It is fully internationalized.

Base package includes .pot file for translation of the interface, and English, French, Dutch and German versions.

Active support

Drop me a line on this page’s comments to report bugs, ask for a specific feature or improvement, or just tell me how you’re using the plugin.

Funding Credits

Original development of this plugin has been paid for by Wellcom.fr. Please visit their site!

Additional developments have been paid for by Bossinternetmarketing.com. Please visit their site!

Translation

Dutch translation by Rene

German translation by Rian

If you want to contribute to a translation of this plugin, please drop me a line by e-mail or leave a comment at the bottom of this page.

You will get credit for your translation in the plugin file and this documentation, as well as a link on this page and on my developers’ blog.

Installation

Unzip yd-wpmu-sitewide-options.zip
Upload the `yd-wpmu-sitewide-options` directory and all its contents into the `/wp-content/plugins/` directory of your main site
Activate the plugin through the ‘Plugins’ menu in WordPress
Use the option admin page to select which plugin options to make network-wide.
Change or reload your plugin’s option to propagate them sitewide.
…et voilà.

La version française de cette page permettant de poser des questions en français est ici.

Par : Yann Dubois

306 Réponses à “ YD Network-wide Options ”

# 1 Mac_Boy dit :
le 23 April 2010 à 23:09 h
This is awesome, terrific! Thank you!
# 2 Y.Dubois dit :
le 24 April 2010 à 1:18 h
Hey, if you liked it, please rate it! Go to wordpress.org/extend/plugins/yd-wpmu-sitewide-options/ , log-in an give me as many stars as you like. That won’t cost you a thing. On the other hand, if you want it to cost you something, just click on the “Donate” button at your right, and get ready for a few more terrific plugins coming your way 😉
# 3 Stuart L dit :
le 27 April 2010 à 3:50 h
This is a super plugin. I think my server (greengrants.ca) does not like it too much. I use the atahualpa 3.4.6 Theme which has about 100 separate options. At first, I checked about 10 options at a time and it kept updating my other blogs (I only have 6 wpmu blogs on this test install). It worked really good. Now I try to check one more option to update a new blog and it reverts to the “General Settings” page with no update to the new option I checked on the YD panel.

Maybe you can comment your thoughts on this?

Thanks,

Stuart
# 4 Stuart L dit :
le 27 April 2010 à 3:51 h
oops, I mean keepgreengrants.ca (mistake on post above)
# 5 Y.Dubois dit :
le 27 April 2010 à 10:42 h
@Stuart L
The latest version of the plugin has a checkbox at the end of the options list that reads “debug”. Please check that to get some more hints as to what goes wrong.
My thoughts on this is that you’re reaching some limit as of the number of option changes your configuration can deal with before reaching some max execution delay or database timeout.
The way the plugin works (as you will see in the debug info), you have to multiply the number of blogs you have with the number of sitewide options you select. If you select a few dozen options times 6 blogs, you quickly reach the few hundred figures.
The way WPMU is built, each option change requires one or two database queries. That can be a problem when you try to cram a hundred or more database updates in one http transaction.
A client of mine has the same kind of problem on a configuration where we want to replicate just 3 options over 100 wpmu blogs. We’re working on resolving that issue.
# 6 Y.Dubois dit :
le 17 May 2010 à 18:27 h
@All:
Version 0.2.0 is just out, with a few bugfixes. It now works on sites with many blogs (fixed memory leak), and option updating is also fixed.
# 7 Dean dit :
le 18 May 2010 à 4:50 h
Hi. I discovered this plugin the other day and it was working fantastically.

I just reinstalled WPMU on my website and when I activated your plugin I noticed that there was a new version.

Now, I can’t get any of the setting from the main blog copies across to the sub blog I created. I’m looking to see where I’ve gone wrong but can’t see anything at the moment.

Any ideas?
# 8 Dean dit :
le 18 May 2010 à 5:38 h
Actually, I’ve thought of something that is different with the installations that may cause a difference. When I first installed your plugin it was on a different domain that was the root domain on my host. Mleno.com is an addon domain on the same host.

Would this make a difference?

Thanks
# 9 Y.Dubois dit :
le 18 May 2010 à 10:21 h
@Dean:
No, the domain makes no difference whatsoever.
You could get an insight into what’s going wrong by checking the “Show debug messages:” checkbox at the very end of the options list, and then pressing “Update widget options”. (which should, by the way, rather read “update plugin options”).
This will display a verbose line-by-line status of the settings replication on each blog.
If you get no luck with the new version of the plugin, you can always revert to the previous version, but the new version is far more reliable once you have more than a few blogs to replicate to.
# 10 Dean dit :
le 19 May 2010 à 7:45 h
Thanks for your reply.

Sorry, but where will I see the debug messages.

I checked my error log and noticed the following after clicking “update widget options”

Does this mean anything to you?

[19-May-2010 05:42:20] WordPress database error Table ‘nzwebho1_mm.wp_5_croer_posts’ doesn’t exist for query SELECT SQL_CALC_FOUND_ROWS wp_5_posts.* , wp_5_croer_posts.post_rank IS NULL AS isnull FROM wp_5_posts LEFT JOIN wp_5_croer_posts ON (wp_5_posts.ID = wp_5_croer_posts.post_id AND wp_5_croer_posts.cat_id = 0) WHERE 1=1 AND wp_5_posts.post_type = ‘post’ AND (wp_5_posts.post_status = ‘publish’ OR wp_5_posts.post_status = ‘private’) ORDER BY isnull ASC, wp_5_croer_posts.post_rank ASC, wp_5_posts.post_date DESC LIMIT 0, 10 made by require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts
# 11 Y.Dubois dit :
le 19 May 2010 à 10:04 h
The error means your database is missing some tables so this is a pretty serious issue, but it has nothing to do with the use of my plugin, which does no direct access to the database. Your WPMU installation is broken, which may explain why the plugin cannot do its work.

If you check the “Show debug messages:” checkbox and then press “Update widget options” right away as I told you before, the debug messages will show up on the top of the next displayed page on a yellow background.
# 12 Dean dit :
le 19 May 2010 à 10:11 h
Ok, I ticked the debug box and got the following:

Action: I should now Update widget options.

1 blogs to update.
Widget options are updated
# 13 Y.Dubois dit :
le 19 May 2010 à 10:15 h
How many blogs do you have on your WP MU? My plugin sees only one, so if you have more, the issue is that the missing database table prevents it to account for all your blogs. If you do have only one blog then you have no need for this plugin in the first place 😉
# 14 Dean dit :
le 19 May 2010 à 10:21 h
I have only one at the moment. Its just a test blog. There will be a lot more in the future
# 15 Y.Dubois dit :
le 19 May 2010 à 10:28 h
@Dean:
The plugin needs at least 2 blogs to operate: one “master” / “root” site from which to copy the settings from, and one or more “child” sub-blogs to which the settings are to be copied. As long as you do not have at least 2 active blogs, it won’t do anything, as the debug message indicates now. ie. There’s no point in replicating the options to the master blog itself.
Please activate a couple of child blogs if you want to test it in a meaningful condition.
# 16 Dean dit :
le 19 May 2010 à 10:38 h
That’s better. Thanks very much.

Dean
# 17 Y.Dubois dit :
le 19 May 2010 à 15:40 h
@Dean:
In fact it seems that you need at least 2 public child blogs for the plugin to work right now. This is in someway a bug. I will fix this in the next release so that a single child-blog is sufficient (in addition to the main/master blog), and the so that the child-blogs do not have to be “public” to allow options replication. Right now it’s a bit too restrictive. Thank you for pointing me to this problem.
# 18 Dean dit :
le 20 May 2010 à 7:45 h
Thanks. Its a really useful plugin.
# 19 Y.Dubois dit :
le 27 May 2010 à 11:42 h
@All
Version 1.0.0 of the plugin was released on 2010-5-20. It includes a fix for the problem that @Dean has been reporting (you needed 2 child blogs for the plugin to work). It also includes new features:
– “Autospreading” of settings changes is now an option (can be enabled/disabled in the plugin’s settings)
– Can now auto-apply default options when new blog is created
– Can now disable overwriting of existing options when updating from the settings page: this way you can keep you manual settings on some child blogs while retaining the “sitewide default options” feature.
# 20 Alex Dominic dit :
le 14 June 2010 à 11:23 h
WPMU site, activate the plugin in the main blog, choose which widgets are activated for all blogs. Save settings but the changes do not occur. What? have instructions with photos of the screen? I hope to help!
# 21 Y.Dubois dit :
le 14 June 2010 à 11:47 h
@Alex Dominic
The WPMU Sitewide Options plugin will propagate the widget *options* to all your blogs, but it will not activate the widgets themselves on each blog. If you want to activate some widgets on all your blogs, you will probably still have to do it manually. Once the widget is activated, however, when you change some setting in the main blog it will be changed the same way in all your blogs. I don’t know if there is a way to activate the same widgets in all the blogs. Maybe you can do it by propagating some specific WP core options, I did not check into that.
# 22 GLerner dit :
le 22 June 2010 à 20:00 h
@Dean, I couldn’t get WP3.0 multi-site working (subdomain mode) when it was installed on an add-on domain. I moved my web site from public_html to an add-on domain, and installed WordPress 3 in public_html, and multi-site worked fine.

Did you get multi-site working for sub-domains, when installed in an add-on domain? When you type nonexistentsubdomain.mydomain.com do you get the page to create nonexistentsubdomain’s blog?

I have a blog post about how to install WordPress with existing web sites, lcblog.lernerconsult.com/2010-wordpress-3-multi-site-installation-existing-web-sites/
# 23 GLerner dit :
le 22 June 2010 à 21:38 h
I don’t know what most of the settings are, since the parameter names are not what is displayed on the Settings pages.

Is there a way to display the Plugin name, and the “human readable” name of the setting? Next to the computer parameter name?

I can’t tell which parameters I care about, or which ones I have changed from the plug-in default values. How about displaying the value of the main blog on this network?
# 24 Y.Dubois dit :
le 22 June 2010 à 23:50 h
@GLerner
Right now I don’t see a way to tie options to plugins, as there was historically no standard way of declaring, storing and managing plugin and widget settings. Since the new versions of WP, there is an official recommendation as how to implement plugin settings, and there are some registration hooks. It will however take some time for plugin developers to adopt these new standards (my own plugins don’t yet implement them). Older plugins will probably never comply, so there is no practical way to link plugins and their options, except for parsing each plugin’s code which is also impractical.

Furthermore, there is no such thing as an official “human readable” title for an option. Developers choose to name their option keys as they like, and can display whatever labels they want in the html of administration forms, without a formal way of tying field labels, field names and the database option keys themselves. So I’m sorry but it looks like a no-go.

Displaying the “main blog” setting would be easy for settings that are just plain text strings. However, once again, there is no standardized way of storing the setting values inside the option key. It could be strings, serialized arrays or objects, or anything else… many values can be stored in the same options key using an array or object.

If you have any suggestion as to how main blog settings values could be displayed, I am interested.
# 25 WordPress 3.0 Multi-Site Installation for Existing Web Sites | Lerner Consulting dit :
le 22 June 2010 à 23:09 h
[…] Carrington Theme by Crowd Favorite Highlighter powered by RoohIt (for WordPress) Featuring WPMU Sitewide Options plugin by YD […]
# 26 GLerner dit :
le 24 June 2010 à 1:46 h
In MySQL, wp3_site.id and wp3_sitemeta.site_id link, so you can display the meta_key with meta_value and the domain. That’s a start.
# 27 Y.Dubois dit :
le 24 June 2010 à 15:32 h
@GLerner:

meta_value can be any kind of serialized data, so I still don’t see how it could be displayed (a php var_dump() of the de-serialized value would work, but look ugly). Meta_key is already what’s displayed “as-is”.

The problem is not linking values to blogs (that’s trivial, as you mentioned), but rather linking meta_key to a specific plugin or admin setting to get some kind of meaningful “human readable” title, as you first suggested. And I still don’t see a simple solution.
# 28 matt dit :
le 24 June 2010 à 18:23 h
For some reason, i can’t seem to get the settings from my master blog to replicate to new blogs. I have checked the debug option and everything looks ok and i have checked the option to spread options to new blogs (the other 2 i have left unchecked).

Then when i set up a new blog none of the changes have occurred. I have tried re-activating each of the affected plugins sitewide (using the plugin commander) after having run YD WPMU Sitewide options and THEN making a new blog, but it didn’t seem to work. I’ve also deactivated YD WPMU on the network and then re-activating it after having made the changes.

I am working on YD WPMU through my main blog plugin interfact (not the wpmu interface) – do you know what the problem may be? I’ve got wpmu 3 installed
# 29 GLerner dit :
le 25 June 2010 à 7:49 h
Ugly, definitely. Maybe just the 1st nn characters of data, vertical bar separating fields, do the best you can do easily. It would at least give users some idea of what is in the data, some way of judging whether to set the info when creating a new blog, or whether to force updates, or “don’t bother, the default is fine” vs. leave the current settings for other blogs in the network.
# 30 GLerner dit :
le 25 June 2010 à 9:13 h
How about a different approach…

I’d probably care most about the variables that are set differently in the main blog than in the other blogs in the network. That might either indicate that this variable should be set differently for each blog (for example, the blog title, or Twitter account), or that I’d just made a change that I might want to copy to other blogs (for example, the permalink structure or time zone).

Perhaps show the 1st (or most recent?) 5 unique values found (if there are 200 blogs, don’t show 200 different values), as meta-key : subdomain/subfolder : value.

Like you said, no way to make it pretty, so just pick some sensible, easy way of displaying what you have access to, and go with that. Unless, of course, the add-on developer uses a standard way of communicating the property name and values.
# 31 Y.Dubois dit :
le 25 June 2010 à 17:56 h
@matt

In my experience it works if you activate YD WPMU Sitewide Options on your main (admin/first) blog, and if the plugins you are trying to spread the options from are activated network-wide. However I did not have a chance to test this on WP3.0 yet.

The action for spreading the options to the new blog is triggered when the blog is added. So YD WPMU Sitewide Options needs to be activated and configured before you create the new blog. Ans so should your “master” plugin settings. It cannot detect “new” blogs retroactively (they’re not new anymore), and it cannot propagate “unset” settings.

If your blog is already created if you check the other two checkboxes and re-save you plugins’ settings, they will be spread