Support » Fixing WordPress » admin delete problem

  • I have a clean install of wp 1.0, and have only edited the index.php template and the permalink_link() and comments_popup_link() functions to point at a new page.
    My problem:
    when i’m logged in as a user or admin and try to delete a post, i get the following

    SQL/DB Error:
    [You have an error in your SQL syntax near '' at line 1]
    SELECT * FROM wp_posts WHERE ID =
    SQL/DB Error:
    [You have an error in your SQL syntax near '' at line 1]
    SELECT * FROM wp_users WHERE ID =
    Warning: Cannot add header information - headers already sent by (output started at /opt/www/dev.site.com/html/wp-includes/wp-db.php:106) in /opt/www/dev.site.com/html/wp-admin/post.php on line 419

    where line 419 or post.php is

    header ('Location: ' . $sendback);

    seems like the sql errors and the header error are seperate…. has anyone seen anything like this, or know how to fix???
    btw.. i’ve verified that the post_id and user_id are available for the sql by simply echo’ing them in where they are used in the ‘delete’ case in post.php.
    thanks

Viewing 4 replies - 1 through 4 (of 4 total)
  • I have seen the same problem in one of my installations, but I have a test installation that does not have the problem. The only difference I know of is that I changed my nickname for admin on the system with the problem while on the test system I created a separate user for myself… besides the different base system name differences. I’ll diff the two installations and see if I can notice anything of interest. Even with the error messages my posts are deleted.
    I believe I tried to delete a post as admin on my test system, but I will double check that.

    I changed line 377 of wp-admin/post.php to be:
    $postdata = get_postdata($post_id) or die(‘Oops, no post with this ID. <
    a href=”post.php”>Go back!’);
    instead of using “get_postdata($post)” and the errors went away. This seems to confirm why the deletion worked since it was when it was trying to get data about the post that the error occured. I don’t know why this works on my test installation without change. My mysqldump output seems to confirm this works now as intended.

    I should note that this is now fixed in the latest nightly build I checked.

    yup, that fixed it… thanks a bunch!

Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.