Drupal

The basics - and even advanced aspects - of SEO are so ordinary for Drupal site builders that sometimes we forget what an advantage Drupal affords us. While site owners still need to think about content quality, metadata and search terms, creating a high-rankable site is a matter of course for Drupal developers.

Here's a brief look at MediaCurrent's SEO work for a client, which also serves as a simple how-to for site builders focusing on SEO in a Drupal environment.

http://www.mediacurrent.com/blog/drupal-seo-win

For several years, I've been using and recommending the excellent Mars Edit for folks who want to write blog posts offline for later uploading.

There are several reasons for people to want to do this - for one thing you can work on several articles at once, without having to flip between browser tabs. Also the better offline editors have good media management, allowing the user to upload images from the desktop easily, and in some cases even pull from iPhoto, or from previously published stories, without breaking the flow of writing. Even the best WYSIWYG editors that work in-browser can't quite match the ease of use and basic unobtrusiveness of a good offline editor.

One user has also points out that she feels safer having a local copy of her posts available as backup, or in case she wants to pull a bunch of posts together for a story collection or a book.

In any case, offline editors are popular, and Mars Edit is one of the best (Mac only, sorry).

So when I recently updated this site to Drupal 7, I figured everything would Just Work, as they say - silly me. There are some configuration issues on the Drupal side that have kept me busy today - nothing that was Mars Edit's fault. It all comes down to setting up BlogAPI correctly.

Just by way of background: Drupal requires the addition of the BlogAPI module in order to provide a web service that allows remote posting in the manner we're looking for here. BlogAPI will accept POST methods, authenticate the user, parse the provided xml, and create or update the node for you. It will also accept images and put them in the Drupal file hierarchy, so that they can be referenced by your post. However, these images need to be encoded as text, because of the xml-based conversation that it's having with the remote client.

Drupal uses the Movable Type API, which is quite well supported generally, and Mars Edit is smart enough to know that - so that when you set up your blog account in Mars Edit for the first time, it generally gets the settings correct.

There are a few gotchas though, and as I spent a good few hours on this, I thought I'd share:

Firstly, you need to get BlogAPI installed. Install it as you would any other Drupal module, but be sure to turn on the supporting API providers - MetaWeblog and Movable Type - in the Modules list. Apparently we need both, as some key functions seem to reside in MetaWeblog.

Next, be sure to grant permissions. This may seem obvious, but I spent a frustrating hour trying to post images as the superuser, and failing. Even if your account is UID=1, you'll still need to create a role, add yourself to it, and give it perms for BlogAPI. If you don't, you'll be able to post text just fine, but BlogAPI will refuse your images, because you won't have a valid file upload limit.

If you'd like to be able to push posts up in Draft (unpublished) status, you'll need "Administer Content" perms as well - grant that to your role, again even if you're user #1.

Finally, if you're getting complaints about the SQL schema, as I was, just uninstall BlogAPI (that means uninstalling the providers first - and I do mean uninstall at /admin/modules/uninstall, not just "turn off"). Turn BlogAPI back on again, and it will re-make the database tables it needs. You will then have to reactive the providers, and set everything up again at /admin/config/services/blogapi. I think this may have something to do with the update - perhaps the BlogAPI updater doesn't quite handle the jump from D6 to D7. Anyhow reinstalling solved it for me.

Just a short interlude to the series on CGSHR…

I've been putting off updating this blog to Drupal 7, but it's time to bite the bullet and do it on several sites I'm responsible for.

Actually this site is simple enough that the data migration was quite straightforward; the time-consuming part of it was the re-making of the theme, since themes can't really be upgraded as such. Good opportunity to make the theme a bit more responsive, anyhow.

One odd glitch was the scrambling of the Administration menu - items disappeared, other items turned up in the wrong place, etc. No amount of re-installing the Admin menu module, rebuilding the menu cache, etc. was of any help.

It turns out this was a known issue (see this d.o post). After hacking some stuff out of the MySQL database as per a suggestion here, the Admin menu was back to normal.

Now that that's done, it's on to Resonetrics.com...

The new site for
The Consortium on Gender, Security and Human Rights had its "soft-launch" yesterday. The site is live and usable, but the owners still have a few things they'd like to tweak.
Little do they know, web sites are never really finished - so for all intents and purposes, this is the real thing.

Probably the most interesting part of the project from my point of view was the heavy customization of Apache Solr search results, and the whole search experience. This was mostly accomplished via templates in the site's theme. I'll share a few details in case anyone's interested.

To begin with, this is a Drupal site - specifically D7. The owners had an initial design and a sort of prototype site built by a previous developer in D7, which they handed off to me. That work was done cleanly and competently, but it was clear the client wanted to go so much further than the original builder was prepared to go. I'm not sure what transpired, though I did have a friendly chat with them, but in any case they were out of the picture by the time I got involved.

When I received the site, the first thing I did was to stage it on my Drupion server. Drupion are like family to me, and I've trusted them to help me grow my Drupal business, so it was an easy pick. When the client agreed to host with me for production, that made the decision that much more rational.

Drupion got Solr and Tika set up right away. Solr is a much more powerful search tool than the built-in Drupal search, capable of handling a very large number of indexable items. More info on that here. It runs as a separate server process, and needs about half a Gig of RAM. Tika is an add-on to Solr, which allows searching inside documents such as Word, PDF and other files that are not normally presentable on the web. The client has quite a number of academic research papers and other documents in these formats, so the ability to search inside them was essential.

Once Solr was running and had started indexing the site's content, we looked at what Facets to use for searches. Facets are basically filters - they allow you to limit searches to, say, one content type, or a particular taxonomy term.

Above, you can see the some of the facets for the overall site search Here we've searched for "Gender" - a term guaranteed to return lots of results on this site.

