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!

Helping to make DrupalEasy again


The Most Excellent gentlemen Ryan Price and Mike Anello had me on their DrupalEasy.com podcast again this week. The main theme of the show was Drupal conferences - they discussed DrupalCon Paris which they both attended while I covered the regional DrupalCamp Atlanta, followed up with an announcement of the forthcoming DrupalCamp Florida 2010. Additionally for their Pick of the Week segment I highlighted the pretty great Taxonomy Manager module which I've used to manage major taxonomy changes without loosing track / going crazy. Thanks for having me on again, guys!

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!

Fixing Apache on CentOS/RHEL 5 for Drupal


While not strictly a requirement, in the interests of not having crazy URLs on your Drupal site it's recommended to set up your web server to support .htaccess files. This will let you have URLs like "/products/cool/stuff" instead of "?q=products/cool/stuff" - obviously much nicer, and better for both usability and search engine optimization. Well unfortunately on Redhat Enterprise Linux 5 (RHEL) and CentOS 5 (which is basically the same as RHEL) the standard web server, Apache, is set to ignore these files. So here's how to fix it.

Whether you're configuring the virtual host in a separate file or in the main httpd.conf, the change you'll want to make is the same:

Step 1: enabling .htaccess files:

  • In the main httpd.conf file (should be at /etc/httpd/conf/httpd.conf) search for the string "AccessFileName",
  • If the line is commented out (it starts with "#") uncomment the line by removing the "#" symbol,
  • Update the line to say:
    • AccessFileName .htaccess
  • Restart Apache, reload the site and.. enjoy the error message :-)
  • On to the second part..

Step 2: allowing .htaccess files to override settings:

  • Find the VirtualHost configuration for the Drupal site,
  • There should be a <Directory> section within that block,
  • If there isn't a line that starts with AllowOverride, add a new one within the <Directory> block,
  • Set the AllowOverride line to the following:
    • AllowOverride Options Indexes Limit FileInfo
  • Restart Apache again.
  • Et voila.

This will allow the Drupal .htaccess file to run and make your URLs all nice & shiny!

Removing the acquia_subscription_status menu


For a Drupal site I was developing I originally tried out the Acquia distribution but ultimately dropped it in favor of the vanilla core release. In doing so I also removed the custom Acquia modules that provided integration with their network as I wasn't going to be using it either. All was good, except that the admin menus retained an unneeded menu item named "acquia_subscription_status" that just linked to acquia.com - I had to vanquish it!

Having removed all of the custom Acquia modules I was confused as to why there was this random menu item hanging around. It wasn't part of any of the contrib modules I was using, so I grep'ed my entire site to see if something remained - it was clean. Given the admin_menu module works off the normal menus I then tried the configured menus, again to no avail. So that just left the database.

In the database it seemed fairly obvious that it should be in the menu tables, and sure enough it was. The menu_links table included a menu item that went something like this:

menu_name: admin_menu
link_path: http://www.acquia.com/
link_title: acquia_subscription_status
external: 1

Sure enough, this was it. So then I just removed the menu item and..

It was still there. :-|

A quick look identified the simple fact that the menu was cached! Duh.

So, a quick "TRUNCATE cache_menu;" (or Flush All Caches -> Menu) later and life was good, the menu item was gone.


Subscribe to Drupal