Stephanie Booth’s Musings on a Multiblog WordPress

Climb to the Stars >> Musings on a Multiblog WordPress: Some interesting thoughts there and I could add some of my own but I have been waiting for *********’s proof of concept to surface. I personally believe that rather than trying to re-engineer an existing wordpress version, we should encourage authors to try to write for the codebase. Putting together a multiple weblog version of WordPress is not going to be simple by any means and if it HAS to be invented, it should be done one time and done right.

My thoughts about the implementation are slightly different from Stephanies’. I believe that a multiple weblog (considering the number of blogs hosted can rise to the thousands) should use caching. Which brings me back to staticize(sp?). I propose that every folder that is supposed to contain a portion of the multiple blog, has an index and the cache files generated for that blog. The index contains the staticize code that determins what to display and where, generates the information if it is not available or has been changed and stores the generated pages for the future. That takes care of the display (I agree this is a pretty high level overview, details will need to be hashed out)

For the control, we will need a similar staticize entity to produce the admin pages for the users. I suggest the addition of an extra identifier to every “entity” of a WP blog. So posts, users, categories, comments etc would all become unique. This could be watered down by having a post-to-blogid table and normalizing all the other information over the blogid. The wp-admin folder of each unique user would contain this blogid (in a config file) and the admin pages could be called from a central location with the blogid as the unique identifier. Everything posted/modified is done with the blogid determining the entities.

Now for the install. This could be as simple or as complicated as we would like it to be. Create a folder, give the web server write permissions to the folder and create a new user. The blog would then copy the required files (autogenerated of course, or just copied if they are support files) to the folder and ask the user to log in with the right credentials.

With potentially thousands of users using this blogging system at the same time and with the complexity of database/files that this would mean, a clear upgrade path would also be important. So, in this scenario, the upgrade would be performed by replacing the original files and running a script. The script (depending on the sheer number of users) could upgrade each user’s directory found in the post-to-blogid table. Heck, maybe even have a “blogusers” table to make thing simpler, which would also store the location of each individual blog.

Complexity of the database, complexity of the obejects and normalization of the tables are going to be really important in such an undertaking. So, if carefully planned and executed, installation of the product, addition of users and upgrades could become really really straightforward and simple.