On the left are check boxes that allow the user to narrow down the search to a particular Country, Region, etc. There's also a facet for Content type. On this site, content types mostly correspond to the type of document or media being shown - Citations, Research, Films, etc.
But you can restrict your search to one content type equally well by using the tabs along the top of the main content area - Films, Lectures, etc.
Clicking one of these will retain the same search terms, but narrow your results down to a single content type (if you want to search 2 content types, you'll have to use the checkboxes on the "All" tab).

In order to get these individual tabs implemented, I set up a separate search environment for each of the key content types. This allowed me to set facets and Bias for each (which we may want to leverage later).

Next, I made pages for each content type. Each Page has its own title, and most of them (except "All") are limited to a particular Bundle (bundles are essentially content types, at the machine level. Check out D7's Entity system for more info). Because they all have paths that look like /search/--bundle--, they're showing up as tabs on the /search page. Neat :-)

In my next post I'll show how Facet blocks are set up, and talk about theming the search results. Finally, I'll show some of the Views on the site, which offer more of a browsing experience, which I think complements the Search pages nicely.

Link

powdermonkey brings us the welcome news that the US Department of Defense has positively OK'd Open Source software for use in its projects.

Here's the opening statement:

To effectively achieve its missions, the Department of Defense must develop and update its software-based capabilities faster than ever, to anticipate new threats and respond to continuously changing requirements. The use of Open Source Software (OSS) can provide advantages in this regard.

The memo's attachments outline a cogent case for OSS, which all software customers should take to heart. Here's a list of key points:

There are positive aspects of OSS that should be considered when conducting market research on software for DoD use, such as:

1. The continuous and broad peer-review enabled by publicly available source code supports software reliability and security efforts through the identification and elimination of defects that might otherwise go unrecognized by a more limited core development team.
2. The unrestricted ability to modify software source code enables the Department to respond more rapidly to changing situations, missions, and future threats.
3. Reliance on a particular software developer or vendor due to proprietary restrictions may be reduced by the use of OSS, which can be operated and maintained by multiple vendors, thus reducing barriers to entry and exit.
4. Open source licenses do not restrict who can use the software or the fields of endeavor in which the software can be used. Therefore, OSS provides a net-centric licensing model that enables rapid provisioning of both known and unanticipated users.
5. Since OSS typically does not have a per-seat licensing cost, it can provide a cost advantage in situations where many copies of the software may be required, and can mitigate risk of cost growth due to licensing in situations where the total number of users may not be known in advance.
6. By sharing the responsibility for maintenance of OSS with other users, the Department can benefit by reducing the total cost of ownership for software, particularly compared with software for which the Department has sole responsibility for maintenance (e.g., GOTS).

Gives new meaning to "Good enough for government work" :-)
Powdermonkey post

DoD PDF document

Following up on the news that whitehouse.gov has been migrated to Drupal, Tim O'Reilly comments on the O'Reilly Radar site.

Among other things, O'Reilly points out that having a high-profile target like this using OSS software validates the long-understood advantage of open source in the security arena. But there's more:

More than just security, though, the White House saw the opportunity to increase their flexibility. Drupal has a huge library of user-contributed modules that will provide functionality the White House can use to expand its social media capabilities, with everything from super-scalable live chats to multi-lingual support.
In many ways, this is the complement to the Government as Platform mantra I've been chanting in Washington. When you build a vibrant, extensible platform, others add value to the foundation you establish; when you join such a platform, you get the benefit of all those features you didn't have to develop yourself.

So is the White House actually creating a user community around their website, in the best Web 2.0 fashion? Well, not yet - right now there's no interactivity to speak of on the site, and no indication as to what the plans are.

O'Reilly post

AP news release, via Huffington Post

Drupal lead Dries Buytaert's comments

Drupal founder Dries Buytaert has a piece on his personal blog about ways in which Drupal is overcoming the hesitation of CIOs to abandon big expensive "enterpise" content management platforms, in favor of OSS solutions like Drupal. You know - the ones they spent, oh, say, $500K on the first year...?

Here's a list of reasons for picking Drupal, from the use case:

The decision for IMO to use Drupal came after an unsuccessful attempt to build out In-Fisherman.com with another CMS. The deciding factors for selecting Drupal were:

• Scalability - Drupal was perceived as the most scalable and extensible open source option.
• Cost - No licensing fees.
• Multi-site / multi-database architecture - Drupal’s flexible multi-site configuration would allow IMO to store content and user data in multiple databases for a single site. Multiple databases would keep distinct areas of the site operational in the event of database failure from server load. The user data is stored in its own database and the gear/angler/www sites are set-up to seamlessly pull user data from that separate database.
• Hosting - The expected traffic for the site demanded a low-cost enterprise level hosting environment. Drupal and the LAMP stack were a natural fit.
• Flexibility - IMO's previous CMS was inflexible, making it difficult to implement new and innovative features. Drupal’s modular framework, API and theme override capabilities made it the top choice.
• Theme customization - Drupal’s separation of presentation and business logic through the theme layer allowed the In-Fisherman.com UI to undergo significant revisions during and after development.
• Active development community - A fragile economy encouraged open source software vs. a proprietary vendor solution. IMO was looking for a community with solid leadership and momentum. In addition, the Mediacurrent offices were local to the project stakeholders and allowed for enhanced interaction.

Here's an end-user quote:

...it was important for us to implement a content management system that enables us to continually improve our sites without the constraint of vendor roadmaps and proprietary code. The transparency of Drupal’s source code and engaged developer community ensures that any deficiencies in the code are quickly discovered and remedied, new features can be developed as necessary, and we will always retain the flexibility to keep our sites on the cutting-edge.

Use case from Drupal.org

Dries' article