WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#2962 closed defect (bug) (invalid)

"Resetting" a blog and re-running install.php does not work

Reported by: RuddO Owned by:
Milestone: Priority: normal
Severity: major Version: 2.0.3
Component: Administration Keywords:
Focuses: Cc:

Description

I encountered a problem using WP 2.0.3 + nonce fixes patch. It's basically the following:

  1. delete all the WP tables' contents using delete from wp_...
  2. re-run install.php to have the tables repopulated with default values
  3. try to log in with the newly created admin user

You can log in, but you can't access any of the admin pages (You do not have sufficient permissions... that menu.php prints).

This is what's going on, after running install.php:

mysql> select * from test_usermeta;
+----------+---------+-------------------+---------------------------------+
| umeta_id | user_id | meta_key | meta_value |
+----------+---------+-------------------+---------------------------------+
| 5 | 1 | test_user_level | 10 |
| 6 | 5 | test_capabilities | a:1:{s:13:"administrator";b:1;} |
+----------+---------+-------------------+---------------------------------+

As you can see, the row keyed 6 is using the user_id 5 (non-existant, probably taken from some autoincrement in MySQL). The test_users table has the following:

mysql> select * from test_users;
+----+------------+----------------------------------+---------------+-------------------+----------+---------------------+---------------------+-------------+--------------+
| ID | user_login | user_pass | user_nicename | user_email | user_url | user_registered | user_activation_key | user_status | display_name |
+----+------------+----------------------------------+---------------+-------------------+----------+---------------------+---------------------+-------------+--------------+
| 1 | admin | 65313ed4218de7c45b1425624632756b | admin | asantos@… | | 2006-07-20 18:18:17 | | 0 | asantos |
+----+------------+----------------------------------+---------------+-------------------+----------+---------------------+---------------------+-------------+--------------+

so you can see the correct user ID is 1.

A simple

mysql> update test_usermeta set user_id = 1;

fixes the issue.

I admit, and I know, emptying a table does not guarantee that the autoincrement counter will be reset. But this simple fact shouldn't have any impact on WP performance.

Who knows what other kinds of bugs like this lie around in WP's source code?

Change History (10)

comment:1 @masquerade9 years ago

  • Resolution set to invalid
  • Status changed from new to closed

Do not clear your tables with delete from ..., clear your tables with TRUNCATE TABLE. This is not a bug, its a user error, if you want to reinstall, delete the tables altogether or truncate them, which confirms that they have the right autoincrement start values.

comment:2 @markjaquith9 years ago

While I agree that you should drop the tables if you want to re-install, it's not good practice to assume things, like auto increment values.

comment:3 @masquerade9 years ago

The general pain and hassle that forcing WordPress itself to verify consistancy across all tables is more than I think is worth it to add. This is precisely what Foreign Keys are for, but unfortunately without forcing table types and higher MySQL versions we can't take advantage of this, and writing all the code to enforce this within WordPress is just too great a hassle.

Plus, you don't need to even drop the tables to reinstall, a truncate will do, its just deleting every row that isn't the same.

comment:4 follow-up: @RuddO9 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Hold on just a sec, are you telling me that

  • wordpress inserting the admin user with ID = 1
  • then wordpress inserting admin user's usermeta keys with ID != 1

is OKAY, irrespective of the autoincrement key?

While I know that TRUNCATE should have been the "blessed" way to reset my blog, the error pointed above is due to a lack of robustness. I posit that inserting a row with ID 1, and subsequently inserting rows that should have had ID 1, with another ID, is a bug, not a user error.

Instead of quickly closing the bug, you could at least have taken a look at the code, could you?

comment:5 @RuddO9 years ago

Just for completeness, this is the behavior I'd expect.

If, upon install.php, WP is going to insert an admin user with an ID of 1, it should use the same fixed ID for all tables which have user_ID as a foreign key.

ALTERNATIVELY, it could also insert the admin user whie letting the database generate the ID key via autoincrement, and then retrieving and using the autoincremented ID *everywhere* else.

Both courses of action would also let me DELETE FROM instead of TRUNCATE.

But the currently implemented "middle ground" behavior is clearly wrong.

comment:6 @skeltoac9 years ago

RuddO, your point may be valid but your approach is caustic. You won't get cooperation that way. If you want it done, put up or lighten up.

comment:7 @technosailor9 years ago

+1 to skeltoac.

RuddO, You presented what you percieved to be a bug. The folks here have looked and said it's not something they want to tackle. Now the ball is in your court. It seems you know what you want and would be best. Please feel free to submit a patch. Every patch is looked at and considered irrespective of who submits it.

comment:8 @foolswisdom9 years ago

  • Milestone changed from 2.0.4 to 2.2

comment:9 in reply to: ↑ 4 @rob1n8 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

Replying to RuddO:

Hold on just a sec, are you telling me that

  • wordpress inserting the admin user with ID = 1
  • then wordpress inserting admin user's usermeta keys with ID != 1

is OKAY, irrespective of the autoincrement key?

It's not "OKAY," it means you didn't clear your tables correctly. TRUNCATE resets the auto_increment values.

While I know that TRUNCATE should have been the "blessed" way to reset my blog, the error pointed above is due to a lack of robustness. I posit that inserting a row with ID 1, and subsequently inserting rows that should have had ID 1, with another ID, is a bug, not a user error.

User error. It's not the "blessed" way, it's the COMPLETE way.

Instead of quickly closing the bug, you could at least have taken a look at the code, could you?

There's no code with in WP for user errors.

comment:10 @rob1n8 years ago

  • Milestone 2.2 deleted
Note: See TracTickets for help on using tickets.