Allows autodiscovery of BloggerAPI via RSD. Basically, we first insert a

<link ref="EditURI" type="application/rsd+xml" title="RSD" href="blogapi/rsd" />

into the header of the mainpage (requires http://drupal.org/node/view/8285)

and then we return an RSD XML to provide a preferred blog engine (default 'Blogger').

Note: CVS Drupal can probably handle Blogger APIs with maybe a few MetaWeblog APIs. It will fail on most MoveableType API.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dries’s picture

I have a number of concerns with this patch:

  1. It violates Drupal's coding conventions:
    • No space after commas.
    • Constant strings should use single quotes, not double quotes.
  2. It exposes terminology the user might not be familiar with. For example, the newly introduced setting mentions 'RSD' without explaining what 'RSD' stands for or what it _actually_ changes/adds.
  3. The engine name reads 'Drupal-4-Bloggers-0.6'.
jseng’s picture

FileSize
2.3 KB

1. fix space after commas

2. Add explaination of RSD and the usage.

3. Change engine name to 'Drupal'

ps: Sorry, I dont intend to change " to ' as that involves testing the patch all over. If thats the reason to reject the patch, so be it.

Dries’s picture

The patch won't work with HEAD. It still uses the old menu system.

Junyor’s picture

Updated patch against HEAD.

Dries’s picture

Excellent. I think we are almost there. There is one thing I'd like to discuss which is the introduction of a new hook called 'default_node'. Is this really necessary or can we use the nodeapi for this?
.

jseng’s picture

firstly, it is not strictly a 'node' thing. It is more of a page, ie, when you display the front page, you show this.

secondly, there arent any $op in hook_nodeapi() that triggers when you display the front page. of cos, we can add that.

Dries’s picture

Does it really makes sense to emit this link when looking at say, user profiles, forum posts or the news aggregator? I was mistakenly assumig that the 'EditURI' link should only be available when the content you are looking at is editable through a blogging application (i.e. when _nodeapi('view') gets called).

If so, instead of introducing a new hook, I suggest we abuse the _menu() or _link() hook like the atom module does. We could also use the _init() hook, but that will introduce more overhead.

I'll make these changes and integrate the code in HEAD as soon this get sorted (hopefully by tonight).

jseng’s picture

yes, we shouldnt emit this
autodiscovery header unless it is the frontpage (and only the frontpage). Which is why we need the hook_default_node() invoked from node_page_default() only. And I am not sure you can do that with hook_menu() or hook_link() because you will emit this on every page if so.

No, it should not be emitted on any page that is editable, only the frontpage.

Perhaps it would be clearer if you understand how this autodiscovery stuff work.

Lets say you use a blogging tool (e.g. ecto on Mac or Zempt on Windows), then you want to blog to drupal.org so you create an account. You enter your blog website (http://drupal.org/), your userid and password. The blogging tool will do a http query to http://drupal.org/, retrieve the frontpage and look for
which will point them to your RSD (Really-Simple-Discovery) 'file'. (It is technically not a file in drupal). Then it do another query to retrieve your RSD 'file', which is basically an XML file containing information like where is the xmlrpc.php engine and the blogAPIs you support. (CVS drupal can only handle Blogger...can't do MovableType or MetaWeblog) so it can configure itself.

Complicated? Well, everything happens behind the scene for the blogger so it is pretty simple for him. All he realise is he entered his blogsite, his userid and password and bingo, the blogging tool knows how to interact with his blog, retrieve his past entries and can post new one.

jseng’s picture

incidently, the way atom.module inserting its header to every page is also a problem :- e.g. in taxonomy/or/x page, you suppose to output the relevant atom headers, not for the whole site. as far as i know, there arent any hook there also.

if you dont like the hook_default_page(), then consider a hook_page($op) which $op could be = 'default' or different taxonomy page so other modules can drupal_set_html_head() for different kind of page.

moshe weitzman’s picture

you don't need a new hook to restrict injecting HTML to only the front page

if ($_GET['q'] == variable_get('site_frontpage', 'node')) {
// do something
}

Junyor’s picture

Righto. I've updated the patch using Dries' and weitzman's suggestions.

Dries’s picture

Committed to HEAD. Marking this fixed.

Anonymous’s picture