For everyone who followed the talks at WordCampUK 2010 by David Coveney of Interconnect IT.
I will add my presentations here in a little bit.
For everyone who followed the talks at WordCampUK 2010 by David Coveney of Interconnect IT.
I will add my presentations here in a little bit.
WordPress 3.0 multisites lets you easily publish multiple sites, on multiple domains, within one installation. This is a time-saving option for those of us who need to manage multiple separate domains running WordPress, but it does take a little knowledge and file access to set up, and at the moment isn’t for anyone who doesn’t consider themselves technically proficient.
You will need to be able to modify your vhosts file in order to do this, but once done you will have a very flexible and powerful server.
This article is written for 3.0 alpha, as of the current build on 19th March 2010.
The instructions above are obviously given without any guarantee – use at your own risk, especially if converting your site from single site to multisites. If you have any feedback or better approaches then do let us know in the comments below.
Please Note, it’s been pointed out that I need to make it clear that this covers version 5.2, the developer release, of MySQL Workbench. The principles still apply to 5.1, but it’s a different process that I’ve not documented at all. Apologies for any confusion.
This is a slight departure from our usual posts as it’s not about WordPress. However, if you’re developing with WordPress on a Windows PC there’s a good chance you’re using XAMPP as your platform.
I always liked the MySQL Administrator and MySQL Query Browser tools, but these have recently been deprecated and will not be updated any more. Read more
If you’ve been involved in WordPress over the past few years you’ll have seen it change from being an excellent but limited blogging platform into something on which you can build much more complex websites. We ourselves have been involved in some pretty sophisticated uses of the system – for example, over at Telecoms.com which makes extensive use of various elements of WP functionality as well as having quite a lot of custom code bolted in. Read more
Migrating a WordPress site can be something of a scary challenge, but we do it a lot, and we’ve become used to it. There are many good reasons to move a site – for example, you might set one up in a subfolder, and decide to move WP to the root. Or perhaps you’ve built a site on localhost and now need to put it on a live server.
If you do it incorrectly, you stand to lose all your widget settings, some file links and so on. This wasn’t a problem with ‘classic WP’ years ago, but these days there are many many paths stored away in the database, in various forms, and catching them all can be somewhat tricky.
Here I show you the steps we take moving a localhost site to a live domain. We’re using WPMU which is running the BuddyPress plugin suite.
Here’s our site on our localhost. As you can see, it’s pretty basic, but everything’s there that needs to be there – we know all elements of the install works, and now we want to pop it onto a live server. In this lesson, we’re going to use FileZilla and ftp the files across from our local install.
On the left you can see we’ve navigated to our local filesystem for this install. On the right, we’re connected to the server. There are already files there, because we have an old install running. You should delete all the files and replace them with the new ones in this case, but if you are replacing a site do make sure you have a copy of everything. Merging sites is much harder than migrating – and way beyond the scope of this tutorial.
So – select and drag all the files from one side, to the other.
Our preferred tool for administering databases is mySQL Administrator. A free tool that really simplifies a lot of DB Admin tasks. Use this to take a backup of your database. You’ll need to create a new backup project.
1. Click Backup
2. Create New Project
3. Select the Schema you’ve been using
4. Click to move it across, selecting ALL tables (unless you have multiple installs in one database, in which case, just the tables for the install you’re interested in)
5. Give it a name
6. Save Project
7. Execute the Backup
You should now have a backup.
Because the server we’re using doesn’t allow connections on Port 3306, we’re going to use phpMyAdmin there. This is no problem at all, but if you were using mySQL administrator you could use the restore tools there. If you’re doing this kind of project you should really know how to use these tools anyway – I’m only explaining these steps for completeness sake and showing you a migration I’m doing myself that’s likely to be typical.
A database backup is done simply as a big set of SQL statements that you can run. If you’re migrating to a different database you’ll need to edit the CREATE and USE statement to tell it which database to use.
Be very careful with this database dump by the way – database dumps are a very easy way for hackers to get into your system and find out lots of information you’d rather not give away.
Now you need to Import the Database. We’re using phpMyAdmin for this. If you have any tables there already, it’s probably best to drop them. All of them. Like I say, if you’re merging you’re going to need more help than this guide can provide.
1. Click on the Import tab
2. Select your file (if it’s bigger than your sever’s upload limit then you’ll have to speak to your admin guys about how to do this.
3. Press the Go button!
Once the import has run successfully you should see a message saying something like "Import has been successfully finished, 95 queries executed." – and it can be an awful lot more than 95 queries! It can also take quite some time. If you need to handle large datasets it’s far easier to use the mySQL Administrator tools – phpMyAdmin can get clunky.
If you try to visit the new uploaded site at the moment you’ll get a Fatal Error because all sorts of things are confused.
You need to change the wp-config.php file.
Change 1, 2, and 3 to match your server’s database settings.
Change 4 to the appropriate path. Most installs are in the root directory, so that would mean $base = ‘/’;
Change 5 to the domain name in use.
Change 6 from ‘/buddypress.11/’ (or whatever your local path is) to the new path, like in 4, so in most cases that will be ‘/’ also.
You now need to run a search and replace on the database – including all incidences of code within serialised PHP strings. There is an excellent and free utility written by Interconnect IT, called the Safe Search and Replace Tool.
I can’t emphasise enough that it’s important to handle serialised PHP correctly. If you don’t, then settings will go missing, fields will get corrupted, and your site runs a severe chance of not working on the new location. It’s a pain, but it’s important.
So, download the program, place it in your blog’s root folder and then run it by visiting the appropriate URL.
If you’re getting confused at this point, perhaps you shouldn’t run the program. Just saying, because it can cause plenty of damage!
Simply visit http://www.example.com/searchreplacedb.php in your browser to fire off the script. This will run. If you experience a time-out, or too much output, you may need to go into the script and remove any echos that are slowing it down. I’ll probably comment this out in due course anyway, but for diagnostics purposes I’ve left it. Once run, you should see something like the above at the bottom. Even a very large search and replace should only take a few seconds.
Check that you can navigate your site in its new location.
You may have to modify .htaccess to fix paths, and you may need to check your uploads folder for media. But that’s it. All should be good.
If you’re using WordPress Single User, then that’s it. You’re all done!
But in this example, we’re running BuddyPress on WordPress MU, and that means one extra step. In phpMyAdmin you need to open up (1) wp_blogs, (2) click the browse tab, and (3) click the edit tab for each row. If you have a lot, you may wish to run another searchreplacedb.php against the database, looking for localhost.localdomain and buddypress.11 and swapping them appropriately.

This is a real-life burglar... still easier to identify than a hacker, sadly. Creative Commons Share-Alike Attribution Picture by Jofus.
There’s been a big fuss lately over the latest WordPress hacks that have targetted older versions of WordPress.
And in my view, they show the less pretty side of WordPress and some people in the community… but not all of them. The attitude has been a straight “upgrade your blog and you’ll be secure.”
Well, I have news for you. They’re wrong. Read more
Sometimes you’ve created a site with WordPress standard (not single user), but have had allow the site owners or users to have full admin access to it. You have plugin and theme dependencies, and if the site owner disables that plugin, you have problems.
For example, you’ve written a plugin that carries out a certain range of syndication functions for your client. If the client accidentally disables it he will lose money, and you will have a call-out, potentially an angry one, when he finds out. He wants admin access, but you know he’s dangerous with it.
So, since WordPress 2.8 you’ve had the facility to create a folder in wp-content called mu-plugins. It will work just like the mu-plugins folder in WordPress MU – as in, any plugin placed there, will run automatically. Activation code won’t fire off, but apart from that, so long as the plugin is correctly written, everything will work.
I’m not sure if this change is a part of allowing ‘must-use’ plugins support, as suggested in http://core.trac.wordpress.org/changeset/10737 or if it’s also planned as part of the move towards merging WP single user and WP-MU. Either way, it’s an incredibly useful tool for those of us who set up and configure sites for clients who are a little prone to fiddling.
Watch out for plugin updates – you can’t auto-update anything in mu-plugins, and you won’t receive any notifications. Be aware that you have to stay on top of this by yourself, just like in the old days!
Those who follow WordPress closely will understand that a vulnerability has been found that, whilst not being especially dangerous, could be very annoying for some – especially for high-profile blogs.
By using a specially crafted URL, it’s possible for an attacker to force a reset of the admin password. The attacker can’t know this admin password, it will be a random string, and this password will be e-mailed to the administrator of the blog. However, there’s no denying that this could be annoying to the administrator. More specifically, an administrator could be locked out of a block while some other exploits are tried, simply by resetting the password at short intervals.
So, it’s not the end of the world, but it’s an annoyance and in a few rare cases a potentially dangerous one.
To fix this vulnerability in older versions of WordPress, such as 2.7, you can manually change wp-login.php using the code shown in the Changeset on the WordPress Trac: http://core.trac.wordpress.org/changeset/11798 – ideally, you should upgrade to the just released WordPress 2.8.4 but if you have legacy reasons for staying with 2.7 (and many have, for example problems with widgets) then you may need to delay this.
This is the presentation given by David Coveney at WordCamp UK 2009 in Cardiff. It covers the advantages, problems and implementations of WordPress as used by the News & Media sectors.
If you need to view the slide notes (primarily for me, to be honest, but you may see some points that got cut during the presentation) you’ll have to visit the Slideshare site.
This is the presentation given by David Coveney at WordCamp UK 2009 in Cardiff. It covers the advantages, problems and opportunities of WordPress within the Enterprise space.
If you need to view the slide notes you’ll have to visit the Slideshare site. But the notes are really for me, so they’re a little messy.