After disabling user ID=1 I'm not able to login

@vanetreg

Every now and then a topic is started about this issue.

Despite several attempts I have never been able to exactly pinpoint the cause of this issue. Believe me I’ve tried …
Set up several test envs but the feature worked flawlessly EVERY TIME.

So here is the bottom line based on my experience with this issue.

Only follow my instructions below when the browser address bar shows:

http(s)://www.domain.com/wp-admin/profile.php

… while the “You do not have sufficient permissions to access this page.” message is displayed.

Log into your database using phpMyAdmin.
In the left panel click on the wp_usermeta table.

Make sure that for the meta_key ‘wp_capabilities’, and for the user you are trying to login with, the meta_value is set to:

a:1:{s:13:”administrator”;b:1;}

I would very much appreciate your feedback on this ??

dwinden

@dwinden
Thank you for your solution.

First I wait for others reaction and tickets, checking whether it is a common problem related to the plugin upgrade or only I experienced it for another reason.

Thanks,
V.

@vanetreg

I’m pretty sure this issue has nothing to do with the plugin upgrade.
No need to change anything yet, but you can check what I asked and provide feedback. I might be the only one responding to this issue …

dwinden

@dwinden

I haven’t found meta_key named ‘wp_capabilities’, but I found 2 instances of ‘ui4_capabilities’. The 2 values are:
a:14:{s:13:”administrator”;b:1;s:26:”wpcf_custom_post_type_view”;b:1;s:26:”wpcf_custom_post_type_edit”;b:1;s:33:”wpcf_custom_post_type_edit_others”;b:1;s:25:”wpcf_custom_taxonomy_view”;b:1;s:25:”wpcf_custom_taxonomy_edit”;b:1;s:32:”wpcf_custom_taxonomy_edit_others”;b:1;s:22:”wpcf_custom_field_view”;b:1;s:22:”wpcf_custom_field_edit”;b:1;s:29:”wpcf_custom_field_edit_others”;b:1;s:25:”wpcf_user_meta_field_view”;b:1;s:25:”wpcf_user_meta_field_edit”;b:1;s:32:”wpcf_user_meta_field_edit_others”;b:1;s:9:”translate”;b:1;}
a:1:{s:13:”administrator”;b:1;}
Pls. note that the first value is really long, you have to scroll horizontally!
If I’m not mistaken and the user_id column in DB record identifies the user and the first, bolded key value belongs to me, what means the value is not what you wrote, so I might have to modify as you suggested!

If you want to keep investigating the issue, I have a hint what can be ‘wpcf_custom_p..’.
I suppose it is related to WP-Types pack and possibly its access management component named Access
So it might ba a plugin conflict…

So you recommend to modify that key ‘ui4_capabilities’ to what you wrote?

Thank you,
V.

@dwinden

Instead of doing what you suggested I restored a staging copy, updated all plugins I had to and in iThemes Security I again modified user ID=1. The problem again appeared.

Pls. note I use this plugin with Types pack on another sites, there have been user IDs changed earlier, months ago, and those sites doesn’t show this problem neither after updating to v.5.1.0.

Best,
V.

No, I didn’t expect this, but it is an interesting development.
Do not change anything yet. We need to properly figure this out first.

a:14: means your user has 14 capabilities … one of them (the first one) is administrator. So that actually looks good. The rest of the capabilities display is truncated (wpcf_custom_p..) by phpMyAdmin.
It seems there is a customization applied to wp_capabilities by another plugin. It seems to be replaced with ‘ui4_capabilities’. So it’s very well possible this issue is a plugin conflict.

Find out what the current user ID is of the user that previously was ID 1.
Based on the info provided so far I think there are only 2 users in your WP env.
But I’m not sure about that. Please verify in the wp_users table.

Anyway check in wp_usermeta table there is a meta_key ‘ui4_capabilities’ for the new ID that used to be ID 1 …
A bit complicated but I hope you understand …

One last thought … perhaps the conflicting plugin requires a user with ID 1 … which would mean the iTSec plugin Change Admin feature cannot be applied in such WP env without breaking login …
If this is true the only way to fix the issue may be restoring a database backup.

dwinden

Just for your understanding, I posted without noticing your last post.

dwinden

I restored again my working staging copy and checked database field value again.
In the first case, when the problem appeared my user_id was 3, after restoring backup, it was 1.
The restored key value is, I haven’t checked but I suppose they are the same:
a:14:{s:13:”administrator”;b:1;s:26:”wpcf_custom_post_type_view”;b:1;s:26:”wpcf_custom_post_type_edit”;b:1;s:33:”wpcf_custom_post_type_edit_others”;b:1;s:25:”wpcf_custom_taxonomy_view”;b:1;s:25:”wpcf_custom_taxonomy_edit”;b:1;s:32:”wpcf_custom_taxonomy_edit_others”;b:1;s:22:”wpcf_custom_field_view”;b:1;s:22:”wpcf_custom_field_edit”;b:1;s:29:”wpcf_custom_field_edit_others”;b:1;s:25:”wpcf_user_meta_field_view”;b:1;s:25:”wpcf_user_meta_field_edit”;b:1;s:32:”wpcf_user_meta_field_edit_others”;b:1;s:9:”translate”;b:1;}

So you might be right, some older component versions of Types pack didn’t require user_id=1 but from some date the new versions do.

I keep open this ticket for some days and I will mark it resolved next week.

Thanks,
V.

@vanetreg

If you require no further assistance please mark this topic as ‘resolved’.

dwinden

@dwinden
I hope the problem (“some older component versions of Types pack didn’t require user_id=1 but from some date the new versions do.”) is solved and will not appear again.
I haven’t tested it.
I close the ticket,
thank you for your help!
V.