Support for additional fields in blogapi

Er, changing the name to reflect the functionality.

After a discussion with chx in #drupal, it became clear that adding a completely separate api is probably unecessary. Attached is a patch that uses the existing nodeapi infrastructure, with 'blogapi new' and 'blogapi edit' as the $op parameter. This gives the same functionality for just 4 lines of code.

I'd LIKE to reduce this to just one op (node_invoke_nodeapi($edit, 'blogapi')), but the $node parameter is either an object or an array depending on what mode the blogapi module hands the node off in. Is the consolidation worth the additional work for each implementing module (checking for object vs array and acting accordingly)?

Thoughts?

Rerolled for HEAD with a minor tweak: 'blogapi' is the only $op it uses, and the third parameter is used for 'new' or 'edit'. Again, this one has been blessed by the blogapi maintainer, and it opens doors for much richer editing of custom content types via desktop clients.

Thanks for the reminder, moshe.

Er, whoops. Left out the $content array in that patch, making the op utterly worthless. Now works. ;) To use it, someone would write the following:

foo_nodeapi(&$node, $op, $arg3, $arg4) {
  if ($op == 'blogapi') {
    if ($arg4 == 'edit') {
      $node->foo_field = $arg3['incoming_xmlrpc_field_foo'];
    }
    else {
      $node['foo_field'] = $arg3['incoming_xmlrpc_field_foo'];
    }
  }
}

Got walkah's blessing on this one. Understood if it doesn't go in for 4.7 (alas) but it is, technically, ready to commit.

Keeping it up with the latest. No chance of 4.7, obviously, but development on HEAD is open again.

As requested, this version removes trackback support, allowing trackback.module to handle that stuff if it's present.

Taxonomy is the best example, Dries. Movable Type, for example, sends both a 'category' field (roughly analagous to hierarchial or flat taxonomies in Drupal) AND a 'keywords' field (like one of our free-tagging taxonomies). Blogapi could be modified to handle the categories and keywords differently, but it might make sense to use this hook in the taxonomy module, centralizing the mapping of terms and keywords.

Other possibilities for non-core stuff? Content types that utilize the additional fields other blogging systems provide (like Livejournal's "visibility setting" mapping to a group-access flag, or Movable Type's "teaser" field being used to populate an additional optional node property). I've been speccing out a 'drupal for blogging' install profile, and providing modules that mirror the fields in other blogging systems (via 'livejournal post', 'movable type entry', and 'wordpress post' node types) would also smooth the way for those transitioning.

This patch isn't a huge jump in features, admittedly -- it's an evolutionary step in blogapi support that gives us more flexibility, and better hooks for expansion. It's important, I think, as Drupal matures and is used by bloggers and blogging communities. As other blogapi/metaweblog systems add features via custom fields, it makes it easier for us to respond via contrib modules, rather than patching blogapi.module itself.

Let me clarify. I'm not sure taxonomy.module would be a good place for the Movable Type import code. But then, I'm not sure core is the best place for anything that amounts to import/export cruft, interfacing with other potentially changing software platforms. Rather, I think that this patch would allow Core to not touch that kind of data, allowing other modules (like 'MovableType.module' or Livejournal.module, which already exists to handle LJ authentication) to do the field-mapping.

Given Dries' comment, I'll go out on a limb and set this to rtbc.