Support for additional fields in blogapi
eaton - November 19, 2005 - 07:29
| Project: | Drupal |
| Version: | x.y.z |
| Component: | blogapi.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
based on some conversations with walkah, here's an api other modules can use to intercept incoming BloggerAPI, MovableTypeAPI, and MetaWebLog creates and edits. This allows custom blogging modules, for example, to utilize additional fields like 'keywords'. In the future, XMLRPC clients could be used to populate even complex Drupal nodes.
Low-impact, low-risk, nice payoff in flexibility.
| Attachment | Size |
|---|---|
| blogapi.module_1.patch | 1.57 KB |
#1
Er, changing the name to reflect the functionality.
#2
+1 - looks good. this is one i've been rambling about for a while to people that would listen and hadn't had a chance to code it.
Dries - FYI - the idea here is to allow modules to hook into blogapi posts ... since the APIs allow for additional information to be past. Two immediate use cases come to (my) mind:
* allowing trackback.module to handle mt_allow_pings
* allow taxonomy.module to use, e.g. mt_keywords for a freetagging vocabulary as tags.
I've also had some talks with people interested in perhaps creating custom desktop clients that would override this field to allow uploading of "richer" content (i.e. recipes, etc) - which could then be caught by a drupal module.
note: needs documentation.
#3
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?
#4
any chance we can revive this tiny patch? looks simple to me, and is blessed by blogapi maintainer.
#5
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.
#6
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'];
}
}
}
#7
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.
#8
+1 I like this.
#9
Keeping it up with the latest. No chance of 4.7, obviously, but development on HEAD is open again.
#10
I see that trackback is hard-coded into blogapi at the moment. It would be good to remove this with this patch.
#11
As requested, this version removes trackback support, allowing trackback.module to handle that stuff if it's present.
#12
#13
What extensions do you have in mind?
Should existing core modules use this new API as well?
#14
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.
#15
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.
#16
I agree that this is a good patch, and that it improves the current behavior. Before committing it, I'd like us to think through if we can change existing core code to take advantage of this, just like other modules would or could. It's always nice when core itself gets to eat its own APIs. :)
Anyone, it looks like all is well, so if no one comes up with any objections or clever ideas, I'll commit this to CVS HEAD. Nice work.
#17
Given Dries' comment, I'll go out on a limb and set this to rtbc.
#18
Committed to HEAD. Please update the hook documentation in contrib.
#19