Site-Wide Admin Bar for WPMU
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:
- 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.
- 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.
Tags: Admin Bar, administration, Site-Wide, WPMU9 comments so far (is that a lot?)
The Theme Styles Plug-n-Hack
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.
Tags: Admin, Theme, WordPress2 comments so far (is that a lot?)
WPMU Site-Wide Latest, With Gravatar
Download Here
The WPMU Site-Wide Latest plugin provides two widgets for your site. The first, labeled “Newest Post,” creates an 80-word teaser of the single most recently published blog post on any public blog across the entire site. The second, called “Recent Posts,” creates a list of the most recently updated blogs with their most recent posts, one post per blog. Both plugins provide a vehicle for those using the standard Gravatar plugin to obtain and display the Gravatar of the post author in each case.
The teaser widget takes the post title as the title of the widget, whereas the listing widget allows you to set your own title. Both allow you to ignore blogs, if you wish. The list widget also allows you to specify how many blogs you want to display and an offset. This is in case you use both together, that way the most recent comment is in the “Newest Post” widget and the next most recent begins the list in the “Recent Posts” widget.
The plugin also uses the WP-Cache, and both widgets allow you to set a time-out.
WP-Functions Used in This Plugin:
switch_to_blog()
restore_blog()
wp_cache_set()
wp_cache_get()
get_permalink()
Installation:
Unzip, upload (to either /mu-plugins or /plugins, your preference), activate and configure. Simple as that!
Tags: Site-Wide, Widgets, WordPress4 comments so far (is that a lot?)
WPMU: Sharing a Common Page List
If you’re looking to maintain one contiguous system across a bunch of MU sites, you’ve probably figured out that its tough to keep a consistent look and feel directly through the system without some tweakage. Creating your own custom theme and making sure it’s the only one available makes the blogs look similar, but unfortunately, without a way to navigate back to the main portions of the system, looks are as far as it goes.
There are, I’m sure, many different ways to go about integrating all the various blogs into one system. For myself, I chose to define a list of pages on the root blog, each of which contains “syndicated” content from other blogs. The idea was similar to a newspaper’s sections on world events, local news, etc. I created an inline list at the top of all my blogs, each using the same set of pages, thereby fusing the whole package together. You can look to the top of this blog post to see what I mean: all the links in the “nav bar” thing point back to the root blog.
To do this, I created a function inside of the functions.php file that checked the pages available on the root blog and displayed them as a list. I have included this function below for your perusal:
function main_pages($exclude, $target_blog) {
global $wpdb;
$prefix = explode('_', $wpdb->prefix);
$target_table = $prefix[0].'_'.$target_blog.'_posts';
$exclude_list = ' AND `ID` != ';
$exclude_list .= implode(' AND `ID` != ', explode(',', $exclude));
$query = $wpdb->get_results("SELECT * FROM $target_table WHERE `post_type` LIKE 'page' $exclude_list AND `post_status` LIKE 'publish' ORDER BY `menu_order` ASC", ARRAY_A);
$output = '<ul>';
foreach($query as $page) {
$output .= '<li><a href="'.$page['guid'].'">'.$page['post_title'].'</a></li>';
}
$output .= '</ul>';
echo($output);
}
As you can see, the function takes two variables, the $target_blog and a comma-separated string of excluded pages called $exclude. Strictly speaking, it wasn’t necessary to include the $target_blog variable, but on the off chance that I might want/need to move things around, I included it.
One process which might be of interest to those of you new to WPMU is that of splitting up the prefix and appending a new blog ID. One of the curiously-difficult things about WPMU is querying information from across blogs: because $wpdb is set with one specific blog’s information, querying info from other blogs requires some jostling of the code to get the query to work right. My solution above is not the most elegant option, but it is effective.
I have toyed with the idea of creating a new database object for use on the website, naming it something along the lines of $pivot or something, but I’ve not yet had a chance to try it. If you were to do such a thing, I’m not sure what if any effect it might have on the way the system works. It may also be that it makes more sense to extend the current class than to just use it as-is.
When I know for sure, I’ll report back!
2 comments so far (is that a lot?)
Simple Invitation-Only Registration for WPMU
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 yourblog.com/notablog or notablog.yourblog.com, 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 ) );
}
die();
}
if( $current_blog == false || $current_site == false )
is_installed();
}
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:
http://myblogsite.com/yournewblog?session=871dc980ec35a6c4468c3d091fe58d51
Or, if you use virtual subdomains, you’d send something like this:
Hey! Come blog with me at:
http://yournewblog.myblogsite.com?session=871dc980ec35a6c4468c3d091fe58d51
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:
<html>
<head><title>Encryptor</title></head>
<?php
if(!isset($_GET['keyword'])) {
?>
<form>
<label for="keyword"><input type="text" name="keyword">
<input type="submit"><input type="reset">
</form>
<?php } else {
$md5 = md5($_GET['keyword']);
?>
Your MD5 is <?php echo($md5) ?>
<?php } ?>
</html>
4 comments so far (is that a lot?)
