One of the growing trends in blogging is using a service to supply comment functionality, rather than using native comments. There are advantages and drawbacks to using an external system for comments, and each service provides both interesting features and potential workarounds for issues that are endemic to the idea.

The Concept

Comment services host your comment data on their site, but display the comments themselves on your site. This is usually accomplished by inserting a snippet of javascript into your blog's template that references the service, and tells it the unique id of the post that is being displayed.

Via that snippet, the service supplies all of the comments previously submitted to that post, a form for submitting new comments, and many potential optional controls that constitute some of the value-add of using the comment service.


There are without doubt some concrete advantages to using a service to manage a site's comments.

Comment services typically provide some degree of spam protection. Since your comments must all pas through the service's system for storage, the service will typically introduce spam-prevention into that workflow. The submitted comments are passed through a typically proprietary set of rules for determining if a comment is spam or ham, and the comment is added to the approved list of comments only if it passes those rules. This often obviates any additional spam prevention mechanism related to submitting comments.

One of the more powerful aspects of using a comment service is that they aggregate comments per user. For example, if you leave comments on both Alice and Bob's sites, and they both use the same comment service, you can see a list of all of those comments on your profile page on that service. This allows you to easily aggregate your own comments across the web and potentially re-publish that data even on your own site. You can also use this information to follow commenters on the web to other sites on which they comment. Typically, the comment service displays a link to a user's commenting profile within their standard output to a blog.

Comments services can also provide inline features on comments that are useful. For example, some services offer individual comment ratings so that visitors can vote comments up or down based on their value. Some services provide threaded comments, which might not be part of what the standard blogging package provides.

Comment services can provide easier methods to reply to comments that are submitted. For example, if you register with a comment service, it may be able to email you when you receive a new comment. Depending on the service's capabilities, you may be able to reply to that email and effectively add a reply to that comment on your blog.


Such advanced features aren't without their drawbacks. Many of the available services offer ways to compensate for these drawbacks. Check with each solution before assuming there isn't a way to mitigate the problem.

On some comment services your data is not portable. This problem is sometimes bi-directional. Some services will not import your existing comment content, so if you have a bulk of comments on your site already, you will lose them if you switch to a service. Some services offer no way of exporting comment data that they have accrued, so if you decide you want to revert to the native comment features of your blog software or switch to another service altogether, you may find that your comments are locked inside that service.

Comment services do not share aggregated comment data. If Alice's and Bob's blogs use different services to manage their comments, and you leave a comments on both of their blogs, you will not see comments from the other blog aggregated in your commenter profile. You will need to switch to the other service's profile to see comments left via that system. If half of your friends use one system, and half use the other, there is no single way to monitor all of the comments, defeating one of the major advantages of using a comment service.

Lack of sharing aggregate data is a serious problem, and there is no service that has overcome it. There is no proposed integration standard to make it work.

Using a comment service typically requires that your visitors enable javascript. This is likely not a requirement for your native blog comment system. Although all browsers come with javascript enabled by default and most people recognize that interaction with the web essentially requires javascript to be enabled, on the rare occasion that a visitor does not have javascript enabled, he will not have commenting capability via many of the comment services.

Available Services

This is not a comprehensive list of services, but a basic representation of the marketplace. There were no fewer than six vendors of comment services represented at Blog World Expo this year, and more have surfaced in the few weeks since then.


js-kit is slowly integrating itself into larger and larger players. CoComment, one of the original comment services, now uses js-kit. js-kit was also derived from the original Haloscan, a service geared to providing flexible commenting on sites that did not have commenting ability. One of js-kit's interesting features is providing YouTube video integration as part of commenting capabilities.


IntenseDebate was recently purchased for use within for comments, suddenly gaining marketshare in the millions of users. It's features include the basics of rating, threading, and replying to comments via email.

TypePad Connect

TypePad Connect was recently rolled out by Six Apart to enter the comment service marketplace. TypePad Connect provides similar features to the other services, and adds OpenID integration for user verification.


Disqus includes basic rating features and threading, as well as inline popup profiles on blogs in which it is embedded. Due to its early arrival on the scene and development explicitly as a comment service, Disqus enjoys a large market share.


SezWho is another service that offers basic commenting and rating features. SezWho provides an administrative interface that reveals the number of visitors their service is driving to your site by means of aggregated commenting.

This session intends to create a simple news site using Panels 2 and Nodequeue. The idea is that the news comes into the site in blogging fashion faster than a "river or news" style would be able to keep it effectively on the home page. Instead of that kind of display, the idea is to display new news in panel areas as only titles in major sections that lead you to an expanded display. To accomplish this, you can employ the Panels and Nodequeue modules.

Panels give you more control over varied content views, and give tyou the ability to style the content. They let each pane know about data on the page that appears elsewhere.

Nodequeue lets the editor control the publishing order of new nodes. The editor can also control the length of the content, and pairs the content with the taxonomy for organizing its display.

A "queue" is basically a line, like "when you stand in line". You can use this feature in the nodequeue to push things at the front of a queue off of the end so that you can cycle the newest nodes onto the page. This allows the node to manage itself instead of having to "unpublish" expired items to get them to disappear from display.

Assigning taxonomy terms to new nodes will allow them to appear in different queues, and therefore in different areas of the site. To do this, you need to adjust how to display you Drupal home page, because usually you have the page.tpl, and the main content of the page is just the main content. To get around this, you set the main content to be a set of panels.

As a result, you can choose to display a nodequeue in any particular panel using whatever criteria you want.

The basic idea of this session seems to be how to get over the difficulties of Drupal shops working together. The general consensus in the room is that most Drupal shops are 10-15 members. Working with other groups is not just about collaborating on a client project, but also collaborating with groups that are responsible for published modules.

