Get it All
Together

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.

OK, so I realize that the official stable version of WPMU is not out just yet.  But still and all, I’m running the latest beta on this site and it’s quite stable so far.  I’ve not seen so much as a single error yet.  Then again, the day is still young, so to speak.

Of course, this marks WPMU’s foray into the new admin layout and while it’s markedly different than the previous two itterations, its slowly revealing itself to be a real improvement to the system.  The last revamping was really just a reimagining of the same basic WP layout and maybe not quite bold enough to be a real usability improvement.  They rearranged some things and changed some font sizes, but ultimately it was the same top nav design.

Now that we’re into the left hand navigation style, I think it’s going to work.  My one complaint is that it would be better if we were able to move stuff around, either within the submenus or moving top-level stuff where we want it in the list.  I can’t tell you, for example, when the last time was that I used the “Links” for anything at all on this or any other site.

There’s a bunch of new features as well, including a quick post area on the Dashboard and the ability to reply to comments on the comment moderation screen.  Both of these things will be welcome additions to the site, especially my political site.  Having to constantly go to the front page, click the article and then reply has been a source of endless irritation in the old version of WP.  Jotting down quick notes to the world is more easily accomplished from the Dashboard while you’re working on other things.  That’s handy.

There is also a more intelligent “Publish” window to the right of the writing window on the Add New Post screen.  Now the buttons in this section more closely reflect the status of the article you’re working on, displaying “schedule,” if you’ve set it up as a post-dated post, or “update” instead of “save draft” if the article is already published.

What I’ve not yet had a chance to do is actually crawl through the changed code and figure out neat new stuff to do.  For example, it appears as though most of the menus are considerably more configurable than they’ve been in the past.  Adding new menu items to the Add Post screen should be much easier going forward. There are more options for site administrators in WPMU 2.7 as well, allowing you to set parameters like new blog defaults and such.

I’ll definitely report back as I discover things.

I’d been holding off on upgrading to WPMU version 1.5.1 because I was worried that the extent of the changes from 1.3 to the new 2.5 codebase might be a bit too much for the system without some serious recoding.  Turns out, I was about half right.  And when I did finally upgrade about a week ago, it was a comedy of errors that forced my hand.

Since I’m on a web host that limits the size of my database, it has ever been a concern that I would hit the cap on my main blog.  The Tan-Tan Noodles Flickr Plugin did just that to me, since it saves all the pictures you display with the plugin as binaries in the database.  Suddenly one day, I could not post to my site and plugins seemed to be magically turning themselves off.  I thought for sure that someone had hacked into my site.

So, I opted to upgrade, hoping any security holes in 1.3 might be closed in 1.5.1.  Crazy, but again, I was panicking with a fairly high-traffic site suddenly being in limbo.  Unfortunately, I didn’t figure out the db problem till long after I’d already overwritten my old 1.3 files.  After I did the upgrade I found that my templates weren’t loading correctly.  Why should that be?

It turns out, after a long time troubleshooting, that a couple mu-plugins I’d written to bring content from other blogs to the main blog had become unusable.  I figured this out because Donncha’s post describing some of the new changes mentioned that plugins using the switch_to_blog() method might have a problem with the new caching system.  That didn’t turn out to be the problem, but since some of my code was still using another method of snagging the info (literally, concatinating “wp_1_posts” and querying the db directly!), it was this method that was causing the problem.

So a warning to you plugin writers out there: stick to the WPMU API to the best of your abilities!  I’m not entirely sure why querying the db would have caused so much grief, but when I switched to the API, I had no problems.

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.

This plugin no longer supported by the developer.

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!

It was with much anticipation and a fair amount of trepidation that I awoke this morning, prepared to upgrade WordPress MU to the new 1.3 version. The new version brings MU in line with the WordPress 2.3.1 codebase, including its new and complex “taxonomy” structure, while also implementing a bunch of MU-specific upgrades. I’ve been looking forward to working with the tagging concepts for a while, now, but upgrading MU is not an easy or entirely clean process.

Because unlike WordPress, you can’t just overwrite files from the old version. Well, you can occasionally, but in this instance, because there are a number of plugin files eliminated and other changes, it’s not recommended. Besides which, if you’re running an MU site with a number of users, you’re likely to find that upgrading in such a way that leaves the website open for a time comes with some complications that are probably best left avoided.

So, I can faithfully report that, if you delete all files and begin the upgrade with a clean MU installation, the upgrade actually is quite painless. I’d wondered if switching to the new taxonomy tables would make things complicated, but it doesn’t. In fact, Donncha was even nice enough to include a plugin for converting Categories to Tags site-wide, if you so chose. This all makes me feel pretty good about switching over on my main website as well.

