There is a problem with CVS blogapi, and how blog API clients know what input filter is used for each post. Currently, no information is sent -- the field is blank. Here is an email from the MarsEdit author regarding the problem:

When getting recent posts, the value for the text filter field for each post is always an empty string. For historical reasons, the text filter field name is mt_convert_breaks -- and it's always an empty string in the XML-RPC response, like this:

<member><name>mt_convert_breaks</name>
<value><string></string></value>

It should instead contain the identifier of the text filter. For instance, on your site, the Markdown With SmartyPants filter has an identifier of 1. So for a post that uses that filter, the XML should look like this:

<member><name>mt_convert_breaks</name>
<value><string>1</string></value>

Comments

walkah’s picture

Assigned:Unassigned» walkah

i

Uwe Hermann’s picture

walkah, are you still working on this? Any progress?

snej’s picture

Status:Active» Needs work

I independently discovered this problem last night (with Ecto), tracked down the cause, and fixed it.

In blogapi.module, the function blogapi_blogger_get_recent_posts() runs a custom SELECT query to get the nodes. Unfortunately it's missing the 'format' and 'comment' columns, so when the rows get passed to _blogapi_get_post(), it generates empty strings for the XML-RPC 'mt_convert_breaks' and 'mt_allow-comments' attributes.

The fix is simply to amend the query string to add the missing columns. Here's a patch for Drupal 4.6.5's blogapi.module:

321c321
<   $result = db_query_range('SELECT n.nid, n.title,'. ($bodies ? ' n.body,' : '') ." n.created, u.name FROM {node} n, {users} u WHERE n.uid=u.uid AND n.type = '%s' AND n.uid = %d ORDER BY n.created DESC", $type, $user->uid, 0, $number_of_posts);
---
>   $result = db_query_range('SELECT n.nid, n.title,'. ($bodies ? ' n.body, n.format, n.comment,' : '') ." n.created, u.name FROM {node} n, {users} u WHERE n.uid=u.uid AND n.type = '%s' AND n.uid = %d ORDER BY n.created DESC", $type, $user->uid, 0, $number_of_posts);

I haven't contributed to Drupal before so I'm not totally clear on the process for submitting fixes/patches yet. I'll save this, then go read up on the procedures -- looks like I'll need to check out CVS and submit a patch against that. In the meantime I'll set the status to "patch (code needs work)" even though it's the patch, not the code, that needs the work :-)

snej’s picture

Status:Needs work» Needs review
StatusFileSize
new1.2 KB

OK, here [attached] is a patch against top-of-tree CVS. I haven't run the CVS version yet, so this definitely needs to be tested. However, it's just a one-line change to add two columns to a SQL query. I did notice that the 'format' column has been moved from the node table to node_revisions, so I changed my 'n.format' to 'r.format'.

Heine’s picture

StatusFileSize
new1.94 KB

Rerolled to apply against head + extra bugfixes.

Heine’s picture

StatusFileSize
new1.95 KB

a little change

Heine’s picture

for the record, posting won't work due to a seperate issue: http://drupal.org/node/80271

Dries’s picture

Fixed look good, but I wonder whether using $node->format makes sense? It doesn't mean that we have to break linebreaks, have we? Wouldn't that depend on the configuration of the format itself?

walkah’s picture

Status:Needs review» Reviewed & tested by the community

RTBC - the patch from #6 is good.

@Dries - the parameter (while questionably named) is used to denote which MT filter to utilize - which is analogous to a drupal input format.

Dries’s picture

Version:x.y.z» 4.7.4

Committed to CVS HEAD. Needs to be backported to Drupal 4.7, I think.

Zen’s picture

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new1.79 KB

Backport attached. Untested.

-K

Zen’s picture

Status:Needs review» Reviewed & tested by the community

Setting backport to RTBC.

killes@www.drop.org’s picture

Status:Reviewed & tested by the community» Fixed

applied

Anonymous’s picture

Status:Fixed» Closed (fixed)