Multiple installations of Wordpress.
Part 3 is what your after. So skip ahead. I don't mind.
About a year ago I tried to get this multiple blog hosting site up and running. WPMU was still dreaming of a beta release and I was impatient.
Abstract:
This document outlines the ideas, not necessiarily the how-to, behind my own attempts to create a multiple installation of Wordpress.
Goal:
To create a multiple blog hosting site capable of several functions and features.
1. Automatic Account Creation
2. Automatic setup / installation of blog
3. Domain Resolution
4. Front Page / Index of main site
5. Site Control and Updates
6. Shared User Resources & Themes
7. Independent User Resources & Themes
Conclusion:
I hope something in here catches your imagination and helps develop WPMU further. I have finished my experimentation as the future of this project hinges on the shoulders of someone else. I have moved on to another project. One I believe offers more opportunity for me to better the world at large.
1. Automatic Account Creation
I created a little account creation page. It asked for the usual items, eg. username, password and email address. It verified that a valid username was given (ie. no spaces or invalid URL characters) and that the email was valid (cursory check for proper characters and form/structure of an email). I was recently working on a "captcha" and a floating / random URL for new member sign up page, but I don't have the time to finish that - or anything really.
2. File setup and installation
A new database was created using the username and (optional MD5 hashed) password provided. This data was presented to the usual WP setup pages via $_POST and the usual WP install continued. wp-config.php was written as usual and the entire process was a success.
Really.
One of the harder parts was figuring out how to go about a couple of things. One - where the heck was I going to install all these files? and how was I going to get Apache permission to do this?
I kept the base files in one folder and copied them over to another during install, making sure the wp-config.php file was written to the new folder.
One suggestion was to use some mod_php_root thing which would give root access to php. I didn't like that route for obvious reasons. So the only other thing to do was to drop those files in sub-directories and then figure out how to get (sub)domain name resolution.
3. Domain Resolution
Here's the fun part. Apache has a wonderful feature called Mass Dynamic Virtual Hosting. This allows you to redirect using wild cards. eg. /var/www/blogizen/%1/ where %1 is what comes before the domain (sub domain) which comes before the tld.
In my case I used the user name - which is why it was important to check for valid characters!
I really want to know if it's possible to use this to resolve to a WPMU sub directory install instead of using mod_rewrite.
<VirtualHost *>
ServerName *.domain.tld
ServerAlias *.domain.tld
VirtualDocumentRoot /var/www/blogs/%1/
<Directory /var/www/blogs/%1/>
Options FollowSymLinks
AllowOverride None
</Directory>
</VirtualHost>
THE BIG PROBLEM HERE!!
There is a big problem with Apache's MDVH - or more to the point - there is a BIG PROBLEM with how some hosts and registrars handle their domain forwarding and/or DNS. Some use frames and call the remote host. That doesn't work at all with MDVH for obvious reasons. So you have to be careful who you use.
ALSO you have to be able to access the Apache config files or otherwise get wildcards in your DNS. I'm sure there are other ways besides /sites-available/default.conf
So yes, this can be done and done without mod_rewrite or any PHP at all. Nice, simple, easy on the system resources.
4. Front Page / Index of main site
I edited the post.php file in Wordpress to "ping" the local user database everytime someone posted a new post. Then I modded Magpie RSS reader to fetch that list, then fetch the RSS feed from those blogs and display it.
It sucks. but it works. I was working on just plugging the timedate, url and stub of the post into the database from post.php. and cutting Magpie RSS out entirely. Actually I don't even know if it was post.php that I edited! My notes were lost in the move a couple of months back... insert bad words here, but I'm sure you get the idea.
Anyway, it works well enough, but it's a system resource hog. Not an important part of the concept really and it would have been faster if I had just done what I wanted from the beginning. Getting Magpie RSS to work properly was a PIA.
5. Site Control and Updates
I had been using some batch files to update the scripts
for $i in /users/*/wp
{ cp /wordpress/newversion /var/www/users/*/wp }
(where * = username)
that kind of thing. I don't even have a copy of that anymore and I know my BASH syntax is crap, but it was handy and you get the drift of it.
I was working on changing the default upgrade URL from the WP one to my own local one.
I had edited the Dashboard to show site wide news. I simply edited one of the RSS feeds that was already there to reflect the feed from the "development" blog. I see you did that as well.
6. Shared User Resources & Themes
Symlinks to a shared directory of themes was an awesome idea that really paid off and I hope it's something you'll take from this
I stored the themes in
/var/blogthemes/themename
and created symlinks to there from /blogs/username/wp-content/themes/
symlinks keep the permissions in the original folder. so I chowned them to www-data and chmoded them to 544 so users couldn't edit them at random - effectively editing their neighbours blog too! Wouldn't that be a fun way to spend some time online... he he he... anyway...
This works great, provided the themes didn't require any editing! Some do, and that's a pisser. I was working on moving those files to //themes.domain.com and putting a theme switcher on the blog there and yadda yadda yadda - never got that far. Wasn't a priority really.
By the way, the symlinks worked great for most plugins too.
7. Independent User Resources & Themes
Ah, here is one of those things that I was going to charge extra for. Providing users access to their files, uploading personal themes and checking/reading/responding to their email account - well, any linux admin worth their ~ is going to know how to do that.
Who am I to rain on their parade?
8. Conclusion
So there you have a brief outline of how I did what you did. It works, it's interesting and not at all in the direction you took.
Site wide access was going to be handled with sessions. Login redirects followed easily from that as did comment logging.
But as I learned how to do all of this, I was struck with another idea and now I'm off to pursue that instead. I think I stand a better chance of helping people, and a lot more of them with that idea than with this.
I hope you'll find something useful in all of this. I certainly did! WPMU has come a lot further than I got and you've taken it in one hell of a great direction. Sometimes it's refreshing to have a different perspective, even if you can't use any of it.
If you have any questions or require any code, write.
Strixy (aka mike at strixy dot com) 4th January, 2007
