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.

Check out the example demo. Try going to Tab number 2 and logging in as user: admin / password: demo123

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.

www.youtube.com/watch?v=Ort-IMmpo4s

Download

unpack_import_demo.tar.gz
dump_pack_demo.tar.gz

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.

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).

http://wordpress.org/extend/plugins/json-api/

A case for including child themes in the official WordPress theme directory
http://developdaly.com/wordpress/child-theme-inclusion-in-the-wordpress-directory/

Vote for Child Theme Inclusion in the WordPress Directory
http://wordpress.org/extend/ideas/topic.php?id=3264

1) Inflation: the price of goods and services rises and therefore what we can buy with 1000€ today is not the same as what we’ll be able to buy in a year.*

2) More importantly: even if the inflation was 0%, having 1000€ today is not the same since we can invest the money today and make.. well, more money. Otherwise we’ll have to wait a whole year before investing.

This becomes more obvious when considering more money and a larger span of time. 10.000€ will not have today’s value in 10 years.

I couldn’t find the name behind this principle of Economics but if you know tell us.

* assuming inflation is rising

• http://ejohn.org/apps/learn – Do you think you know JavaScript? Well, see if you understand these code challenges. This is a interactive tutorial, that walks you through different examples which you can even run on the same site.
• http://jsbin.com – perfect to use in conjunction with the previous link. What you don’t understand just copy+paste here and try it out! This is a JavaScript playground so to say.
• http://tinyurl.com/yqua25 – in this video Douglas Crockford from Yahoo! talks about “The JavaScript Programming Language”.

If you’re coming from Actionscript then this link is a good read as well.