Login page redirects back to login page. Cause: wp_users table - ID column is case-sensitive

[icanhazpython]

This is an odd one.

Environment:
Mysql: 5.7.17
PHP: 5.6.29
WP version: 4.1, also present in 4.7

Some of my sites seem to have the ID column in the wp_users table as lowercase id. Now I'm not sure how they got this way and if they were always this way (have not checked source to see table creation specs), but through process of elimination I was able to track down that a lowercase ID field name causes the login page to break, whereas uppercase will allow it to work.

Literally this will break it:
ALTER TABLE wp_users
CHANGE COLUMN id id bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT;

And this will fix it:
ALTER TABLE wp_users
CHANGE COLUMN id ID bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT;

I saw some errors with debug mode on: Undefined property: "stdClass::$ID" in wp-includes/user.php

Now I understand that this may be a case of intentional design, but I have not done any manual editing of my table schema, so I think the decision to be particular in the case of the field names could be waiting to bite someone else.

[icanhazpython]

I found some additional fields in another site's db which cause issues as well (when adding a new post, there is no editor box!):
wp_comments.comment_id -> comment_ID
wp_posts.id -> ID

I think I'm seeing a pattern emerge. These sites are running v4.7 and db_version 38590, but it seems that maybe these fields failed to be migrated. I have not checked migration source code so not sure but that's my guess. Since I've seen this issue on v4.1 as well, it could be that these changes were supposed to be made many versions ago, and were not for some reason.

[markparnell]

Hi @icanhazpython - thanks for the report. It's possible you may be on the right track with a migration issue, though none of those fields have changed since at least 3.7.

However given that it seems to be specific to a handful of sites I'm going to close this.