My First Impressions of OpenPublish: 10 Joys

We recently switched the new site development for Boston Review(BR) from a bare Drupal underpinning to an OpenPublish underpinning. In this post I share my early impressions from a the perspective of a developer and site-builder.

[OpenPublish is a Drupal distribution from Phase2 Technologies based (currently) on Drupal 6.x with many module choices, configuration, and default theming intended to be useful to publishers.]

1. Installation is the same as with Drupal

Obviously, as a Drupal developer, it's important to me that OpenPublish is based on Drupal. But I was pleasantly surprised when I didn’t have to learn anything new to install OpenPublish.

The fact that I got over sixty compatible installed modules with lots of basic configuration and default theming right out-of-the-box, really piqued my interest. I knew that if it was consistent with what I wanted to build, it was going to save me immense amounts of time.

2. Streamlined administration

Take a look at the Drupal reports page in OpenPublish:

The well-designed icons are the first thing I noticed, but the way the whole administrative experience is streamlined also hit me after I got used to the administrative menus that appear to the left of each page (thanks to the Admin Module). One of the many benefits of this is that clients get the impression “Hey, an OpenPublish-based site is actually usable by me”. This is very important, since many potential clients have anxieties about taking care of a new site – and an OpenPublish test site looks (and is) manageable.

3. Power “under the hood”

One of the first things I noticed about OpenPublish is that the platform makes the same choice of fundamental modules that I already had chosen for the data-, image-, and multimedia-handling needs of the Boston Review. I’m speaking here of things like Views, CCK, ImageField, ImageCache, and Embedded Media Field. I knew that these were very solid choices in terms of upgrade-path for Drupal 7 and beyond. But I was also taken by some of the other advanced possibilities in OpenPublish, like Apache Solr search integration, that also matched my choices. So I suspected, right away, that the various semantic technologies also built into OpenPublish (see later entries on OpenCalais and Apture) might be appropriate for BR as well.

4. Attractive default theming

Take a look at this article view from my Boston Review development site:

This article, despite the fact that it can’t display custom Boston Review fields like “discussed works”, gives a good idea how BRs content will eventually look on their new site. So it is important that the default layout is good, so clients can get an idea of a new site before a designer and themer get to work on it. People wanting a new site just respond better to a site that is easy to look at.

5. Attention to detail: Author creation and display

A issue that publishers are faced with in setting up a Drupal site is that the actual author of a given piece of content does not generally have an account on the Drupal site. So Drupal’s out-ot-the-box authorship mechanisms do not suffice. But in OpenPublish each actual author is an object of type Author, and these objects are created and displayed flexibly and easily.

When a person creates a new article on an OpenPublish site, the part of the form where one sets the author looks like this:

One great thing about this is that if the article is by a new article, one can simply hit the “plus” icon, create the new author in a pop-up window, and then automatically reference the newly created Author instance. This sort of attention to detail carries through to viewing the article in the default OpenPublish theme.

So, for example, if I create myself as the second author of this piece, the end of the article will look like this:

Note that the panel says “About the authors...” automatically and lists us both. What a pleasure.

6. Organization with the Features module

OpenPublish organizes related views, content types fields, imagecache settings, and the like into “features” which can be enabled or disabled as a group, and are version-controlled on http://drupal.org. This emerging module provides a needed and sensible level of structure to the complex platform.

7. Bidirectional links with the Relationships Module

Articles have Authors in OpenPublish, but Authors at the same time refer back to the articles they have written. One manifestation of this is that viewing an author automatically shows the articles they have written:

And using this capability in my own custom node-reference fields has been a snap.
NB: I have never actually co-authored anything with Craig Morgan Teicher

8. Search with Apache Solr

Once I set up a Solr Search server one of my first tasks was to turn on a block for automatically sorting search results different ways. Once I learned that block visibility is controlled by the Context Module in OpenPublish, and is not set on the usual blocks page, it was a snap to produce the following search results page.

9. Automated linking (and more) with Apture

