The WordPress 3.0 betas are kicking around and for projects still in development, upgrading now will save you the trouble later after the site is in production. Upgrading Single Site WordPress installs to 3.0.x is as easy as ever, but now that WordPress µ has been rolled into the main WordPress code base it takes a bit more work to “cross-grade” to the new WordPress 3.0 Multi-Site features.

This is a rough guide to upgrading WordPress MU 2.9.x to WordPress 3.0 Multi-Site. That means that I’m largely pulling this from recent memory and may skip a step or state something inaccurately. Feel free to heckle correct me in the comments.

1. Get a copy of WordPress 3.0 via Subversion.
2. When I tried to reuse my MU-style wp-config.php (even after adding WP_ALLOW_MULTISITE) I got a number of strange errors, so I recommend starting a fresh wp-config.php based on the wp-config-sample.php file that comes with WP 3.0
3. Add this to your wp-config.php file to enable Multi-Site: define('WP_ALLOW_MULTISITE', true);
4. Copy over your DB Settings and the security SALT constant definitions. Double check these, I had to add another one called NONCE_SALT that I wasn’t in my original wp-config file. Don’t forget to upload your changes.
5. Remove the wp-content/blogs.php file. You’ll be prompted later if you don’t.
6. Now this is where it got tricky. In order to get WordPress to enable Multi-Site you have to kick off the process from WP-Admin > Tools > Network, but our table structure is all wrong since we were on WP-MU. Export your DB to a SQL file (Structure+Data), and find all of your wp_1_* tables (assuming your table prefix is wp_).
7. Run a search and replace operation and change wp_1_ to wp_ in your sql file. Remove everything else.
8. Then import the renamed tables and data back into your DB. You won’t have to remove or do anything to the original tables.
9. Now you need to do a little DB hacking. Find your user by ID in the wp_usermeta table, and find the entries that have an option name that starts with wp_1_*.
10. Add new keys using wp_* as the option names, and copy the values from their wp_1_* counterparts. This will ensure you have privileges on your own blog.
11. Log in to WP-Admin. You should be greeted with the familiar Database Upgrade Required dialog. You may or may not also be prompted to repair your database. If you are, run the repair operation and try the Upgrade again.
12. Once logged in, go to Tools > Network and activate your Multi-Site features. It should recognize that you have a network already, and prompt you to update your wp-config.php with additional constant definitions and to replace the WordPress rewrite rules in your .htaccess file.

After all that, you should be good to go. Remember that your mileage may vary and make good backups of everything before proceeding. If you know of an easier way to do this, let me know in the comments.

Before I get into this, let me offer up a bit of background on my own involvement with conferences and events of all shapes. I’ve attended multiple WordCamps, both as a speaker and a participant. I’ve also helped organize BarCampOrlando, was involved with the first DrupalCamp Florida, and attended a number of other BarCamps and unconferences all over the country. I even booked and promoted concerts in a past life.

Let’s just say I’ve got a bit more Event Planning experience than your average bear, and have half a clue about what goes into making a good event great.

Here’s what I took away from the recent guidelines and along the way I’ll offer up a few assumptions of what I think are the motivations behind them, and what my interpretation of the guidelines are. This is by no means exhaustive nor is it intended to address anyone’s concerns directly.

What Automattic, as shepherds of the WordPress project, is trying to do is protect the integrity of the WordCamp “trademark” and ensuring that attendees get a consistent experience no matter which WordCamp event they attend.

Insisting that the content of the conference be solely about WordPress ensures that folks get what they paid for.

Insisting that they are stand-alone events ensures conference goers a quality experience. I’ve been to WordCamp events that played second fiddle to a larger BarCamp conference, and frankly it felt tacked on and sucked more than a little.

Insisting that organizers, speakers and sponsors be aligned with the WordPress philosophy and respectful of the GPL ensures that the community comes first, and commercial interests a distant second.

Trust me, I speak at conferences to do one thing: Educate my audience. In the course of teaching them, undoubtedly someone talks to me after my session and wants to hire me. This is why I do it, and I make no bones about that fact, and the guidelines were not created to address this issue. My presentations are by no means sales pitches, but I find that there is no greater form of marketing for a developer than showing potential clients how my brain works and how deep my knowledge goes.

