Multiblogging Terminology For Dummies
Multi-blogs, or as I prefer to call them, blog farms, are not so widely spread that a common terminology exists. And where the words are missing, communication is difficult and prone to misunderstandings, and unilateral communication (i.e. writing) even more so. Here are the terms and concepts I found helpful when thinking about and developing in a multi-blog context, and which I intend to refer to in future posts on this topic.
Here are some basic terms first that serve as foundation to multi-blog-related terms:
A blog consists of two major parts, the blog files, and the blog database tables, or blog tables for short.
From the outside, a blog is accessed via the blog URL. The server maps the blog URL is mapped onto a blog file system path, where the blog files reside.
The blog files consist of blog code files and static files.
While a static file is served as-is by the server, a blog code file is executed to render the final output. In the context of WordPress, blog code files are PHP files. Examples of static files are CSS style sheets, JavaScript files, images or videos.
The blog stores data that is regularly modified by the user in the blog tables, but for example CSS data, which is modified at least once when adjusting the blog to your needs, is stored in static files. Hence some of the static files are really blog data files.
Many of you have been probably quite familiar with the above concepts. Now for the more specific ones (I borrowed many from the Wiki world):
The triplet (blog files, blog tables, blog URL) is called a blog instance. Changing any of the three yields a new blog instance. Standard WordPress is capable of running only one blog instance. Enhancement technologies like WPMU and Virtual Multiblog enable running many blog instances.
Commonly, a blog instance is what is perceived as a website, so the terms website or site could be viewed as synonyms for blog instance.
A blog farm is a collection of blog instances that share their blog files, but not their blog tables or their blog URL.1
The major benefit of sharing blog files is sharing code: You only need to maintain one code base.
The major drawback of sharing blog files is the inability to have individual blog data files per blog instance.
That’s all for now. I will include more terms and concepts here as the need arises.
- In theory, blog instances may share some blog tables too, but I don’t know of a WordPress-related technology that supports this. This is because WordPress currently does not provide a good foundation on top of which such a feature could be implemented. Some other CMS’es, like Drupal, do support this. [↩]
- 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
EDIT: Well, I’m reading the next post in the Hackadelic series, so, I kind of get what you’re saying now, about having 2 .htaccess etc.
I guess my experience has been that most plugins write to a Database table (such as saving the options for the plugin), so you get a fresh set of options on each blog instance — all with 1 install of the plugin.
But as you say in the next post, it’s true that plugins which write to a hard-coded file location would persist with the same across all the blog instances (if that plugin is activated).
Can you double-check that last sentence,
I’m not sure you defined blog data files? You defined blog code files, and blog database tables. The conclusion was confusing. What is the major drawback of a blog farm?
I understand you can’t have different (what I call) “codebase”, being WordPress itself. But you can have different themes per blog instance, therefore different PHP, therefore different blog files (blog code files & static files). So I haven’t figured out what the drawback is. Is it that you can’t have WP and Drupal as choices in a blog farm? OK.
Dgold, it is defined, sort of: Look up “Hence some of the static files are really blog data files.”
Example: MyCSS stores it’s styles in a file located in it’s installation directory. Naturally, when you share a single installation across blog instance, including all plugin files, you share that file, too, which is not what you want. That’s the major drawback.