Skip to:
Content
Pages
Categories
Search
Top
Bottom

Deleting Users results in Malformed SQL Syntax

  • I am upgrading an old .83 bbpress installation to Alpha 1.0r6.

    I have about 6k posts in the .83 database.

    After upgrading the database I’ve noticed the following problems. Several of the posts in the database were made by users no longer in the database. If a topic containing posts by these now ‘anonymous’ users is displayed, I get the following error at the top of the screen.

    DB Error in wp_users::append_meta: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '32) /* WP_Users::append_meta */' at line 1

    SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (1,,32) /* WP_Users::append_meta */

    If I delete the anonymous posts in the thread, the problem goes away. Using PHPAdmin I checked the user ID’s assigned to the posts and there are no users with those user ID’s in wp_users. (I have an integrated installation).

    I thought the problem was a result of an upgrade, so I created a new user, made some posts, and then deleted that user. The problem still exists. I have not tried this on a clean install and it would be useful if someone could try that.

    I am running the default Kak. Blue theme.

    I believe I tracked the problem request to a backpress file.

    bb-includes/backpress/class.wp-users.php:

    if ( $metas = $this->db->get_results("SELECT $meta_field, meta_key, meta_value FROM {$this->db->$meta_table} WHERE $meta_field IN ($ids) /* WP_Users::append_meta */") ) {

    I am not a SQL sleuth but I believe the $ids field is being populated with nulls associated with deleted users.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Just did a clean install of 1.0r6 w/ the same WP2.7 user tables and saw no problem.

    There must be some issue as a result of the upgrade from 0.83

    Additional info:

    Following the error, the page displays fine with the exception of user roles and the link to the user profile. All are listed as invalid, with the exception of the user that is logged in.

    The malformed SQL request is listing the user ID’s in the thread. The ID’s are in order of post appearance. Once an anonymous post is in the sequence it fails to insert the userID.

    Another example is below:

    SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (17,23,1,18,) /* WP_Users::append_meta */

    The fifth post in the topic is an anonymous poster with no corresponding wp_user or wp_usermeta information but it appears a null is inserted in the request rather than the legacy user ID.

    If I look into the database and examine topics and posts made by anonymous users the legacy user ID’s are there. bb_posts has the old user IDs for the posts made by deleted users . Somehow, this data isn’t making it into the request.

    I never found the source of the problem, but was able to find a solution.

    I used the Manage -> Recount function in the BBPress interface and recalculated all parameters. After doing this, things appeared to work.

    Perhaps this function should be called whenever there is a database upgrade.

    Turns out the Manage -> Recount didn’t solve the issue.

    I did a clean install of BBpress integrated with WordPress and reproduced the problem. I failed to reproduce the problem the first time since I only had two users.

    Try this on a clean install-

    0. Use keymaster account to write a two posts under two topics.

    1. Create user #2.

    2. Login user #1 and create two posts under same two topics written by user #1.

    3. Using wordpress admin delete user #2.

    4. Create user #3 and log in as user #3.

    5. Display topics.

    6. Note that the keymaster account is ‘inactive’. This is a result of the SQL request for the account level failing.

    Hi,

    I got around this issue, by doing this:

    File : bb-includes/backpress/class.wp-users.php

    Line: 307

    $ids = join(‘,’, array_keys($trans));

    The leading comma caused issues in the SQL query so I put an ltrim in front:

    $ids = ltrim(join(‘,’, array_keys($trans)), ‘,’);

    Error went away:)

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