Don’t store at umeta_id=0 !!!!!!!!!!!!!!!!!!!!!

Resolved designdrumm
(@designdrumm)

5 years, 3 months ago
For the love of God and all you hold dear, please don’t store umeta_id=0!
Please fix ‘wfls-last-login’. I can’t login because you store that usermeta at umeta_id=0.

Well, actually it logs in, but redirects to the login page. This may be on W3TC’s end. Shows successful in DB. The issue is not central to you. W3TC is doing it too (umeta_id=0) and I am going to post the same there.

Common Sense Rule: You never store at ID=0, that is where poorly developed scripts store at!!

🙂

Anxiously await an update. I certainly enjoy your plugin and the protection it provides. Thank you for that and a free version!

Best,
designdrumm
- This topic was modified 5 years, 3 months ago by designdrumm.
The page I need help with: [log in to see the link]

Viewing 6 replies - 1 through 6 (of 6 total)

Thread Starter designdrumm
(@designdrumm)

5 years, 3 months ago
Hello,
Looks like this function is not getting the correct $user array.
$user->ID = 0 when I login.
```
public function _record_login($user_login, $user) {
	update_user_meta($user->ID, 'wfls-last-login', Controller_Time::time());
}
```
This may be due to $user_login being set. It does’t get used, so my thoughts are it’s a variable that was overlooked for removal? It may be that $user_login = (correct user ID). Not positive on this as I do not have time to test.

Best,
designdrumm
Thread Starter designdrumm
(@designdrumm)

5 years, 3 months ago

Hello again,
Looks like W3TC is storing a login session_token at umeta_id=0. Since you guys set your last login meta here, it blocks the session token from being set which causes a DB error and because of the .htaccess it sends me back to the login page.

Also, again I had to delete all your database tables to get back into my site. When I finally got into it and reinstalled your plugin, your new setup prompted me up to 5 times to finish installation. It prompted me on the plugins page and every page in your plugin. Couldn’t get away from it. Finally it took.

My reason for bringing this up is that this issue may be storing something that messes the $user array in the previous problem. Might be a stretch though. 😛

Best,
designdrumm

Thread Starter designdrumm
(@designdrumm)

5 years, 3 months ago

Hello again,
It seem it was an issue with a corrupt and incomplete usermeta table. By deleting and reloading the SQL in phpMyAdmin it seems to have fixed the issue. I also had a user with no usermeta at all. Not sure if this was aid to the issue, but since adding meta, the issue has gone.

Hope that helps someone!

Best,
designdrumm

WFSupport
(@wfsupport)

5 years, 3 months ago

Just to be clear, was this a database corruption issue? If you are using W3TC and database caching we’d recommend turning that off, and aching for known users in general. database caching has been known to cause problems in the past and IMO it doesn’t really do anything to majorly increase site speed in most cases.

Tim

Thread Starter designdrumm
(@designdrumm)

5 years, 2 months ago

The problem is back and I was able to get in by disabling WF completely (deleting and removing the wordfence-waf.php and user.ini, deleting the umeta_id=0 value and clearing the lock tables in WF. Seems the issue is WF locking me out even when I put in the correct U&P. About to delete and move on.

Thread Starter designdrumm
(@designdrumm)

5 years, 2 months ago

Hello again,
Ok, I figured out what was the problem. My usermeta and user tables both did not have Auto_Increment set, so WordPress was storing at umeta_id = 0; When I exported the MySQL, the auto index option did not save to the file and I updated without. Well, that is my theory anyway. Sorry for the noise.

All is fixed now. 🙂

Best,
designdrumm

Viewing 6 replies - 1 through 6 (of 6 total)

The topic ‘Don’t store at umeta_id=0 !!!!!!!!!!!!!!!!!!!!!’ is closed to new replies.