Restarting the BlogAPI Alternative project


In Drupal 5 and 6 there was a module shipped with core called "BlogAPI" which provided the necessary plumbing to let you post content using desktop clients that supported a variety of APIs. Unfortunately the module languished and, while APIs improved, the module's support for them did not keep up. During 2009 my employer at the time, Bonnier Corporation, wanted a way for their editorial staff to post content while working remotely, so I created the BlogAPI Improved project to add improvements to the module. As often happens, Bonnier decided to postpone their mobile efforts and focused on their core (desktop) web experience instead; when this happened I let the module languish as I just didn't have time to commit to it.

In Drupal 7 the BlogAPI module was removed entirely from core and moved into a separate project which someone volunteered to maintain. After several years, after a ChipIn fundraiser met its goals and with dev versions available for two different branches, there's still nothing available for Drupal 7 that works.

While the whole BlogAPI platform was languishing, along came dedicated projects like Drupad, which used a combination of a contrib module and a customized application to post content, the hope being that by controlling both ends of the equation it should be more reliable & powerful than 10-year-old APIs. At the same time many of the iOS and OSX blogging tools disappeared, e.g. both Ecto and iBlogger were bought out and are currently unavailable, so the market for client software is questionable.

When I decided to upgrade my personal site to Drupal 7 one of my goals was to be able to post content using one of the various iOS clients available. Unfortunately my attempts at posting with Drupad failed, so I'm back to needing BlogAPI again.

Which brings me to the point of this post.

I've started development of the BlogAPI Improved module again, which I've renamed to the more appropriate BlogAPI Alternative as it more clearly speaks to my goals for it, and the first beta for Drupal 7 has been released. My sole aim for this project is to provide a temporary solution while the official project is finished; once there's a working version of the main BlogAPI project, with a working upgrade path, I'll be more than happy to retire BogAPI Alternative.

"Why didn't you just join the official BlogAPI project?" you may ask. Simply put, I don't have a lot of time to put into maintaining it, so slapping putty & duck-tape onto an existing module will take less of my time than learning the Services API and trawling my way through a new codebase; further, it means it'll take less time for me and other people to be able to start writing blog posts offline. Also, it provides some temporary relief from the official module's maintainer(s) so their issue queue isn't filled with people bitching that nothing has been released yet. Finally, it keeps a distinction between a project that has already been sponsored by several companies, versus my project which has not.

I'll see you in the issue queue!

Using myBlogEdit with Drupal


In my efforts to test all OSX blog tools to see how well they work with Drupal, I've come across a new tool via MacZot called myBlogEdit. This is a relatively simple tool that is unfortunately missing a good amount of standard functionality:

  • There is no WYSIWYG editor.
  • It doesn't give you a list of the "blogs" available through the API, you have to manually type it. For Drupal this means typing the content type name.
  • When you download existing articles it doesn't correctly identify that the articles have been published or load their tags.
  • It doesn't load the existing tags in the system, instead it presents you with a basic text box to enter them.


  • When you go to publish your article, it presents you with a drop down list to select a category. There's a button beside the selector to presumably obtain a list of the categories from the blog, but clicking this makes the app crash.
  • None of the supported APIs are compatible with Drupal for actually publishing articles, every single one fails.
  • The logging system doesn't record the message sent to the API, only what the response was, so debugging it will be impossible.

So, if you're looking for a weblog editing tool for a Drupal site this is one to skip, simply because it won't work!

The future of blogging with Drupal via XML-RPC?


One of the benefits of having a content management engine that supports XML-RPC-based content creation is that you can write your content in more usable tools and publish when finished. Drupal is one such system and is an amazingly powerful tool in its own right, but you still want to be able to write offline..

For offline / desktop-based writing I use ecto, which is a MacOSX-based editor that works pretty well, though many prefer other tools like MarsEdit, etc. So lets see how well it works..

The first step is to enable the BlogAPI module and then doing some basic configuration as mentioned my a previous post. That's the easy part.

One of the most powerful aspects of Drupal is being able to build a very powerful taxonomy structure by building different vocabularies of terms, e.g. a master category, a general-purpose free tagging / folk taxonomies aka "tags", maybe one for the related country, etc.. it can be amazingly powerful and is well worth learning how to effectively using.

To match that, the XML-RPC blogging standards have ways of querying the list of categories, usually the MetaWebog API call metaWeblog.getCategories or the Moveable Type API call mt.getCategoryList. Additionally, the Wordpress folks have added their own XML-RPC API and have given the world wp.getTags which is for listing tags. Ecto gives two different lists, one for categories and one for tags, which can work well in the right circumstances.

A bit of a limitation with Drupal's BlogAPI module, however, is that you are not given much control over how it handles vocabularies. By right you should be able to select which one is the master vocabulary to be used as the standard category and which is used as tags, or even add a way to list all vocabularies with their terms in a nested structure. Unfortunately, it currently only supports the categories functions and lists all of the site's terms in one long list. With today's sophisticated desktop blogging tools, and Drupal's amazing taxonomy system, this is an unfortunate limitation.

For the forthcoming Drupal 7 I think the BlogAPI really needs expanding. There are two ways of looking at it:

  1. Just add some basic support for existing APIs:
    • Add controls to the BlogAPI module to let you decide which vocabulary or vocabularies are made available through the existing blogapi_metaweblog_get_category_list() function.
    • Add support for the wp.getTags function and add a similar configuration block to decide which vocabularies are made available through it.
  2. Push beyond the existing APIs, lead the field:
    • Define an extension of one of the existing APIs which returns a nested array of all vocabularies.
    • Work with other blogging software and desktop tools to get this feature supported, for example Wordpress is working towards being able to support user-created taxonomies (like Drupal).

Obviously, being an open-source system this functionality won't fall off the trees, it has to be built by someone. So who's going to build it? You? Me? Maybe.


Update: It should also be mentioned that the combination of Ecto and Drupal is still a bit buggy - when I initially published this article it missed all of the taxonomy selections.  Bummer.


Subscribe to blogapi