Author: Nuno Morgadinho

Manage Multiple WordPress Installs

I was wondering how to admin several WordPress installs from the same interface and came out with this simple idea of having a tab container where each tab would give access to the WordPress admin panel.

This can be quite simple to develop by putting together a jQuery tab container and iframes.

This could be further extended in a way that one single login would authenticate across all the WordPress installations. In this way we can manage the several installs from one single interface with full flexibility, i.e. we have exactly the same options as if we open separate windows and log into the installations.

Authentication by POST/GET in WordPress

For a project I’m working on I needed to trigger an action in a remote WordPress installation. I had a bit of trouble understanding how I could authenticate myself against the remote site. Eventually I found a clean and nice way and I want to share it here with you. Of course, if you’re not into WordPress you can safely skip this post.

The Problem

Where I first stumbled was when from my plugin I tried to access directly the other plugin in the remote site. The code I was using for doing this was something like:


// create curl resource
$ch = curl_init();
// set url
curl_setopt($ch, CURLOPT_URL, "http://wordpress.mu/wp-admin/admin.php?page=myplugin");
//return the transfer as a string
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
// $output contains the output string
$output = curl_exec($ch);
// close curl resource to free up system resources
curl_close($ch);
// print the result of the whole request:
print "CONTENT = ".$output;

And this wouldn’t work because although I was authenticated in the remote site via the browser, the session that the curl request creates is not, and so this request results in us being redirected to the login page.

What to do?

Ideally we want to do a POST request that we execute before and that authenticates us. I searched around on how to do this but couldn’t find anything. What I found was one of the many third-party applications that allow talking to WordPress remotely. I then looked at how they work and how they authenticate themselves.

Instead of doing a POST request to the plugin page like before, they do a POST request to the site’s index.php. A plugin is registered to catch a particular POST request. Then you simple use the WordPress function user_pass_ok(), that authenticates the user against the database.

Here I demonstrate how to do this using a GET request, because its simpler, but the same thing would work with a POST request.

add_action('plugins_loaded', 'unpackimport_createblog', -1);
function unpackimport_createblog() {
if(isset($_GET['myplugin'])) {
if(user_pass_ok($_REQUEST['username'], $_REQUEST['password']))
echo 'Authentication successful';
}

And the client request:

curl_setopt($ch, CURLOPT_URL, "http://wordpress.mu/index.php?myplugin=true&username=test&password=testpass");

Screencast

I wanted to show a working example rather than just saying this works so I did this screencast. You can also download the plugins yourself and try them out.

Download

unpack_import_demo.tar.gz
dump_pack_demo.tar.gz

Illusion

Masters say this is all a big illusion, that life and everything around it is nothing more than an illusion, Maya. The first reaction when people hear about this is that it’s total crap. How can it be an illusion if I’m seeing it, if it is here happening in front of my eyes?

Think of a tooth, for example. If you curl your tongue and touch any of your tooth, it really feels like a nice polished surface. Nevertheless, if you zoom into it you’ll see it is actually made of tiny razorblades. It is not that what you see is not real. It’s just you’re probably not seeing it through the right lenses.

Changing the Default Blog in WordPress MU

WordPress MU is a platform that allows you to host and manage multiple WordPress installations. It is used to power WordPress.com, among other sites.

The basic of WordPress MU is that the user registers and upon the click of a button, a blog is generated for him, available to use immediately.

The default blog that is generated is the most basic thing you can get. It uses the default Kubrick theme, no plugins or widgets, and a bit of example content (a post, a page, a comment and some links).

I’m working on a WordPress MU project now and I had to change the default blog to something more elaborate. So I went and researched a bit what can be done and what is supported. Here’s what I’ve found.

There are a couple of MU plugins that allow you through an admin panel to edit some defaults (blog title, default theme, stuff like that). If you’re into that kind of thing see the New Blog Defaults plugin. But in fact what I wanted was something more along the lines of developing my default blog locally (in a local MU installation) and then deploy to the production site with minimum hassle.

I found another plugin called Blog Templates and with it you can create a template from a blog. This template will be saved in a different database table ‘wp_gp_templates’ and will contain posts, pages, links, post categories and some blog options. You can easily extend it by adding more options to be saved if you need to. You can then upload the template to the production server and it will be applied as a template to new blogs. Pretty cool.

exclude pages plugin

I had a plugin to exclude certain pages from the menu. This was a question of adding an extra option to be saved in the template. *

copying plugin settings

Information about what plugins are active is kept inside the options table and so it can be saved quite easily:

$newoptions[‘active_plugins’] = get_option(‘active_plugins’);

A problem with this is you still need to make sure all the plugins you had locally installed are on the server. Not a big deal but something to keep in mind.

copying widget settings

Widget settings are also kept inside the options table so it’s not a big deal to extend the plugin to also save them (you still need to work out which options to save though). Because normally widgets are registered from plugins you again need to make sure all the plugins you had locally are on the server.

theme

The theme name is saved in the template but you still need to manually make sure all the theme files are on the server, and if not, upload them.

post meta / custom fields

I extended the plugin to clone all of the meta items for a post. This seems to work quite well without any problems. I might work together with the plugin author to include this as an option in the plugin or maybe release the code here separately.

* A problem with this is that because the pages are excluded based on their ID, you need to be sure that the pages will be created with the same ID that is saved to the template (this is a problem if you have created pages and then deleted them because the IDs will not be the first ones).