Multiblog Data Files Sharing Problem

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

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.

An example:

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

Conclusion

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.

1. 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. [↩]

8 Comments

• 
  Freddy October 1, 2009 at 8:45 pm

  Great series. Are you planning to continue it? It seems to have ended about 4 months ago.

  VMB may save my life!
  • 
    Hackadelic October 2, 2009 at 11:29 am

    Freddy, I’ve intensified my usage of VMB. I have found some issues with VMB 2.6.1 and I helped Steven to fix them (2.6.2 is out). So I do think more on the topic is likely to come (if time permits that is).
• 
  Dgold August 2, 2009 at 2:02 pm

  Sounds like Caching plugins is the main area that needs to be solved? MyCSS, did you find that one to be a problem? I’m not sure about Google Sitemaps plugin, it miiight prefer to run on just one blog and not cover the blog farm?

  Other than that, from the ones I’ve tried, most plugins only write into the database, so it’s a fresh set of options for the plugin on each blog instance — with just the one install of the plugin. You choose blog-by-blog which ones to activate a plugin on.

  This is a great series of posts Hackadelic. I am a really big fan of Stephen’s Virtual Multiblog technique, and it is good to see this discussion emerging.
  • 
    Hackadelic August 2, 2009 at 9:33 pm

    The good news about MyCSS is that I’m half-way through implementing a multiblog-enabled version 🙂
• 
  Friso June 14, 2009 at 11:39 am

  Hi Zoran,

  Thanks. Just one step closer to implementing it. Cloning plugins shouldn’t be a problem: that is something you’d already have to do when driving several blogs or a blog farm.

  Two questions remain at this point:
  1. How can I determine which plugin’s will have an impact on .htaccess?
  2. Does cloning the plugins -and installing them off course- solve the .htaccess problem?

  Cheers,

  Friso.
  • 
    Hackadelic June 14, 2009 at 8:06 pm

    Hi Frisco,

    here are my two cents about cloning plugins: From the view point of a multiblog, cloning plugins (= duplicating code) is exactly what you don’t want to do. IMO two separate WP installations are less of a maintenance nightmare compared to all the plugins you install in addition. So if a plugin doesn’t work in multblog context, I’d rather try to find a replacement that does than cloning it.

    Cloning a plugin is actually just a workaround for when the plugin writes to a file in its own directory. It won’t resolve a situation when a plugin writes to a file that’s independent of the plugin installation directory. .htaccess is such a file.

    I can’t tell you any wisdom about how to determine if a plugin writes to .htaccess or not. The plugin documentation should make such a statement. If not, well… improvise. 😉

    Fortunately, almost no plugin writes to .htaccess, with one big exception: Caching plugins. They all do, AFAIK.

    If you really need a caching plugin, you’re probably better off with WPMU. (On the other hand, you need a caching plugin because your server is too slow for the traffic you get. But then, if you get that much traffic, you can probably afford a better server, or a better hosting plan with more band width.)
• 
  Friso June 12, 2009 at 10:22 am

  Hi Zoran,

  Thanks for the Sliding Notes update. Just what I was looking for!

  Apart from MyCSS, what kind of plugins are expected to conflict with VMB? I’m thinking of using VMB and your plugin.

  Friso.
  • 
    Hackadelic June 12, 2009 at 5:03 pm

    Hi Friso,

    mine all work with VMB. Apart from those mentioned in the post, I can’t think of any other plugins that don’t work with it (though I know there must be others which store data in files, like MyCSS).

    Anyway, it’s not usually a problem that the plugin won’t work (except for those who modify .htaccess), but that it won’t work in more than one blog simultaneously. A quick solution is to clone the plugin (by making a copy of its directory), and use one copy in blog1, and the other in blog2.

    BTW, that’s the way to go if you want to use the “same” theme in two blogs in the farm, but have to tweak it differently in each.