The penny has dropped, the vuvuzelas have sounded and the kitties have played themselves out. WordPress 3.0 has been officially released. Check out the official release post from Matt.

I’ve been watching the download counter whirl by.

This release marks the official end of separate WordPressMU development. The exisiting functionality is now a part of WordPress core and is know as a Network of Sites.

So, for existing MU users, you’ll see some terminology changes in the backend:
- Blogs are now Sites
- Site is now Network
- Site Admin is now Super Admin

If you’re using a plugin that has hard-coded references to the site admin menu areas, they will need to be updated. The wp-content/blogs.php file is deprecated. You will need to remove it and update your server rewrite rules to use wp-includes/ms-files.php instead. We’ll be writing an extensive tutorial for upgrading over the next few days.

I know a lot of you are super-cautious and do not upgrade right away anyway, to make sure all the kinks are out. Now that the MU functionality is in core WordPress, it has been tested and re-tested probably more than it has ever been.

What happens to us? Well, first off a little nap and some catching up on the piles of client work and things. This blog will remain, as many people will be running their current MU installs for a while. Plus, the archives are pretty darn useful.

Going forward, we will still be here – with a new look, a slightly different name and a small shift in focus to the new users. We’ll still intersperse with more advanced things, highlighting a few goodies that are now open to use, and more of the how-to’s you’re used to. Maybe even more often! I smell a relaunch in the air.

• January 21, 2010 — Testers, start your engines (6)
• June 18, 2010 — Upgrading from WPMU to WP 3.0 (39)
• January 14, 2010 — 2.9.1 released, last before merge (6)
• January 6, 2010 — Merge News (1)
• January 5, 2010 — The merge begins (22)

© andrea for WPMU Tutorials, 2010. | Permalink | 8 comments | Add to del.icio.us
Post tags: 3.0, development, new features, release, wordpress, wordpressmu, wpmu

Need real genuine helpful support? MU Support.

Feed enhanced by Better Feed from Ozh

Our buddy Pete went and wrote up a very detailed post on how to upgrade from WPMU to WordPress 3.0 if you are brave enough right now to try out the beta2. Pete steps through it manually, so be prepared for that. (and backup your site first).

These instructions will still be relevant for the final release. The only difference is when the release is final, you will get an upgrade notice.

Thanks, Pete! Writing that post was on my list.

(Did you get the part about backing up first?)

• April 12, 2010 — Disabling the Plugin/Theme editor 3.0 (11)
• December 3, 2009 — MU 2.9 beta (6)
• June 23, 2009 — WP-Devel plugin (1)
• June 18, 2010 — Upgrading from WPMU to WP 3.0 (32)
• June 17, 2010 — The age of Thelonious and WordPress 3.0 (7)

© andrea for WPMU Tutorials, 2010. | Permalink | 8 comments | Add to del.icio.us
Post tags: beta, development, plugin, test, upgrade

Need real genuine helpful support? MU Support.

Feed enhanced by Better Feed from Ozh

A local development environment is a collection of software and files on your local computer that replicates a server environment. There’s a number of reasons why doing web development in a local environment and then pushing it to a remove server is a good idea:

• Convenience: You don’t need an internet connection
• Speed: Because you’re not transferring files remotely, there’s no save or reload lag
• Power: You have total control over the environment, in a way you don’t on, eg, shared hosting
• Safety: You can set up as many parallel environments as you’d like on your local machine, and if you destroy one of them, you can wipe it out and replace it in just a few clicks

I just got a new computer and so have been going through the process of rebuildling my local dev environment. For the benefit of those just getting into web development, here’s how I set it up, with a bit of explanation. Keep in mind that I’m working with OS X 10.6, developing for WordPress; if you’re running a different operating system, or developing for a non-PHP based framework, your setup will differ from mine.

1. Create a /sites directory: To make navigation from the command line a bit easier, I like to keep all my development environments in first-level directory called sites. Open a Terminal window and type:

   mkdir /sites

2. Download and install MAMP: Strictly speaking, MAMP isn’t required on OSX, since the OS comes with Apache, MySQL, and PHP installed (enabled through System Preferences > Sharing > Web Sharing). But MAMP has a nice preferences interface, and comes with useful tools like PHPMyAdmin, so I use it. Get MAMP and install it.
3. Configure MAMP: Open MAMP and click the Preferences button.
   • Configure Start/Stop. I like to uncheck the “Stop servers when quitting MAMP” box, so that I don’t have to keep MAMP open all the time.
   • Switch the ports. You can use the port settings that MAMP comes preconfigured with, but I like to change it because it can make managing domain names a bit easier. Click “Set to default Apache and MySQL ports”. The downside of changing this setting is that each time you start up MAMP (for me, that’s every time I start the computer, which is once every week or so), you’ll need to type in your OSX administrator password. That’ll happen when you save your settings at the end of this step, too – don’t be alarmed.
   • Switch the Apache root directory. On the Apache tab, change the root directory to /sites.

   When you click on OK to save your preferences, you will probably be asked for your admin password. Your local environment is now up and running, and it’s time to configure it to handle WordPress.

