Not sure if I messed something up but anyone not using a strong password (seems to be upper/lower case and special character required) they get an error message that id_member is expecting an integer.
Any clues?
Edit
I remember now I changed it to a stronger password - changed it to medium
hmm... interesting problem!
How could I have missed this!?!?!
That sounds like a bug, let me move the topic.
So what you did is:
1) set up the forum with password requirements "low" (or medium),
2) let some members register,
3) change the password setting from low/medium to strong
And what you have observed is an error:
id_member is expecting an integer.
or something similar, I don't think the exact message is this one, but okay.
I'll try to reproduce it.
Exactly, was working fine til I changed required strength to High then it failed.
Changing back to medium and everything worked fine again.
Error message is exactly that.
I don't think this one is tracked yet for 1.1.6.
This one appears to be caused not by the sequence of events listed, but simply a bug.
When you are on the registration form, and you enter an invalid password (as determined by the ACP password level, high/med/low) the form will show a caution symbol next to the password fields to show they are invalid. Of course the member registering can ignore that and hit submit.
Once they submit with a password that will fail, it will be caught by the registerMember() function and the error(s) set in $reg_errors->hasErrors() registerMember() will return false instead of a memberID.
The current logic does not check for reg_errors and instead trys to log the agreement (and optional privacy policy) to the log_agreement_accept which needs the member id, which is false and you get the above error. I think we can simply move those two logging actions after the error checking.
$lang = !empty($modSettings['userLanguage']) ? $modSettings['userLanguage'] : 'english';
$agreement = new Agreement($lang);
$agreement->accept($memberID, $user_info['ip'], empty($modSettings['agreementRevision']) ? strftime('%Y-%m-%d', forum_time(false)) : $modSettings['agreementRevision']);
if (!empty($modSettings['requirePrivacypolicy']))
{
$policy = new \PrivacyPolicy($lang);
$policy->accept($memberID, $user_info['ip'], empty($modSettings['privacypolicyRevision']) ? strftime('%Y-%m-%d', forum_time(false)) : $modSettings['privacypolicyRevision']);
}
// If there are "important" errors and you are not an admin: log the first error
// Otherwise grab all of them and don't log anything
if ($reg_errors->hasErrors(1) && !$user_info['is_admin'])
{
foreach ($reg_errors->prepareErrors(1) as $error)
throw new Elk_Exception($error, 'general');
}
// Was there actually an error of some kind dear boy?
if ($reg_errors->hasErrors())
{
$this->_req->post->step = 2;
$this->action_register();
return false;
}
// If there are "important" errors and you are not an admin: log the first error
// Otherwise grab all of them and don't log anything
if ($reg_errors->hasErrors(1) && !$user_info['is_admin'])
{
foreach ($reg_errors->prepareErrors(1) as $error)
throw new Elk_Exception($error, 'general');
}
// Was there actually an error of some kind dear boy?
if ($reg_errors->hasErrors())
{
$this->_req->post->step = 2;
$this->action_register();
return false;
}
$lang = !empty($modSettings['userLanguage']) ? $modSettings['userLanguage'] : 'english';
$agreement = new Agreement($lang);
$agreement->accept($memberID, $user_info['ip'], empty($modSettings['agreementRevision']) ? strftime('%Y-%m-%d', forum_time(false)) : $modSettings['agreementRevision']);
if (!empty($modSettings['requirePrivacypolicy']))
{
$policy = new \PrivacyPolicy($lang);
$policy->accept($memberID, $user_info['ip'], empty($modSettings['privacypolicyRevision']) ? strftime('%Y-%m-%d', forum_time(false)) : $modSettings['privacypolicyRevision']);
}
And tracked https://github.com/elkarte/Elkarte/issues/3296
I'm seeming to get this error whenever a user attempts to register, regardless of any other factors. Happens on both 1.1.4 and 1.1.5.
I think it was missed and thus not fixed yet. I believe it will be fixed in 1.1.6.
I fixed this using the solution
@emanuele provided here: https://www.elkarte.net/community/index.php?topic=5510.msg39245#msg39245 So hopefully it will be incorporated into the next version of ElkArte.
It was/is ;)