However, as you are probably aware, there is a long standing battle between Matt Mullenweg/Automattic/WordPress and various premium theme and plugin authors – most notably Thesis and diythemes, and their interpretation of whether or not themes and plugins should be considered derivative works of the project and therefore are required to be released under the same license. The official WordPress Foundation stance is that they are indeed derivative works, and I agree 100%. My plugins or themes can not be run in any stand alone fashion since they make extensive use of functions and APIs that are provided by the host system and are intended solely to modify the behavior of WordPress. I see this policy as just another aspect of the battle for the soul of the GPL as applied to WordPress (so to speak) and nothing more. Asking that these types of organizations not be sponsors or speakers or organizers is just an extension of this debate.

Take Microsoft for example, which has been thrown around as a strawman in this debate. The company produces proprietary and non-GPL products left and right and has a long history of anti-open source moves (FUD Campaigns, etc). However, their actions in the WP Community have been nothing but in line with the project’s philosophy and the GPL. They’ve released code, submitted patches, and are generally working with the WordPress community on many levels to ensure that WordPress works flawlessly on their server software, can utilize their database technology and that their cloud services can support one of the most sought after web publishing tools out there. They’re good community citizens, and the past sponsorship of WordCamp events (and I hope future events) shouldn’t be curtailed just because they make most of their money from proprietary software.

The actions of some other members of the community stand in stark contrast to those of Microsoft in a number of ways. They’ve been antagonistic to the point of being mean and still wrongly (in my opinion) insist that themes/plugins are not derivative works of WordPress and hence don’t have to abide by the GPL.

Compare this with the Shopp plugin for which I paid $300 for a developer’s license. What I really bought was ongoing support and upgrades and to support the project, and while you still can’t just download a copy with out paying, the code is still licensed under the GPL (implicitly and explicitly). This means that I can fork it or do whatever I want with the actual code, as is my right under the GPL. I wouldn’t, since that would be kind of a dick move and would harm a small independent developer’s ability to make money for his hard work, but there is nothing really stopping me other than common decency.

Same goes for community members, such as WooThemes, who charge for membership to a ‘club’ and for support and other goodies rather than the code itself. Many of their themes are even straight up free (as in beer and as in speech). This is one of the reasons why I think their menu manager code was eventually donated to the WordPress Core. They are a shining example of the kinds of actions a good community citizen makes.

The bottom line is that WordCamps are seen as official WordPress conferences and only share some of the DNA with the BarCamp unconferences that inspired the name, so its in their right to make some requests to ensure the integrity of the ‘brand’ the WordCamp name has come to represent. Don’t like the rules? Then don’t just call it a WordCamp.

Remember, this project (much like Linux) is run by a benevolent dictator with the community’s best interests in mind. It is, however, still a dictatorship. At least it’s the nice folks on the WordPress core team (not all of them Automattic employees mind you) doing the dictating and not this guy:

Richard Stallman - Open Source Ideologue

Welcome to the Innernette!

Download MU-Helpers Plugin

The first function, get_all_blog_posts, will return all the posts across all of the blogs on your site. It employs a quicksort algorithm to ensure that the list is in the order you specify, and works pretty darn fast, all things considered. The function signature looks like this:

get_all_blog_posts( $num_per_blog = 1, $orderby = 'date', $sort = 'post_date_gmt' )

You can specify the number of posts per blog, how they should be ordered in the original query, and how they should be sorted by the quicksort algorithm. The orderby param takes the same values as query_posts would. The sort param is the column name in the database you want to sort on.

The second function, get_all_blog_comments, queries for all of the comments on all of the blogs on your network. It employs the same quicksort algorithm to sort the returned list by whichever column you specify. The function signature looks like this:

get_all_blog_comments( $num_per_blog = 1, $orderby = 'comment_date_gmt', $sort = 'comment_date_gmt' )