On the other hand, there is a slight complication to switching over there which I’ve not worked out yet: the newest MU-specific addition in this release is the option to modify registration availability. You can now specify if visitors can create blogs, user accounts, or neither and you can also set it to allow only registered users to create blogs (which I presume means that visitors cannot create user accounts, otherwise that would defeat the purpose, as I’ve discovered. More on that later). This is a great addition which was desperately needed, as was the ability to hide your wp-signup.php file from search engines, thereby reducing the effectiveness of certain kinds of spam/splog attacks.

However, I’ve been using a tweak I’d developed which allowed users following a key-encoded link to create both the username and blog while providing other users only with the option to create a user name. It was a scheme meant to at least avoid spam somewhat while allowing my approved users to create the blogs they needed. It’s not100%, but it keeps the tourist spammers at bay for the most part and saves me the trouble of having to either a) create blogs for users or b) provide an extra set of instructions for creating the blog after they’ve created a username.

Well now, with this new change, all that goes away. I haven’t had the chance to check out the files that go into making this whole thing work, but I suspect my hack will not be able to live along-side the current system. In any event, I’ve also realized that my plan – cunning though it might at first have seemed – did not take into account the fact that registered users could create all the blogs they wanted. So, all someone with the time and drive would have to do was create a username and then create blogs all they wanted. Someone actually did this, though I suspect in this case that it was unintentional.

I think I’d rather have the security than the ease of administration, speaking personally, but it’s prohibitive for users starting up on my system. What I might do is edit the wpmu-functions.php to include a link back to the wp-signup.php file in the user account registration email, but I’m not sure. It figures that, after almost a month wrangling people into blogging on my network, people start suddenly all getting around to setting up their blogs on the weekend that I want to make this upgrade. This is one of those things that’s not really possible to do in a few minutes before I go to bed, so weekends are pretty much the only near-convenient time frame to do such upgrading.

Oh, yeah! And I’ll also need to upgrade my templates to include the new tagging features as well. Joy!

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!

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>

Wired.com has a great article in it about the problems associated with what are the most popular social networking sites out there, Facebook and MySpace:

Slap in the Facebook: It’s Time for Social Networks to Open Up

Social networks like Facebook and MySpace are taking the web by storm because they make it easy to manage your personal data and keep in touch with people you know. But to get value out, you have to put something in — photos, contacts, appointments, lists of your interests and your blog musings.

Therein lies the rub. When entering data into Facebook, you’re sending it on a one-way trip. Want to show somebody a video or a picture you posted to your profile? Unless they also have an account, they can’t see it. Your pictures, videos and everything else is stranded in a walled garden, cut off from the rest of the web.

I use both services to promote my main website.  This is largely out of necessity, inasmuch as both services provide quick and easy ways to reach people in my target audience (young, liberal and living in Rochester, NY).  But the one-way communication that they present is only part of the problem.

With MySpace, it seems relatively inexperienced and unprepared techs put the site together without planning for the future.  When MySpace bloomed out of control, they started shutting down the ability to incorporate your own stuff because they can’t seem to control all the spam.  Rather than deal with spam directly, they restrict user’s ability to embed Flash, JavaScript or even a large swath of HTML into their own spaces.  Despite having made a play for musicians, comedians and politicians all to spend their time on MySpace and get the message out, MySpace’s engineers have done nothing whatsoever to help people using those services effectively manage their “friends.”

I mean, what is the point of inviting your entire 1000-person friends list to a concert in Buffalo if only twenty people on your list live in the Buffalo area?

My current experiments in WordPress MU land are directed at creating something social like MySpace, only social enough that you can do what you like with it.  I’m creating a site to allow users to blog on issues concerning Rochester, NY, each on their own private blogs, and then give them the option to rate other people’s blog articles to allow the most popular content to reach the top of the front page.  I’m also working on having “featured bloggers,” those being people of interest in the various content areas of the site that get their stuff featured throughout.

Many of the experiments happening on this site happen for the sake of the other.  Hopefully, if all goes well, people in Rochester will have something worth talking about and a model to be emulated elsewhere.

I’m wondering what XFN plugins are available for WordPress and what they do.  Perhaps with a little bit of thought, I might come up with one of my own. . . .

Technorati Tags: , , , , ,

Powered by ScribeFire.

OK, so I’ve been playing around with the postratings.php plugin that was supposedly for WordPress MU.  Like hell, it is.  I’m still jerking around to try and get this thing working, and so far, all I’ve managed is to make the bastard not bork my entire blog.  At least, so I think.

But of course, if you’re reading this, then I’ve definitely avoided a catastrophe before I went to sleep this evening.