4. Configure your hosts file: By default, you can reach your local installation in a browser by visiting http://localhost or http://127.0.0.1. The first option doesn’t work very well with WordPress (WPMU, at least), and the second one isn’t very attractive. We can set up a more attractive host name by editing the /etc/hosts. Open /etc/hosts, ideally at the command line with

   sudo nano /etc/hosts

   ‘sudo’ is important here, as you’ll need admin rights to change this file. Modify the line that says

   127.0.0.1		localhost

   so that it says

   127.0.0.1		localhost boone.is.awesome

   Now clearly you don’t have to use ‘boone.is.awesome’ (though you probably should, because I am awesome). You can use any combination of words you want, separated by periods, like a URL – ‘local.dev’, perhaps. Don’t use a real URL. Save the file (if you’re at the command line, hit Ctrl-X, and then Y when you’re prompted to save) and test your new hosts file by visiting http://boone.is.awesome (or whatever) in a browser window.

5. Create a database: In MAMP, click the “Open Start Page” button, which will open the MAMP start page in the browser. Click on the PHPMyAdmin link on the start page. PHPMyAdmin is a graphical interface for your MySQL database that you might find handy as you do development. Click the Databases tab, and create a new database – I’m calling mine ‘wp-trunk’. You may also want to choose a default text encoding: ‘utf8_general_ci’ works pretty well if you think you might be doing development in different character sets (Cyrillic, Arabic, etc).
6. Download WordPress: I like to get WP via SVN, which makes it easy to keep track of any core hacks I might make. Here are the Terminal commands to create an installation called ‘wp-trunk’:

   cd /sites
   mkdir wp-trunk
   svn co http://core.svn.wordpress.org/trunk wp-trunk/

   You’ll see a bunch of files being downloaded. In this example I’m downloading the trunk, or development, version of WP, rather than the stable version. If you’d like to get a specific version, say 2.9.2, use svn co http://core.svn.wordpress.org/tags/2.9.2 wp-trunk/ instead. (More on using svn with WordPress, from Mark Jaquith)



7. Install WordPress: In your browser, go to http://boone.is.awesome/wp-trunk (or the corresponding path on your machine). This should load the WordPress installer. If you’ve followed along with my instructions, the settings in this image ought to work for you. You’ll notice that I’m using the root MySQL account, with the default password, because it automatically has all privileges on all databases. You should obviously never do this on a database that is connected to the internet. I should also note here that I’m installing the beta of WP 3.0, but the same process will work for any version of WP, even WPMU. With MU, though, you may have some problems if you choose the subdomains option for secondary blogs.
8. That’s it! You should now be able to log into your installation at http://boone.is.awesome/wp-trunk/wp-admin. When I plan to use an installation of WP to develop for BuddyPress, I check out the trunk version of BP in a similar fashion to step 6:

   cd /sites/wp-trunk/wp-content/plugins
   mkdir buddypress
   svn co http://svn.buddypress.org/trunk buddypress/

Related posts:

1. Google Summer of Code, WordPress, and BuddyPress
2. TinyMCE in Buddypress
3. Upgrading from BuddyPress 1.0 to 1.1

The bulk of the merge has been done in WordPress core. At least with regards to moving over the files. Now the fun part begins: bug gardening, testing and tweaking.

Here’s what you can do to help not only the dev team and others, but also yourself:

- set up a local install of WPMU
- import some data, plugins & themes from your current setup
(in other words, create a working copy somewhere)

Now, upgrade it to the latest WordPress trunk. The zip is located at the bottom of this page. To manually upgrade, just overwrite the MU files with the files located in the zip.

When you find bugs, please file them over at the WordPress trac, and pick the term multisite in the component field dropdown, so the other devs know is it MU related. Some terminology is changing, so this refers to the multiple blog capabilities. Your login to file a ticket is the same as your forum username and password.

Did you get the part where I said to do this on a dev version and not a live site? Good.

• January 14, 2010 — 2.9.1 released, last before merge (6)
• January 6, 2010 — Merge News (1)
• January 5, 2010 — The merge begins (21)
• December 27, 2009 — Merge news and Buddypress awesomeness (7)
• December 9, 2009 — Twitter Digest (4)

© andrea for WPMU Tutorials, 2010. | Permalink | 6 comments | Add to del.icio.us
Post tags: development, merge, trac, trunk, wordpress, wordpressmu, wpmu

Need real genuine helpful support? MU Support.

Feed enhanced by Better Feed from Ozh

With news of the merge of the Wordpress & WordPressMU codebase becoming more widespread, one of the questions I get asked with increasing frequency is should someone start a new site based on MU or should they wait for the merge.

My answer? It depends.

Is it time-critical? Do you need it up and running sooner rather than later? Is it income-generating? I spoke to someone earlier this week who is building out their MU-based site now because as they so succinctly put it, “I’m not leaving 3 months income on the table.”

