The future of blogging with Drupal via XML-RPC?

Tags: 

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.

 

Posting to Drupal through XMPRPC / BlogAPI

Tags: 

When I migrated my blog from Wordpress to Drupal one key thing I still wanted to do was be able to use ecto to post messages from my laptop rather than through the web interface - it can be just easier at times. Thankfully Drupal has a plugin/module built in which does this for you, the BlogAPI module. So I activate the module then try to connect using ecto only to be greeted with the lovely message:

The response from the server did not contain valid data.

This was frustrating, it should just work, right? Thankfully ecto has a console feature which displays all communications with the server, and I was able to see it submit:

<?xml version="1.0" encoding="UTF-8"?>
<methodCall>
<methodName>blogger.getUsersBlogs</methodName>
<params>
        <param>
                <value><string>ignore</string></value>
        </param>
        <param>
                <value><string>Damien</string></value>
        </param>
        <param>
                <value><string>*****************</string></value>
        </param>
</params>
</methodCall>

This is a normal Blogger API call to find out what blogs a given user (me) has permission to write on at a given blog installation, and should have returned some valid data. Here's what came back:

<?xml version="1.0"?>

<methodResponse>
  <params>
  <param>
    <value><array><data>
</data></array></value>
  </param>
  </params>
</methodResponse>

Obviously this isn't quite right.. I dug through the code, adding print and print_r statements where I thought they might help, until I came to blogapi.module line 937 which says:

$available_types = array_keys(array_filter(variable_get('blogapi_node_types', array('blog' => 1))));

This is supposed to grab the blogapi_node_types system variable which stores a list of the Drupal content types you told it were allowed to be written to using the BlogAPI.. and I had set them, right?

200904201148.jpg

No, as it turned out I hadn't, though I thought I had.

Once I went to /admin/settings/blogapi I was able to mark a few content types to be editable, hit save, go back to ecto and finally see what I wanted:

200904201147.jpg

Success!


Ok, so next problem.. I wrote the above, including the two pasted images, hit Publish but started getting the following error:

<?xml version="1.0"?>
<methodResponse>
  <fault>
  <value>
   <struct>
   <member>
   <name>faultCode</name>
   <value><int>1</int></value>
   </member>
   <member>
   <name>faultString</name>
   <value><string>It is not possible to upload the file, because it exceeded the maximum filesize of 0 bytes.</string></value>
   </member>
   </struct>
  </value>
  </fault>
</methodResponse>

Obviously a problem persisted.

I cranked open the files and inserted some extra code that made it say::

<?xml version="1.0"?>
<methodResponse>
  <fault>
  <value>
   <struct>
   <member>
   <name>faultCode</name>
   <value><int>1</int></value>
   </member>
   <member>
   <name>faultString</name>
   <value><string>It is not possible to upload the file, because it exceeded the maximum filesize of 0 bytes and your file was 12.04 KB.</string></value>
   </member>
   </struct>
  </value>
  </fault>
</methodResponse>

From this you can see that it was getting the file, but it was basically saying that my account was not set up to accept attachments, which was not true as I was the administrator and could do everything, right?

I went back to the BlogAPI settings page, ensured that the file settings looked correct..

200904201211.jpg

.. scratched my head. Then I went to look at the permissions.. as it turned out I had not enabled "administer content with blog api" for my user group.

200904201212.jpg

Doh. I enabled that permission, saved it, and now when I went back to the BlogAPI settings page there was a new item waiting for me:

200904201210.jpg

I expanded that, set the same 1MB and 5MB... and saved..

Et voila! That did the trick, I can now post embedded images too!

BarCamp Orlando 3 was awesome!

Tags: 

Anyone who lives in Central Florida who's into anything IT-related, or design, or business management, or marketing.. or anyone who wasn't otherwise busy, should have been at BarCamp Orlando this past Saturday. With three rooms for presentations, there were plenty of sessions to cover just about any interest. Needless to say, it was awesome.

One of the best presentations, or rather two presentations, that I attended were from Murray Izenwasser who gave two great talks on business use of social media and, surprise surprise, how most companies don't have a clue of what they're doing. A key point was that just randomly throwing out a Facebook page or a Twitter account won't magically make the world shine on you. Contrary to popular opinion, if you're trying to build a social media following, if you build it they won't come, it takes a lot of planning and effort. I personally saw this at a company I worked with a few years back where the owner read an article about how blogs were great so decided to start a blog.. only then rather than letting it happen organically forced a rigid control over it so it became little better than their news announcements in a different form.

Another great session was, as always, Rob Dempsey talking about his favorite topics - agile management and scrum - always a good presenter.

A session I'm really sorry I missed was regarding IT in healthcare, particularly when it was one of the few that mentioned Drupal (my CMS of choice these days), but I'm looking forward to the notes being made available, I've heard it was very interesting and well presented.

So a huge thanks to Gregg Pollack, Eric Marden and everyone else who helped out! This year's was definitely full of win! I'm really looking forward to next year's...? :-)

New home for the website

Tags: 

After several months waiting to do so, I've finally moved this site to Drupal. Right now the content has been moved over and I've set up most of the bare features I wanted, but I still have to finish some functionality and, obviously, make it not look quite so horrible. More updates will be arriving over the coming weeks, stay tuned!

menu_link_save doesn't like aliases (drupal)

Tags: 

A quick tip.. while working on an install profile in Drupal I discovered that the menu_link_save() function requires an internal URL, e.g. "node/123" instead of "my-cool-page". Once I tracked down the issue I was able to very easily create lots of menu items as needed, but it wasn't entirely obvious this was needed. I was using install_profile_api to create the menu items and figured it was going to make things easier for the end user, but alas no, so I threw together a quick patch to save others the headache, and wasted hours of development time.

Pages

Subscribe to Front page feed