In an earlier post in this series, I was absolutely exalted about the Virtual Multiblog technology, and sated that I could not think of any drawback. While my enthusiasm remains, with further insights I did discover a fundamental systemic shortcoming.
The problem is not related to Virtual Multiblog specifically, but it is a natural consequence of sharing blog files, which includes but is not limitted to blog code files. But before I continue, let me refer you to some basic terminology, Multiblogging Terminology For Dummies, as I will be using the terms defined therein.
In that article, I already mention that a major drawback of sharing all blog files is the inability to have instance-wise blog data files.
I am using the MyCSS plugin, that stores the CSS in a file called “my.css”, which resides in the MyCSS plugin directory. If I created another blog instance, accessed through, say, “more.hackadelic.com”, I would still have a single my.css file to cover both sites. If the two sites had different themes (which is almost certain), it may be impossible to accomplish CSS adjustments with a single, shared file, as some CSS clauses required by one site may collide with those required by the other.
A solution to the MyCSS problem would be to add an option to the plugin to make (at least) the CSS file name configurable. Because blog settings are stored in a blog table, different settings can be configured for each site.
Things are getting more critical with data files whose names cannot be freely chosen. Such a file is “.htaccess”. Caching plugins modify it to enable serving cached static files instead of re-generating them by a more time-consuming PHP code execution. However, these changes are mostly bound to the blog URL, and hence to the blog instance. Hence such plugins will constantly overwrite “.htaccess” with instructions valid for the blog instance they are invoked in, breaking all others.
But caching plugins also store other data files in the file system – the cached HTML files. If such a plugin is not specifically prepared for multi-blogging, it is likely to constantly overwrite the other sites’ caches each time it is invoked. I don’t want to imagine what is then displayed to a clueless random visitor of such a site.
Criteriea for Multiblog-Ready Plugins
In implementation terms, the requirement on plugins can be specified very easily:
No writing to hard-coded file system locations.
This means that the plugin must either store all of its data in the database, or if it has to write to the file system, it must provide a databased-stored setting to specify where to write to. It can be a single file, or, as would be appropriate for massive file system usage like with caching, a root directory. That way
Of course, this does not solve the “.htaccess problem”. You can’t configure where your “.htaccess” is, or how it is named, as it depends on Apache, not WordPress.
Is there a Solution to the .htaccess Problem?
I haven’t thought about this very intensively, but I don’t think so. Not at WordPress level. The contents of “.htaccess” are evaluated by Apache before any WordPress code is invoked. Consequently, whatever WordPress code would do about it, it would be too late.1
WordPress’ blog farming abilities are yet to mature. Though technologies exist that largely support blog farming, the issues are not so much on their side, but on the side of WordPress as a platform. In particular, it is missing a file system access API that would support “virtualized” access (an API that serves different “physical” locations for the same “logical” location) that extensions like Virtual Multiblog can hook into to supply their own virtualization conditions (depending on blog URL in that case). Once available, it would, of course, also require a disciplined plugin development approach that does not bypass that API.
- Big Changes To Hackadelic.com Ahead
- WPMU Blues
- WPMU is out, Virtual Multiblog is in
- This Blog Is Now Proudly Powered By Virtual MultiBlog
- Multiblogging Terminology For Dummies
- Multiblog Data Files Sharing Problem
- Chances are though that a clever combination of blog directory, symlink and some non-WordPress PHP code could do the trick, but I will certainly not be the one to implement it. [↩]