One of the primary blocks for shops working together is communication between collaborators. By keeping the communication channels open, things like duplicated module work can be avoided. Keeping the plans open in spite of competitive differences that might otherwise prevent collaboration.

This can be accomplished by blogging what you're doing to an internal back-channel. Do research before you start coding, and document what you all need to do so that the scope of work for each person is clear.

Also, if you're working on a module that others might use, be sure that you publish a path to completion or a list of things you might do in the future so that others who use your work know the direction you're heading in.

Using the correct tools, like blogs, offer unexpected benefits to collaborative efforts. Traditional tools like CVS can also obviously allow you to collaborate better with other groups.

Maintaining modules that you develop in congress to prevent them from languishing in client projects is one way to benefit from collaborating with other Drupal shops. By maintaining the modules together, you could re-use those modules later in future projects.

In my first attended session at Druaplcon 2008, speaker Chad Phillips started out with the basics of Drupal features including forms and the idea of separating presentation from content with themes.

Obviously, if you're going to be developing in Drupal, you're going to want a place to do the coding. Setting up an AMP (Apache + MySQL + PHP) stack locally is a quick way to set up a development environment that can be modified without mangling your production site. Versions of AMP stacks are available or Windows, Mac, and Linux as WAMP, MAMP, and various basic linux installs. The usefulness of phpMyAdmin on the local site is not to be overlooked.

For coding, a programmer's editor is really required equipment. When choosing an editor, choose one with debugging support and one that lets you code closer to the machine, so that you can edit things directly on the server if need be.

Using code conventions is important because in makes code reading common across developers. Increases security because its more obvious where errors are if the code is organized correctly. Makes it possible to commit changes to core code.

Where to get Drupal help when you can't figure it out: One place is the site itself. Get support with specific common topics at /support and /handbook.

Drupal also has support via IRC. Use #drupal for general topics, #drupal-dev for discussing specific development topics, #drupal-support for questions starting with "How do I...?", and #drupal-themes for help in building themes.

The Drupal Dojo has screencast videos to provide training to users. Check out

Drupal's own API Module helps with code documentation and PHP documentation by creating references from the PHPDoc comments in the code. This is an interesting module in deference to PHPDocumentor, which pulls the same kind of information, but this integrates it into actual Drupal output. Using this module locally allows you to develop locally without requiring access to the internet, so you can develop on a plane and still access the API documentation. Running the API module with locally installed modules will also bring in all of the documentation from those modules, which you normally aren't able to get from the's own public API reference.

The Devel module is a helpful development module that allows you to completely clear the Drupal cache on demand. It can present to you a list of variables in the variables table, and let you change the value of those variables. It can capture emails that Drupal tries to send, and store them in the log without sending them, which is really useful if you've got a local site running for development and don't want to email your clients while you're testing. The devel module can output all o the queries that run for a single request, showing all of the replaced values and the duration of query execution. When it displays the queries, it can filter them to show only the ones that take longer than a certain amount of time, so that you can optimize them to increase page load speed.

The devel module is what you can use to display a call stack and backtrace in an error which is rather helpful for sorting out really hairy issues. There are quite a few useful features in the devel module for development, and it may be worthwhile to look into whether you're doing actual development or just building a site. The devel module has additional features if you're using Drupal 6, including theme editing.

The Content module allows you to create a bunch of sample content without having to create nodes that have Beastie Boys' lyrics.

A Coder module helps you code to coding standards and can assist in upgrading your module code between versions of Drupal. Another session will cover this module in more detail, so this one wasn't covered at length, but sounds interesting.

The Simpletest module will automate unit testing by executing test classes that you write to test your modules. Another session will go into detail on this module as well, and I'm thinking of attending that one later.

Chad offers these tips: Learn how to use CVS by reading the CVS handbook at I'm not sure how learning about Drupal's CVS structure is useful for you own Drupal development, and would actually prefer to keep my code in Subversion because, in my opinion, it is superior to CVS. Chad didn't really detail why you need to know this, but I suppose it would be handy if you were going to contribute to Drupal or contributed modules directly, since everything in Drupal is still using CVS. Knowing Subversion basically gives you the knowledge you need to use CVS, so better to learn the better tech and then use CVS only when it's necessary, I feel.

One thing he does cite as an advantage in reviewing Drupal via CVS is being able to see intended changes in future versions of Drupal and its modules. A diligent eye would be required to keep track of this kind of thing.

One thing Chad says about Subversion is that Drupal has many man-hours invested in using CVS as a tool, and that there are project management features that are integrated into Drupal as modules. Since these all depend on CVS, changing Drupal repos over to Subversion wouldn't be as simple as switching just the repo, but also all of the dependent modules that publish API deocumentation and such from the site. Very time-intensive.

Cool tip: Copy the first two lines from Drupal's main index.php to a new file, and add anything you want after that to test its working in Drupal with the full functionality it provides. It allows you to test easily without running everything and producing page output. You don't get all of the nice themes on output (unless you call them), but you do have access to things like the database and any active module. Great idea for debugging a tricky snippet of code.

Chad finishes up with some basic debugging information, using exit() and print_r() for testing.

Welcome to the rebirth of RedAlt's Blog And CMS Development weblog!

I'll be covering all sorts of topics in the blog development and social media areas. This will include new software releases and updates, development strategies, and interesting hosted service provider offerings that may be of interest in your site development. I will also cover CMS development tools, not just what runs on a server, but what you can use from your desktop, along with techniques for planning development and getting the most for your time.

I hope to have something new to post every day, so I hope you come back frequently or subscribe to the Atom feed.

Thanks for stopping by, I hope you're as excited to begin as I am!