Running Multiple Blogs in dotCMS
// August 5th, 2009 // 4 Comments » // Software, Tech, Web
Earlier today, a question was raised on Twitter about how one handles multiple blogs using dotCMS. Out of the box, dotCMS comes with a rather decent blogging system. And with some tweaking, that decent system can pretty much kick the ass of anything Wordpress driven any day of the week. That’s so long as you’re only running ONE blog. When you get into a position where you want to run more than one, things can get icky real fast. I want to share some of the reasons why, and what you can do to help solve the issues.
First, if you’re going to run multiple blogs, basically commit to abandoning most everything built in. The Starter Site blog is single purpose, and won’t scale how you want. This is sort of like the calendar that’s built into dotCMS. Good calendar, but you discover if you run 12 domains out of one dotCMS instance, they’re all tied to the single calendar. That’s a little rough. Once you’ve realized that issue, then you get to learn the other two reasons why multiuser blogs are hard: permissions and relationships. dotCMS currently lacks true user level permissions, so every blog you make will have to have a role associated to it (more on this later), and relationships are just too hard.
Let me start with relationships. Don’t use them. Period. It seems at face value to be the logical choice – make a blog structure, and relate posts to a blog. The problem is that while the instinct to use them makes sense, and they’re powerful and great tools for someone writing complex apps in dotCMS, the average grade blog user has no clue why they have to set them up, especially when they only use one blog. Ideally, dotCMS itself should handle it like this: If a structure requires a relationship, and via permission restrictions a user only has one piece of content to relate it to, it should just force that relationship by default (I suspect using the pre-content hook you could write a plugin to do that, but I don’t think it’d be easy). But it doesn’t, so users just get hit with a needless extra layer of work to get a blog post out. And besides, it’s just not needed for this. Leave relationships for more programatically useful tasks.
The solution to the relationship issue is categories. This is actually the crux of the entire multiuser issue. Categories are where you can segment blogs, and control their display. Like I mentioned, you’re going to have to create a role for each blog anyway. No way around it. The benefit of that is that you can run all the blog entries from one structure, and by controlling user access to categories, you control the blogs they post to. Each blog/role gets a category, like:
Blogs
+ My First Blog
+ Category 1
+ Category 2
+ Someone Else's Blog
+ Category 3
+ Category 87
Someone permissioned on “My First Blog” wouldn’t even see “Someone Else’s Blog” under the blog entry categories, and like magic, you’ve now segmented everything (additional advantage, one person could have roles for several blogs, and post to them all at the same time. This goes further and is true really for any kind of content that you need to do “access control” on. If you can tie it with category permissions, it’s a great, simple way to have several people working in one structure without getting into each other’s stuff). Now, when you build out the blog page, you build based on parent categories, rather than relationships. Combine all this with a login protected page on the front end using the Front End Content Submission plugin, and users never even need to log in to /c.
My suggestion is two structures, a blog entry content structure (which comes with the starter site, so you could just modify it), and a blog page widget structure. The widget would let you turn any page into a blog, by covering all the listing and displaying functionality, and allow you to define the category it should pull, and all that extra bloggy stuff. In ours, you can add Feedburner links, decide to show excerpts or full posts, control global commenting and rating settings, and even upload custom CSS (Cascading Style Sheets) files. If you have two dozen templates, the widget route would let you turn any of those templates into a blog. Here’s an example setup.
The smart thing to do in the widget code for the actual blog widget would be to just have it dotParse() an appropriate .vtl file for single view or an archive view (normal, date, category, etc). You could break that down as far as you’d want, but that’d keep the code segments less in the widget, and more in actual files.
Another area that dotCMS hurts in right out of the gates is commenting. The commenting system itself works, but the design is just bad. The markup isn’t good, and the layout is ugly. Luckily for you, you can override that. If you look at the code that drives the Comment macro, you’ll see that it calls in a template file from the file system. Also, if you look at that code, you’ll notice there’s a variable you can set that isn’t mentioned in the documentation: $commentSourceCode. This lets you control how your comments are marked up, which is a major deal. You can actually go in, copy that source file, edit it to meet your needs, and add some good semantic markup to both the form and the comments – making them both easier to manipulate and style. You could even integrate Gravatar support with the help of some Javascript MD5 code. Here’s an example of some massaged comments:
The form there is easier to read and use, and the comments look nicer and are easier to change with better XHTML markup. You can even go further into the HTML to do threaded commenting, just like in Wordpress. Combine that with some jQuery, and you can get real fancy. Alternative, you could just go outside with a commenting system like Disqus if you want more functionality, which you can embed in your blog post view template. There’s one gotcha to commenting I haven’t solved yet (at least, not without editing some field data in the database). If you delete comments, the comment count doesn’t change. So if you got 6 spam comments on a blog and deleted them all, the blog still says it has 6. The field the count is stored in isn’t user editable (as mentioned, you could change this in the database itself), and there’s no hook to subtract from it when comments are deleted. A workaround would be to count the size of the actual list from the comment relationship pull rather than trusting that field.
Everything’s not all roses and puppies and sunshine though. The way I do things, it scales better, but not great. This isn’t bad for a couple dozen blogs, but I still wouldn’t do it for hundreds until there’s a better way to attach permissions at the user level, and automate it. The major limit is that role issue, and I’m happy to entertain ideas as to how to get around it (ultimately, it could be done with a CMS (Content Management System) Owner role, which is in the system now, but not quite used “right” enough for this purpose). You could make pretty much make everything 100% dynamic, and from an infrastructure point of view, it’d just scale and scale and scale, so long as you’re willing to make a role manually each and every time.
Additionally, there’s no easy route into creating categories for the user. You can give them access in the back end to add their own, but it’s not as easy as in other systems. That’s not really a fault in dotCMS, since categories can do so much in the system, they just need to be in their own portlet. So, you either end up manually maintaining categories for them, forcing everyone to use a common set, or hope they’re savvy enough to use the category manager (keep in mind, if they have to log in to /c to edit categories and whatnot, it sort of kills the reason to do a front end page mentioned above). Your environment will pretty much entirely dictate your approach, so this could be a non-issue for you, or maybe not.
I’ll present our web office blog at PSU as an example of this sort of system in use, and then a test blog, using the same system in a different place. Different paths, different categories and RSS feeds, but using the same system. I’m also working with another client on a very similar implementation, but with some differences, such as how the actual blog pages are built out (for about 2 dozen blogs). Naturally, pulling this off takes a little time, and you’re going to need to be comfortable working with Velocity to pull it off, but I’ll tell you, in one page of Velocity I can duplicate almost all the core Wordpress display functionality (single, archive, category, tag, and author views), and have most of it done in under a day.
I’ll close by saying that if anyone has the skill and time to tackle the idea of doing a multiuser blog portlet plugin for the back end, I know it’d be well received in the community. This could help get around every single deficiency that exists now, though I think within the next two releases, we’ll see some of the modifications needed to really implement this well natively inside dotCMS.
More secure than passwords.