With OpenPublish, one can automatically choose a link with the web service Apture. For example, when entering a story about the world bank, one can highlight the words "world bank" and hits the Apture link icon.

This gets you a pop-up that asks you what kind of link you want:

And when you click the Create Link button the appropriate HTML code is inserted in your article.

It's as easy as that. This barely scratches the surface of the services available through Apture which include embedding content and automatic links to your content.

10. Automated tagging (and more) with OpenCalais

OpenCalais is a service powered by Thompson Reuters which automatically tags content. The text of content of types you choose is sent to OpenCalais in the background, semantic analysis is performed there, and appropriate tags arereturned to your site and added to your article. For example, default tagging of articles produced all of the following tags except "On poetry" and "January February 2010".

This addresses a fundamental problem in making the web more semantic, and a daily struggle of editors everywhere - "Whose job is it to tag the content and maintain the taxonomy?"

As you can see, OpenPublish is allowing me to leverage vast efforts on the part Phase2 Technologies and the Drupal community effectively for clients in publishing. And in very practical terms, it is helping me deliver a new site to Boston Review with capabilities that neither of us dreamed of at the start of our project. Capabilities that will bring tremendous value to the Boston Review and tremendous connection to the Boston Review readership.


Nice to see someone talking sense

Nice Top Ten!

I started looking at Drupal a month or three back and thought I had a reasonable hang on it as a 'beginner'. After reading more about Drupal I realised how wrong I was. Using Actual Pages (Not the module) to create static pages that appear dynamic instead of using modules – pages, views, CCK, man I felt so stupid. I was rather in a rush to complete something in Drupal and I was getting paid for it so it had to be quick and ended up looking ok (ish), she is happy so that's that!. Feel free to have a look if feel like it: http://catherinebarker.co.uk.

So I decided to start again but the Drupal documentation is so uninspiring, it has some real flat spots in it and I was desparate to get to using CCK, views and pages, then found out all this other guff I needed to install to make it do what I want and quickly got p'd off!

So I found open publish, WOW, what a breath of fresh air, even from looking at how it works and seeing taxonomy working everything starts to make sense. I am tempted to use it for a couple of builds I have coming up but again they are time critical, but I have a feeling I would be better to go back to Drupe and start a fresh and try to build there as I think this CM/S/P/F (System/Platform/Framework?!!) may be a bridge too far at the moment...

Bit like getting a Ferrari when you've just got your provisional license.

I would love to hear you talking about some pros and cons for either system.

Web site organization


I'm glad you like the post.

Site organization is a HUGE topic. And it seems like something I should blog about if I find the time.

A few thoughts of mine:

1. There is almost no wrong way to build a fairly static site.

2. The code for the look of any site is bounded in size by the total number of pages.  The code for the functionality of any site is unbounded since the site may do nearly anything.

3. A site with lots of content starts to need a CMS or the sheer number of separate files gets unmanageable. Bulk operations on different content types are nearly impossible without separation of content and code.

4. When a PHP-mixed-with-the-content type site adds functionality over the years, each set of PHP scripts tends to add a database. One ends up with a site with many, many databases and almost no organization. Yikes!

5. Getting feedback from PHP when it is in-lined in HTML files is (almost?) impossible. So, in adding new content if one breaks any in-lined code one gets a White Screen of Death (WSoD) and anyone adding things to the site will waste lots of time, frequently, and not even know why the site is so hard to update.

6. Everyone's view (including mine) is myopic, because the systems are all so complex that few people learn well more than one system.

7. In the Drupal sphere, there are many approaches to the problem. Many are distributions of Drupal, such as OpenPublish, OpenAtrium, and Drupal Commons. Drupal Gardens builds Drupal 7-based sites from a web interface. Buzzr does something similar.

Perhaps I will expand this into a blog post someday.

Thank you


many thanks for such a thoughtful and detailed review. It always amazes me how power-users, like yourself, find the ways to explain a software much better than probably the original authors could have.

We are thrilled that you liked OpenPublish and can't wait to start reading the new Boston Review powered by Drupal and Openpublish.

Drupal SEO