Forum Replies Created

Viewing 15 replies - 1 through 15 (of 39 total)
  • Thread Starter rdsmes

    (@rdsmes)

    Sanjeev,

    Thanks for the response. I had thought about maybe uploading the new version ‘by hand’ to resolve the problem, thinking, as you did, that the plugin hadn’t been updated correctly. At the time, I did not do that, however, as my priority was on getting the old version of the plugin reinstalled – and I was trying to do this over a very slow internet connection.

    I was surprised by the error, as I found it a bit difficult to believe that the code would have a ‘missing class’ error! Those types of errors wouldn’t be around for very long…

    Thanks again for the response – I will try the update again when I get a chance.

    Try deactivating plugins that add panels below the edit box. I had the same problem — it was an old version of the LiveJournal crossposter plugin. Deactivated the plugin and the edit window came back. Upgraded the plugin and all is well.

    Interestingly enough, the edit box came up ok in old IE7, but not in new FF or IE.

    I know this is digging up an old thread, but this ‘check’ as quoted by Viper007Bond seems flawed to me:

    It checks the database for the latest comment from your IP or e-mail address and then compares the timestamp to the current time.

    If that’s true (and that’s what it looks like the code in comment.php does to me) than ANY two users that submit comments within the time period would trigger the error IF they BOTH were to leave the EMAIL field blank, no?

    The only reason I’m looking at this is that I think I just got bit by it on my own blog – where I submitted a comment and got flagged with the ‘too quickly’ error, but hadn’t submitted an earlier comment. But another user had submitted a comment just a second or two earlier…

    Just asking the question. Maybe I misunderstand the check, but if it uses IP address OR email address, it seems to me that two quick comments, both with blank email fields, would be flagged as being too close together, no matter where they came from.

    Thread Starter rdsmes

    (@rdsmes)

    I added that to the fact that Akismet wasn’t mentioned in the 2.0.7 release as one of the files that had changed.

    Sorry for asking for what seemed to me to be a rather obvious question, one for which I should apparently have divined the answer.

    Consider the issue resolved.

    Thread Starter rdsmes

    (@rdsmes)

    Kafk…

    You’re probably right – part of my confusion came when I checked the download page at Akismet.com. It says: “The latest version of the plugin is 1.2.1.”.

    But the version that is actually downloaded is the 1.8.1 included in the WP 2.0.7 package.

    Maybe it’s just me, but that IS a bit confusing, is it not?

    I would assume that post_id is an autoindex. An autoindex in a table can be reset via query. Check this post on another topic.

    The only one I know of is this one:

    http://wordpress.org/support/topic/61431/page/2#post-337727

    in which case the offending post had the word “curl” in it – which mod_security did not like.

    Nick –

    I think that line has a few too many double-quotes in it. Try either:
    echo "<option value=$thisM";
    or
    echo '<option value='.$thisM;

    Hawke –

    I can only speak to my experience, in which I was seeing a 404 error on the redirection after using ‘save and continue’ and then doing a ‘save’ or ‘publish’ operation – with the URL containing the long mySQL error string. I did not see a blank page.

    In that case, yes, the fix that Ryan placed into the Trac system is working for me, as were the temporary patches. I could reliably reproduce the error, and it is now gone. It is possible that some of the other posters in this thread are seeing different problems.

    silversihde –

    I’m just curious – did this 403 show up in your server error log, and did that give you any clue?

    RavanH and others –

    If you’re seeing the 404 problem after you have used the save-and-continue feature (with the long mySQL error string at the end of the URL), there has already been considerable discussion on this matter, and a fix has been entered for testing.

    Check this post from Ryan in the other thread for the developers’ proposed change to correct the problem.

    Ryan,

    Thanks for the change info. I figured that when I and Technosailor had proposed patches that they were just patches, and not necessarily the preferred fix for the problem.

    I’m running your change to the classes file on my site now, and have removed my patch to the functions file. Your change does seem to correct the problem – at least in my case, it was happening every time I used ‘save and continue’.

    Hope we were able to help point you in the right direction…

    rodrigomuniz-

    Read back through this thread and you’ll find a full discussion of the error and a patch to try.

    That’s important information, since there seems to be some confusion over WordPress-generated 404 errors, server generated 404s and browser timeouts.

    Perhaps WordPress should consider using a message that give a little more info than the 404 – Not Found to help users to distinguish the difference. They all have different causes.

    That looks like it should be a perfectly legit address for the ‘write post’ page for your site, doesn’t it? Have you looked in the server error log to see if the 404 error is in there? Does the 404 error page look like it comes from your site or is it a more generic Apache error page?

Viewing 15 replies - 1 through 15 (of 39 total)