Get it All

This plugin is deprecated and no longer maintained by the developer.

The new 2.7 version of WordPress MU is pretty awesome and I’m glad to have it running on both of my sites right now. There’s a lot 2.7 has to offer in terms of usability boosts, and while I balked at the redesign when it first started, I have to confess that there is much to love about the new layout.

However, one thing that’s been nagging me is the new Admin Bar functionality. It suffers from two things, in my opinion:

  1. It’s a blog by blog setting, not sitewide. This is fine for sites where you want savvy people to start blogging on your network. It’s less so for community based sites like mine, where the idea is a sort of news magazine site where consistency is key.
  2. Because plugins can add their own top-level menus, the Admin Bar can get a bit crowded and I’d like the option to add or subtract items from the list as I see fit. Again, it would be nice to have these settings happen globally rather than by site.

While I have not worked out the second problem just yet, I thought I’d go ahead and post my modified code to this site which allows site-wide settings rather than by-site. It also tucks the Admin Bar settings under the Admin section rather than Options.

There’s nothing magical here: all I did was change every occurrence of “get_option” and “update_option” to “get_site_option” and “update_site_option.” Then, I just modified the menu statement to look like the following:
// Register the settings page
function AddAdminMenu() {
add_submenu_page('wpmu-admin.php', __('WordPress Admin Bar', 'wordpress-admin-bar'), __('Admin Bar', 'wordpress-admin-bar'), 'read', 'wordpress-admin-bar', array(&$this, 'SettingsPage') );

Download the file here and replace the one currently sitting in /wp-includes/wordpress-admin-bar/

Meanwhile, I’m going to work on tweaking the plugin to make it more flexible for MU as I go.

Download Here

This one’s called a “Plug-n-Hack” because it relies on a lot more than just the basic plugin to work. It requires careful layout of your blog’s theme and editing the plugin in order to work correctly.

But for those of you who are running sites where you’d like to be able to keep the overall structure of individual blogs the same, while allowing your users to make some adjustments to the color scheme, this may be just the solution. With the Theme Styles Plug-n-Hack, you can create new color schemes as the administrator and offer them to your users to select from.

The plugin itself is very basic. All it does is add a new style element to the wp_head when the site loads. The elements within the style must be the same IDs and classes as you use regularly, because the new declarations will override your default settings for color. As such, it is imperative that before working with this plugin, you take stock of your current color scheme and determine how many colors you work with ordinarily and how many of those you’ll want to change. For example, my site uses five basic colors not counting the text, which I decided would always stay the same color.

Once you’ve determined what colors you’re going to change, you need to start creating a second style sheet (which will eventually replace the one in the plugin) that calls each of the affected elements and declares only those attributes which are related to color. By way of example, in my case:
#top_nav_1 {
background:#CD2626 none repeat scroll 0%;
border-bottom:1px solid #FFCC00;
border-top:1px solid #FFCC00;

Now that you have this list, you can begin to replace the RGB color codes with PHP substitutions. The plugin is currently setup to recognize five color variables:
$darkest, $dark, $medium, $light, $border
These variable names made sense to me, but feel free to edit the plugin to change them, if you prefer. Go ahead and start putting in your substitutions where they fit. In my case:
#top_nav_1 {
border-bottom: 1px solid <?php echo($borders); ?>;
border-top: 1px solid <?php echo($borders); ?>;
background:<?php echo($dark); ?>;

Now you can go ahead and insert that style list in place of the one in the plugin, starting at line 33 of the theme_styles.php file. Note also that at line 23, some default values are set. You’ll want to switch these around to your theme’s default colors! Defaults are also set for the admin area at line 208.

Once all this is done, you can upload the theme_styles.php file to your /plugins folder and test it out. By activating the plugin, you create two new menu items: one is for Site Admins only, which is located under the Site Admin tab and allows you to either create new styles or change the values of existing styles; the second allows users to select from the styles you’ve created and is located under the Presentation menu.

With a little bit of editing, I think you’ll find this a welcome addition to your website.

For those of you concerned with getting bombarded with new blogs built by strangers you don’t want on your network, but would still like to leave the registration process open to others, I’ve created a simple set of hacks that will allow this to happen. A caveat, however: you’ll need to have some little app on the same server that does MD5 encryption, so you know what you’re going to use as session phrases.

I say “session phrases” as opposed to “passwords,” because I would like to disabuse anyone reading this of the notion that this is any kind of real “security” per se. Rather, this is a simple way to keep nusance registrations at bay while still allowing users to register as subscribers to blogs, and also send invitations to those you’d actually like to have a blog. The basic MU wp-signup.php form doesn’t really distinguish and rather allows anyone to get a blog on your network. Yikes! This is the kind of thing you’d at least want the option to override.

So, I did this. First step is opening wp-signup.php and browsing to around line 369. That is the line that is commented // Main, and that’s where you’re going to begin your editing. Change it to look like this:
// Main
$passphrase = md5('numbnuts'); // Becomes 871dc980ec35a6c4468c3d091fe58d51, change this often!
if(!$_POST['stage']) {
if (isset($_GET['session'])) {
if ($_GET['session'] === $passphrase) {
$active_signup = 'all';
else {
$active_signup = 'none';
else {
$active_signup = 'user';
else { $active_signup = 'all'; }

As you can see, my code uses a simple md5, but only for the sake of having an invitation code which is not guessable. You could forgo this step if you’d like. It checks for the existence of a session phrase, and if none exists, it allows the user to sign up for a user ID, but not a blog. If the session phrase is there but does not match, it locks the user out of registration altogether, and if the session phrase matches, the user is allowed to create his blog or his username.

The $active_signup variable determines what level of registration is available to users. Strange that this is not a variable that can be set through Options, eh? But its not. Happily, though, this makes for a less complicated hack. You could of course get more creative with the code than I did, but I wanted to keep things simple.

Updated! I discovered an interesting additional bug to this hack, which is that the signup_user() function won’t redirect validation errors correctly without a little help. I would actually call this a minor bug in the code of MU, but what do I know?

Search for the phrase “<?php if( $active_signup == ‘blog’ ) { ?>” around line 249 or so, and change it to:

<?php if( $active_signup == 'blog' || $active_signup == 'all' ) { ?>

This will force the system to enforce the same rules on errors. Some tricky devil figured out that failing to enter the correct data on my site allowed them to create a blog after it spit back the error. Imagine my chagrin!

The only other thing I did on this file was to rewrite line 426 to read:

printf(__("<p><em>Sorry! The blog you were looking for, <strong>%s</strong> doesn't exist!</em></p>"), $newblog );

This is a small hack, just for the sake of not suggesting that there could be a blog in the future of someone you have no interest in giving a blog to! The whole line seems to be a throw-away line in the first place, if you ask me.

At this point, you’ve basically eliminated the possibility of someone creating a blog without your permission. If a person types in a URL like or, they’ll get the option to create a username, but that’s it. If they try to go to wp-signup.php and try to create a blog there, they’ll need a valid session phrase to do that.

But why stop there? What if you could also enforce some organization to your blog’s subdomains/subdirectories? Rather than just inviting guests to blog with you, what if you could gently suggest what that sub-whatever looked like? Well you can!

On line 103 of wpmu-settings.php, you’ll find the code that redirects incorrect URLs. Edit the file to look like the below code:
if( defined( "WP_INSTALLING" ) == false ) {
if( $current_site && $current_blog == null ) {
if($_GET['session']) {
header( "Location: http://{$current_site->domain}{$current_site->path}wp-signup.php?new=" . urlencode( $blogname )."&session=" . urlencode( $_GET['session'] ) );
else {
header( "Location: http://{$current_site->domain}{$current_site->path}wp-signup.php?new=" . urlencode( $blogname ) );
if( $current_blog == false || $current_site == false )

OK, now we’re cookin’! When you send out a link, you’ll send something that looks like this:

Hey! Come join my blog at:

Or, if you use virtual subdomains, you’d send something like this:
Hey! Come blog with me at:

Oh, and for those of you who’d like not to think more than you have to about writing that little MD5 encryption script, here’s the code for it:
if(!isset($_GET['keyword'])) {
<label for="keyword"><input type="text" name="keyword">
<input type="submit"><input type="reset">
<?php } else {
$md5 = md5($_GET['keyword']);
Your MD5 is <?php echo($md5) ?>
<?php } ?>