BlogAPI content submission is broken

This is probably because the "teaser is part of the body" setting is not on by default when submitting the node. This setting is new to Drupal 6.

Note: it looks like what Drupal is doing is using a new "<content>" field in the XLMRPC response.

To retain compatibility with existing desktop blogging clients it should stick to using the standard fields for MT

<description> = the teaser or the full body if no teaser/body split

<mt_text_more> = the full body or empty if the whole body was in the description

This convention is followed by every blog system that supports MT's API, e.g. MovableType, WordPress, etc. So it seems like a mistake for Drupal to diverge here without a great reason.

If this is not fixed it seems like it will essentially break compatibility with all existing desktop blog clients.

Daniel

Hm. Sounds critical. :( Or at least definitely a regression from 5.x. :(

Another thing - I noticed that tags/taxonomy don't work

Possible solution to the node submit part of the problem (ref. #2) here: http://drupal.org/node/216890.

I wanted to post my experiences with a few blogging clients this morning.

From the page (http://en.wikipedia.org/wiki/MetaWeblog), I downloaded two clients more or less at random, depending mostly on what I thought of their names. I set up a fresh copy of 6, enabled both blog module and blog api module, created a new user "user1", and in the blog api settings, checked "page" "story" and "blog entry" as allowable posts from blogging clients. I created a free-tagging vocabulary associated with blog posts. In pemissions, I allowed authenticated users to create all content types, and well as "administer content with blog api".

Using a copy of BlogJet 2.0 I was able to create accounts for the Drupal blogs for both my administrative account and user1. Posting from BlogJet to both blogs went fine. I was able to create long posts in both instances, and the teasers were generated correctly. If I already had a term created due to a previous posting in Drupal, I could associate new posts with that term (but apparently could not create new terms from the client). I could post a blog entry, and then edit the blog entry using the client and it the edited copy was saved fine. Creating a non-published blog entry from the client worked fine.

Using a copy of Anconia Rocket Post, my experience was not as positive. When logged into the client with the credentials of the administrative drupal user, I could post and retrieve the contents of blogs, but my blog entry would be saved in Drupal with the correct title but a body of "1". When logged into the client with the credentials of my Drupal user1, I could retrieve a list of user1's previously posted blogs (created due to my blogjet trial), but when trying to post a new entry, the Rocket Post client would "lock up", or at least hang longer than I wished to wait. This issue only seemed to occur when I was using the user1 account.

I didn't try MarsEdit because I don't have a Mac handy. (This testing is on a Vista platform.)

Perhaps the "locking up" and "body of string '1'" are issues with RocketPost. I'm a little bit concerned that I could "do something" logged in as a Drupal user with full rights and then not have the same thing occur when logged in as (what I believe to be) a properly-permissioned user (even if that "something" was incorrectly posting blog entries that only contain the string "1").

My teasers were formed correctly when posting from BlogJet, so I'm going to provisionally say that perhaps the OP's teaser issue is an issue with MarsEdit? I could well be wrong. There is a lot of variables here. In the interim pending further tests, though, I'm reverting to normal.

Keith - thanks a lot for testing this out. The big issue I observed in Erik's original report to me was that the XMLRPC responses from Drupal did not put the post content into a field, but into a field.

Can you confirm that this is NOT happening? If so, I'm curious to know what about Erik's installation is causing this to happen. Perhaps he has a plugin installed or something?

Erik, it sounds like a really good sanity check would be if you can try posting to your blog from another client besides MarsEdit. For instance, can you try with Ecto?

Daniel

The big issue I observed in Erik's original report to me was that the XMLRPC responses from Drupal did not put the post content into a field, but into a field.

I'm happy to re-test. The XMLRPC responses did not put the post content into a field, but into a ...?

Keith,

the teasers were generated correctly

Do you mean, automatically by Drupal? If so, then how does the node look when you view it in page view in a browser? (i.e. is the teaser missing?)

Also, assuming the teaser is auto-generated by Drupal, if you go to the node via the web interface, hit Edit and immediately hit Split summary at cursor, what is the status of the checkbox?

Yes, after posting long posts using BlogJet, and then viewing them on the web, teasers appeared correctly on the home page, and the entire post appeared when viewing the node. When clicking edit and then hitting "Split summary...", the checkbox is not checked.

On "RocketPost", I couldn't really test this as the body of all my posts were created as the string "1".

Thanks Keith. I'm a bit confused. If the checkbox is not checked, then I wonder how come the auto-generated teaser being included in the post when viewing it in page view? I mean, node.module only sets that checkbox to be unchecked (at the point of node edit form generation) if the teaser extracted from the database isn't the first xxx characters of the body.

When I do this with ScribeFire, the Drupal generated teaser is omitted from the page view of the post ... And is then missing when I view/edit it with ScribeFire. Maybe I need to try BlogJet!

Or maybe I need to do it with something other than "lipsum"ed text -- maybe the entire thing isn't really showing up but I just think it is. I'll go look further.

I hope you don't mind I'm setting the priority back to critical until you can confirm it's behaving correctly. This would be really embarrassing for Drupal if the proposed failure is actually happening.

*sigh*. Indeed, this was poor testing on my part. On further testing, with a piece of text that I can easily identify if it gets split apart in odd ways, the posting behavior from BlogJet is indeed wrong.

Specifically, if I create a long post in BlogJet and then publish it through Blog API to a test site:

• the first 600 characters or so (the default teaser size) appear on /node.
• When viewing the node, I see from where the teaser ended through the last of the post.
• When I edit, before clicking "Split summary at cursor", I see the entire post in the "Body" text area.
• Clicking "Split summary at cursor", the entire post is in the top text area, and the bottom text area is blank. "Show summary in full view" is not checked.

Sorry for derailing this issue. 'Twas just that my original test text all looked alike, so I didn't realize that it wasn't starting correctly when viewing the node.

Likely back to critical then, unfortunately.

Thanks for following up, Keith. I appreciate your dedication to getting the bug correctly identified.

I've posted a patch at the other issue http://drupal.org/node/216890 which attempts to solve the teaser part of the problem via a one-line change in node_submit(). Leaving this issue open

- in case it is decided the problem is in blogapi.module, and that node_submit() is fine as is
- and because Daniel looks to have identified other problem(s) with the blog API at #3 above http://drupal.org/node/216608#comment-714017

I tried the patch from http://drupal.org/node/216890 and left the results in that thread. Essentially, with the patch applied, and repeating the test from #15, the changes were: a) the entire post is seen when viewing the node, and b) "Show summary in full view" is checked after editing the node and choosing "Split summary at cursor".

Whao. 18 followups and noone retitled the issue. XML-RPC is not broken.

Erik, could you test the patch over at http://drupal.org/node/216890 ? (or anyone else who can test with MarsEdit).

Marking this as normal and active needs more info until the patch over there gets fully tested and committed.

Hi Erik,

Fully understand that 6.0 may not be appropriate for you at the present. (We are all still eagerly awaiting the stable release ... date not fixed, but could be within a few weeks - "We hope that this [RC3] will be the final release candidate before we can make an official release of Drupal 6.0." - http://drupal.org/drupal-6.0-rc3.)

The patch over at http://drupal.org/node/216890 has just been committed to HEAD. This means that when the current dev version of 6.x http://drupal.org/node/97368 is automatically updated in a few hours (currently it's still showing last update 31 Jan), it will include the patch.

If you are able (with your webmaster's help?) to test this then it would be a great help. Probably that patch will have fixed the main problem you were having - it would just be good to confirm.

Also Daniel raised some other concerns at #3 above. Any futher comments on those from anyone would be helpful so we can decide whether there is still any issue here that needs attention.

Thanks,
gpk

>bunch of modules that aren't yet out for 6.0
Fair enough!

Meanwhile, thanks for your help with testing.

1. Many MT / MetaWebLogAPI clients have different implementations -- even if you implement the "standard", we sometimes have to implement workarounds (hence the option to support Blogger / MT / or native MWL)

2. Yes, it would suck to ship with this not working. Thanks all for testing.

Note: not being able to create *new* tags / taxonomy terms is expected behaviour. Unfortunately, Metaweblog API doesn't support tag creation in any standards based way. Making an "advanced blog api" (or something) contrib module that we could get blog editors to support would be great. Alternately, parse kind of like mailhandler to include tags in the body and have it stripped out by Drupal before posting.

I've tested the patch at http://drupal.org/node/216890 on Ecto and BlogJet.
It's work fine.

@erikmarcus:
If you wrap a 'p' tag around a line you will get what you need.
Node's body and teaser are stored in a database with "\n" as line breaks.

Maybe you should use WYSIWYG editor in Drupal as TinyMCE (http://drupal.org/project/tinymce) or FCKeditor (http://drupal.org/project/fckeditor). This one preserves paragraph as entered.

I'm having problem posting any blog material via the BlogAPI using MarsEdit on Drupal 6.9. Was Drupal 6 released without this being fixed? This issue just dies off with no follow up.

Closing this issue because of a lack of activity.