WordPress.org

Support

Support » Installation » [Resolved] 1.5.12 and ecto

[Resolved] 1.5.12 and ecto

  • I was just upgraded to 1.5.13 and am now unable post using ecto. When I save the post and try to publish it, I get this error – “Parsing failure! Could not parse response for “metaWeblog.newPost”. Please check the console log for more information.”

    I quit and restarted ecto and was prompted that 2.3.6 was available. Downloaded and installed … same error and inability to post.

    The only change was the upgrade to the new version of ecto.

    Also, the post ID in ecto is now a 14 digit number rather than the next expected post ID (613, 614, 615).

    Please advise and thank you in advance. My guess is that I will need to revert to the previous version but was curious whether anyone else has seen this.

    Thank you,
    Jim
    http://www.realcentralva.com

Viewing 15 replies - 1 through 15 (of 54 total)
  • I am having a similar problem with BlogJet. I get this error:

    Error Posting to Blog:
    TResult.GetString – Item is not a string type

    here is the error I am getting in the Console log –

    Response:

    <b>Fatal error</b>: Call to a member function on a non-object in <b>/home/realcent/public_html/xmlrpc.php</b> on line <b>548</b>

    Downgrading to WordPress 1.5.1.2 is strongly discouraged.

    Several folks are looking into the specifics. Stay tuned, please.

    xmlrpc.php was changed quite a bit due to the security fixes. I’m sure Matt and Ryan will take a look into this since its probably just a typo after all the changes made yesterday.

    I am unable to confirm this problem on a test install, so I’m setting up another one locally.

    Using an unmodified 1.5.1.3 install of WordPress, I was able to post with BloGTK from a Debian GNU/Linux workstation.

    I still can’t reproduce this, but I think that skippy may have found a potential fix and I’m posting it to the wp-hackers mailing list. If someone cares to contact me via email with access information to a test install so I can test the solution, my email is false.hopes@gmail.com

    Alright, I was just able to reproduce the problem, and I have a potential fix. If anyone could apply this patch and test it out it’d be greatly appreciated.

    Index: branches/1.5/xmlrpc.php
    ===================================================================
    — branches/1.5/xmlrpc.php (revision 2672)
    +++ branches/1.5/xmlrpc.php (working copy)
    @@ -502,13 +502,11 @@

    global $wpdb, $post_default_category;

    – $this->escape($args);

    – $blog_ID = $args[0]; // we will support this in the near future
    – $user_login = $args[1];
    – $user_pass = $args[2];
    + $blog_ID = $wpdb->escape($args[0]);
    + $user_login = $wpdb->escape($args[1]);
    + $user_pass = $wpdb->escape($args[2]);
    + $publish = $wpdb->escape($args[4]);
    $content_struct = $args[3];
    – $publish = $args[4];

    if (!$this->login_pass_ok($user_login, $user_pass)) {
    return $this->error;

    Updated xmlrpc.php available here. Try that out.

    hi,
    I can confirm that at least updating entries works fine with the patch (updating entries was broken before as well).

    I’ve just posted to another thread
    http://wordpress.org/support/topic/37772?page=1
    But this updated xmlrpc.php has another problem of systematically adding default category even if other categories are selected. A problem similar to the one reported before:
    http://trac.wordpress.org/ticket/1355
    I’ve commented out line 567 for the moment to prevent this.

    Oops, I thought it worked but it actually doesn’t.
    I got to put back my old 1.5.1.2 version xmlrpc.php after all.

    There are still problems with the xmlrpc-file.
    I managed to work around the category problem described above by commenting the lines that contain the else-block responsible for the category-behaviour.

    However, I’m not able to add images using ecto or marsedit.
    the file is uploaded correctly, but the data seems to get messed up during decoding. If I try to open the file stored on the server, my graphics-app (GraphicConverter) tells me, that the file is broken and that it does not recognize the file format.
    The image is not displayed in browser apps as well (neither firefox nor safari).

    Don’t get me wrong, but if so much was changed in the rpc-api there should’ve been much more testing prior to releasing this buggy implementation…

    But if you’re blog was compromised, you would fuss that a security release was not issued fast enough. The devs and all of the volunteers are doing the best they can, but nobody is perfect. If you think you can do better, then please, step up.

    Also, Nothing was changed about the API, there was a security issue which involved non-escaped content being allowed through.

    Security issues don’t mean the basics of software release go out of the window. Assess/Develop/Test/Test/Release. The ball was dropped here and you certainly don’t tell users to “step up” to do it themselves – that’s just petulant and immature and theres no need, it’s not going to get the issues resolved.

    As someone with an interest in seeing this fixed, I’d love for the usual jingoism to just not get started.

Viewing 15 replies - 1 through 15 (of 54 total)
  • The topic ‘[Resolved] 1.5.12 and ecto’ is closed to new replies.
Skip to toolbar