You can specify the number of comments per blog, how they are ordered per blog and how the whole list is sorted. The orderby param takes the same values as get_comments. The sort param is the column name in the database you want to sort on.

This plugin has not been tested with the new WordPress 3.0 Multi-Site Network.

I plan on submitting a patch so that the original plugin just handles this out-of-the-box, but until its fixed, this plugin will fill the gap for you.

Download HTTPS Stats Fix Plugin

The following functions are overriden by this plugin:

• wp_notify_postauthor
• wp_notify_moderator
• wp_new_user_notification

Due to the way pluggable functions works, you can NOT have any other plugins trying to override these functions or they will clash. Some of these functions have actions/filters that you can use to further modify how they operate.

In time I plan to add more of these hooks to my versions of these functions. If you have any suggestions, please let me know in the comments.

What makes WordPress unique is that the platform itself is open sourced under the GNU General Public License v2. This license imposes itself on derivative works by insisting that they in turn be licensed under the GPLv2 if and when they are distributed to others. Generally, this poses no issues, and everyone releasing plugins and themes on the WordPress.org Extensions db has chosen to release their code under the GPL.

The Premium WordPress Theme and Plugin marketplace has largely adopted the GPLv2 for licensing their goods (at least the parts they are compelled to by the GPL, namely the PHP code). It should be noted that this doesn’t hinder their ability to sell their add-ons or to even limit access to the downloads by putting it behind a paywall and asking users to pay for access to it. The only limitation that is placed on the developer is that, underneath the GPL, you must release certain rights to the end user of the software. The rights given to users are the same the developer received with WordPress: the code can be forked, copied, modified and extended, provided that all derivative works are licensed under the GPL. The GPL was intended to be contagious and to protect the code by ensuring that it always remains free. In other words, it’s free to remain free.

This is in stark opposition to the MIT or BSD Licenses that generally state that you can use the source code for any purpose and with no impetus to release anything you make with the code under any license, much less the same one that they used. And if you think about it, this is real software freedom. And while no Open Source license is perfect, the GPLv2 especially has a number of gray areas, especially given that is couched in the technical language of binaries and source code – which are hard (but not impossible) to reconcile with interpreted scripting languages, such as PHP, Python and Ruby.

The recent debate swirling around the recent #thesiswp has caused me to examine my own relationship to the GPL, the WordPress community and the larger Open Source movement in general. Both sides of the debate have interesting arguments to make, and by and large I feel that the GPL, as interpreted by the core developers and contributors (the copyright holders), the WordPress Foundation (the trademark holders) and many others in the community, extends to Plugins and Themes.

Anyone who has done any serious WordPress development knows that themes and plugins are so intertwined with the WordPress core that saying that they don’t combine into a single unit at run time is laughable. You are constantly navigating between the Theme / functions.php, and the Plugin layers to get anything even moderately elaborate running on WordPress.

I should know. I work on K2, a free theme framework with over a half a million downloads, and have written 100s of plugins for myself and clients, and released a dozen of them. This is what makes WordPress such a great CMS to work with.

WordPress development requires the navigation and manipulation of numerous callback functions, function overrides, class extensions and the use of other PHP language constructs that all of the code turns into one hot mess. Have you ever debugged a typical WordPress request cycle? If you follow it all the way through, you’ll see it jump around between the Core, Theme, and Plugin layers and back again – and if you don’t step into the functions deep enough you won’t even see your plugins and theme in action – it just looks like all WordPress (yet your plugin and theme code will have run and contributed greatly to the final output of the page).

Which brings me to the matter of the GPL, and my own relationship to it. Given its flaws, I can say that my own, non-GPL incumbered, open source contributions will be released under the MIT License. Its short, to the point and strives more to be an open release of source code than a philosophical stance. This is a personal choice, and is one I came to have to talking with other developers (outside of our community) about the GPL, the further research I did in trying to understand both sides of the argument, and actually reading and rereading many of the different open source licenses to get a sense for how I interpreted what I read.

Don’t get me wrong, I think the GPL is fine, am grateful to the numerous software packages I love and use every day that are free to me because of the GPL, but when I want to make something truly free then one of the “non-Copyleft” licenses are just one of the better choices. All of my WordPress related contributions will continue to be released under the GPL license – by choice and by the wishes of the WordPress copyright holders (of which I am one).