And that’s how long it will may take to be out in the wild. Can you afford to wait three months? Only you (or your client) can answer that.

Also, if you are planning a project based on Buddypress and were waiting for the merge so you could use it on single WordPress, I mentioned over a week ago that this improvement is already in the trunk of BP. It is tentatively slated for release at the end of January, so if that was what you were waiting for, I would start development on trunk now.

Other people I have spoken to expressed concern over being able to upgrade from WPMU to WP when 3.0 comes out. This is one of the major priorities for the devs, and I have found historically the devs were always quite good in making sure core code (and new changes) were upgradeable. They want your site to upgrade and succeed too.

EDIT: Although I said three months up above, the actual release date has yet to be determined. The length of time is an educated guesstimate, not a firm thing. It was stated for illustrative purposes for how long you may have to wait.

• January 21, 2010 — Testers, start your engines (6)
• January 14, 2010 — 2.9.1 released, last before merge (6)
• January 6, 2010 — Merge News (1)
• January 5, 2010 — The merge begins (21)
• December 27, 2009 — Merge news and Buddypress awesomeness (7)

© andrea for WPMU Tutorials, 2010. | Permalink | 7 comments | Add to del.icio.us
Post tags: client work, development, merge, new sites

Need real genuine helpful support? MU Support.

Feed enhanced by Better Feed from Ozh

WordPress has been out in the 2.9 version for a few days now, and Donncha has just checked in the 2.9 code into the MU trunk. You can find it here: WordPressMU trunk

Scroll down to the bottom of that page and there is a zip link. Do not put this on a production site yet, but please do try and test it somewhere. Maybe a development site, or a test site on a spare domain, or locally on your computer.

The more people who test it now, the less bugs we have to deal with after releases.

There are some useful changes coming through, and some are especially useful for MU sites. Like the video embed. You’ll be able to ditch the plugins to embed video for popular sites. Please read the official release post on the WordPress blog for an overview and highlights.

• January 7, 2010 — Should you use WPMU? (7)
• June 23, 2009 — WP-Devel plugin (1)

© andrea for WPMU Tutorials, 2009. | Permalink | 13 comments | Add to del.icio.us
Post tags: 2.9, code, development, testing, trac

Need real genuine helpful support? MU Support.

Feed enhanced by Better Feed from Ozh

At OpenEd09 I was part of a very necessary conversation. We were talking about different ways in which our respective universities use WordPress MU. The consensus was that in order for us to be truly successful we need to be sharing much more. Sharing our frameworks, sharing our plugins and sharing our hacks. Boone Gorges frames the conversation nicely here and talks about what is needed from developers. Enej and others responded by reviving the OLT Dev blog. However, Matthew Gold rightly said this:

But we need to build more lasting channels of communication soon, lest we miss some important connections

So here is my attempt to provide those connections:

WPMU For Education blog

The basic idea is an aggregation blog for “WPMU for education” developers. Jim Groom provided a blog from his WPMUEd domain so that a new channel, dev.wpmued could be created. I used the Add Link Widget with FeedWordPress to turn this blog into an aggregation of content from developers who are working on developing WPMU in education using the method that Jim and I came up with. I seeded it with a few of my often read WordPress MU in education blogs (myself, Jim, D’Arcy, Boone, OLT and CUNY Dev).

But we need more, much more. If you know of any other blogs that write on this subject, please add their feed to the site.  Here is the current master list of institutions that are using WordPress MU. If you have any connections to any of them help the community out by contacting them and asking them to share what they are doing. Also, before you add your feed remember to turn the number of posts up (if you have more than 10 feeds to contribute). If you use WordPress you can include a mutli-tag feed by going “your-url/tag/tag1,tag2,tag3/feed”.

This can be a powerful way to boost our combined development prowess as well as a fantastic demonstration of the power of WordPress to support a community.

the actual conversation happening (photo credit Michelle Lamberson)

Adding your feed is as simple as dropping the URL into the text box on the left sidebar. Add the password (wpmued) and you are done. I’ll be checking for new feeds periodically but you can give me a shout and I’ll activate it ASAP.

Future plans:

I plan to use Wiki Append to pull important content from the wordcamped wiki into pages (it would be done already but wiki-append is having some problems). I think the wiki can act as  a second channel of communication. I will post again as soon as all of that is set up. In the mean time, edit the wiki, give it some much needed love!

I’ve also been playing with a branding idea. A year ago I came up with the idea for the UBC BlogSquad of having badges for contributors. It has worked really well as it reminds everyone of the existence of the aggregated blog (including the blogger themselves). It also immediately identifies you as part of the community. Of course, these were all first and second year students and I am not sure if seasoned bloggers want to pollute their blog with badges. If you do, feel free to grab one below. If you don’t like the design feel free to take your own shot at it (icon design is definitely not my strong suit). If you think the idea is stupid and that something else would work better, let me know in the comments below.