As for #thesiswp, the debate will remain largely unsettled and unsettling to the WordPress community. Call it growing pains, call it mud slinging, call it anything you want. Even if the WordPress community stopped persuading “Anti-GPL” hold-outs to release under the GPL license, or if all of the hold-outs (most notably Chris Pearson creator of the Thesis theme) adopted the GPL on their own, nothing would change but their opinion of each other. And there in lies the paradox. They got chocolate in our GPL and we got GPL in their peanut butter.

And unlike some of the folks in this debate (and very much like others) I don’t feel that this particular Philosophical Reese Cup would be settled, nay! could be settled with a court case. A GPL battle would be a huge distraction for the community, and as I’ve stated previously, it would probably create a largely inefficient outcome for both parties – no matter who ‘wins’. Its unfortunate that there are clear GPL violations in the current Thesis codebase, since that changes the nature of any possible court case from being a test of the GPL to one of code “theft”, which begs the question: Can free code even be stolen?

And this is where my relationship to the GPL shifted. You see, the GPL builds upon copyright law and not contract law like End User License Agreements (EULAs) do. And even if you only take the GPL-inheritance definition at face value, you can see how this Copyleft license starts to resemble a EULA – in so far as they both pose some limitations. Obviously this comparison is a bit of a stretch given that there is ton of freedom afforded by the GPL – for both developer and user – and building your business on GPL code is a fine idea with a lot of perks, and when one of those perks is 20 Million+ users allowing limitations becomes part of the trade off.

I liken it to Apple’s Developer Agreement and the other great debate of our day, Apple v. Adobe. Does Apple, the platform creator/innovator, get to make up arbitrary rules and ask that all developers for their platforms play by those rules? Absolutely. And despite the drawbacks of their proprietary platform and the flaming bizzaro hoops you have to jump through to release on their platform, developers that are willing to play by the rules are making an absolute killing.

The WordPress marketplace for Premium Themes, Plugins, Services, Hosting, Consulting, and other add-on Services is growing every day and many companies, including the one owned by Mr. Pearson, are themselves making a killing. Most developers are willing to play by the rules of the GPL license, but since WordPress doesn’t control the distribution of paid add-ons, compliance has to be voluntary. If we give the corporate person Apple enough leeway to say: “Your agreement sucks, but I’ll comply in order to make cool stuff for people to buy” then why can’t we afford the same respect to the thousands of real people that are represented by the WordPress copyright?

Its seems to me to be easier to adopt the GPL and continue offering your products and services, than to publicly, and at many times antagonistically, defy the wishes of the WordPress copyright holders. That just seems like bad business with a side of disrespect.

Its a shame that the substance of this battle is so largely philosophical. Both sides are being asked to change their minds and give up their own personal principles to make each other happy, and that’s just not something humans are very good at doing.

P.S. – There are a number of great posts on both sides of the issues of this debate that I couldn’t be bothered linking to each and everyone of them inside of the post. Instead I offer you a collection of bookmarks I’ve been curating on this issue.

The GPL talk also spilled over into the Drupal Easy podcast, and tackles the issue from the Drupal community’s point of view (and also mentions my appearance on Our Yellow House). Checking that out is also worth your time.

P.S. – My thoughts on the GPL issue were not as formulated at the time of this recording as they are in this blog post I wrote a couple of days afterwards, so read that too if you’re interested in my current thinking on the GNU General Public License.


add_action('my_attachment_redirect', 'my_attachment_redirect');
function my_attachment_redirect()
{
global $posts;
header('Location: '.$posts[0]->guid);
}


Then just call the action we created as the only code in your image.php and attachment.php templates:

<?php do_action('my_attachment_redirect'); ?>

Now when users visit the permalink for the attachment, they will be redirected to the actual file path. The rest is handled by the browser. For instance, images should be displayed in the browser window and PDFs downloaded or displayed inline (depending on what normally happens for that user when they encounter a PDF link).