Extension talk:ConfirmAccount

About this board

Summary by Seb35

Not an error in ConfirmAccount.

Therotintheroot (talkcontribs)

Hoping this is an easy one. Here is the backtrace. Happens when I hit the "Create Account" button.

[Yve--N0CrNL3S_ildqFUjAAAABM] /wiki/index.php?title=Special:CreateAccount&returnto=Special:ConfirmAccounts/authors Error: Call to undefined method User::setOption()


from /usr/local/www/apache24/data/wiki/skins/Vector/includes/Hooks.php(220)

#0 /usr/local/www/apache24/data/wiki/includes/HookContainer/HookContainer.php(338): Vector\Hooks::onLocalUserCreated(User, boolean)

#1 /usr/local/www/apache24/data/wiki/includes/HookContainer/HookContainer.php(137): MediaWiki\HookContainer\HookContainer->callLegacyHook(string, array, array, array)

#2 /usr/local/www/apache24/data/wiki/includes/HookContainer/HookRunner.php(2370): MediaWiki\HookContainer\HookContainer->run(string, array)

#3 /usr/local/www/apache24/data/wiki/includes/auth/AuthManager.php(1503): MediaWiki\HookContainer\HookRunner->onLocalUserCreated(User, boolean)

#4 /usr/local/www/apache24/data/wiki/includes/auth/AuthManager.php(1217): MediaWiki\Auth\AuthManager->continueAccountCreation(array)

#5 /usr/local/www/apache24/data/wiki/includes/specialpage/AuthManagerSpecialPage.php(376): MediaWiki\Auth\AuthManager->beginAccountCreation(User, array, string)

#6 /usr/local/www/apache24/data/wiki/includes/specialpage/AuthManagerSpecialPage.php(502): AuthManagerSpecialPage->performAuthenticationStep(string, array)

#7 /usr/local/www/apache24/data/wiki/includes/htmlform/HTMLForm.php(726): AuthManagerSpecialPage->handleFormSubmit(array, VFormHTMLForm)

#8 /usr/local/www/apache24/data/wiki/includes/specialpage/AuthManagerSpecialPage.php(435): HTMLForm->trySubmit()

#9 /usr/local/www/apache24/data/wiki/includes/specialpage/LoginSignupSpecialPage.php(314): AuthManagerSpecialPage->trySubmit()

#10 /usr/local/www/apache24/data/wiki/includes/specialpage/SpecialPage.php(671): LoginSignupSpecialPage->execute(NULL)

#11 /usr/local/www/apache24/data/wiki/includes/specialpage/SpecialPageFactory.php(1378): SpecialPage->run(NULL)

#12 /usr/local/www/apache24/data/wiki/includes/MediaWiki.php(315): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)

#13 /usr/local/www/apache24/data/wiki/includes/MediaWiki.php(912): MediaWiki->performRequest()

#14 /usr/local/www/apache24/data/wiki/includes/MediaWiki.php(563): MediaWiki->main()

#15 /usr/local/www/apache24/data/wiki/index.php(53): MediaWiki->run()

#16 /usr/local/www/apache24/data/wiki/index.php(46): wfIndexMain()

#17 {main}

Therotintheroot (talkcontribs)

Nevermind, I fixed it. Skin was bad. Sorry for the noise!

ConfirmAccount missing on Login page (1.38)

SyncmasterN (talkcontribs)

I did not get the chance to check in earlier versions (v1.35) if the Login button does indeed appear.

Checked the workaround posted here: https://www.mediawiki.org/w/index.php?title=Topic:Voy0tmnffcrokxf2&topic_showPostId=vp08ljyllv3j6g6j#flow-post-vp08ljyllv3j6g6j but it's already fixed.

The settings used:


// If your MediaWiki version is 1.25 or higher, use this line:

wfLoadExtensions([ 'ConfirmEdit', 'ConfirmEdit/QuestyCaptcha' ]);

# The following permissions were set based on your choice in the installer

# Disable reading by anonymous users

$wgGroupPermissions['*']['read'] = false;

# But allow them to read e.g., these pages:

$wgWhitelistRead = [

        "Main Page",




# Disable anonymous editing

$wgGroupPermissions['*']['edit'] = true;

# Prevent new user registrations by anyone

$wgGroupPermissions['*']['createaccount'] = false;

#Confirm new Users settings (CONFIRM EXTENSION)


$wgConfirmAccountContact = 'email_account@gmail.com';

$wgGroupPermissions['administrator']['confirmaccount-notify'] = true;

$wgGroupPermissions['bureaucrat']['confirmaccount-notify'] = true;

$wgRejectedAccountMaxAge = 0;

$wgMakeUserPageFromBio = false;

#$wgAutoWelcomeNewUsers = true;

$wgConfirmAccountRequestFormItems = [

        'UserName'        => [ 'enabled' => true ],

        'RealName'        => [ 'enabled' => true ],

        'Biography'       => [ 'enabled' => false, 'minWords' => 50 ],

        'AreasOfInterest' => [ 'enabled' => false ],

        'CV'              => [ 'enabled' => false ],

        'Notes'           => [ 'enabled' => true ],

        'Links'           => [ 'enabled' => false ],

        'TermsOfService'  => [ 'enabled' => true ],


Any ideas how to check what is going wrong?

Product Version
MediaWiki 1.38.2
PHP 7.4.19 (fpm-fcgi)
MariaDB 10.6.7-MariaDB
ICU 60.3
Lua 5.1.5
Pygments 2.11.2

I am using the new Vector Skin (2022)



Reply to "ConfirmAccount missing on Login page (1.38)"

ConfirmAccount missing on Login page (1.35)

Rrosenfeld (talkcontribs)

On upgrading from 1.31 to 1.35 I have the problem, that the link to the ConfirmLogin special page (requestaccount-loginnotice) is missing on the login special page.

I tracked this down to includes/frontend/ConfirmAccountUI.hooks.php where addRequestLoginText() should add this information to the hook. But addRequestLoginText() is never called in 1.35 (tried it out by adding a division by zero error at the top of addRequestLoginText() in both 1.31 and 1.35. Any idea, what I'm doing wrong? Anything that I have to do to enforce using the hooks?

For testing reasons I tried with a freshly created LocalSettings.php with only ConfirmLogin extension enabled but with the same result: No link to Special:RequestAccount in the login form, so this should hurt every user here...

Escalatr (talkcontribs)
Reply to "ConfirmAccount missing on Login page (1.35)"

Email address confirmation doesn't update 'user_email_authenticated'

TazzyTazzy (talkcontribs)

I'm using ConfirmAccount and ConfirmEdit extensions. Right now, when a user requests an account, they get an email asking them to confirm their email address. After clicking it on, the admin will get a notification of a new account request. After admin creates thew new account, the password is sent to the user. However, there account is still marked as not having email confirmed. In the database, the user entry for that user in the user table shows the field 'user_email_authenticated' as null while this should have a timestamp.

If the user goes through their preferences, it still says "Your email address is not yet confirmed. No email will be sent for any of the following features." If they click on that, they get yet another email asking them to confirm their email address. Eventually, this then confirms their email address and updates the database.

Why is there a need for double email confirmation? Versions: MediaWiki: 1.36.2 Confirm User Accounts: – (3195e5a) 11:46, October 7, 2021 Confirm Edit: 1.6.0

TazzyTazzy (talkcontribs)

I've implemented this quick fix in my localsettings.php.

# Automatically set the user's email as validated since they have to get validated through ConfirmAccount.
# Must have "$wgGroupPermissions['*']['createaccount'] = false;" per ConfirmAccount extension.
$wgHooks['LocalUserCreated'][] = 'onLocalUserCreatedEmailAutoConfirm';
function onLocalUserCreatedEmailAutoConfirm( $user, $autocreated ) {

This should work since anon users can't create accounts, only admins. This also fixed the issue of the user being redirected to create an account after changing their temporary password.

Reply to "Email address confirmation doesn't update 'user_email_authenticated'"

[SOLVED] Request account button not showing up on main page for 1.34 -- working for 1.33

Paulette00 (talkcontribs)

I must have done something idiotic but somehow I can't make the "request account" to appear for potential new users. The mediawiki (1.34) setup is private. The extension is also 1.34 compatible. Permissions are set up as:

$wgGroupPermissions['*']['read'] = false;


$wgWhitelistRead = array(

  "Special:Request account",

  "Spécial:Demander un compte"


What is missing ?

Many thanks.

Spas.Z.Spasov (talkcontribs)

Hello, please read this post of mine. I think it could help.

Paulette00 (talkcontribs)

Ok thanks, I've seen it, and I don't have errors (when for example using mediawiki:loginprompt to make the request account page appear).

Nevertheless, I'll have a go at what you suggest, and report here.

Paulette00 (talkcontribs)

Hello, I did do as you suggested by adding/rewriting the hook to display the RequestAccount button. I did not touch at the ConfirmEdit bit: there are no errors showing up in the logs.

But the whole lot didn't work.

However: this feature worked with the MW version 1.33. I did not check when upgrading to 1.34 if the the feature was still alive. So, to make sure, I replaced the ConfirmAccount directory from 1.34 by the one from 1.33. And .... it did work. So I don't really know what's happening here: a quick diff on both directories didn't enlightnen me.

Conclusion: I stay with ConfirmAccount 1.33 until I have better ideas...

Paulette00 (talkcontribs)

Here we go, I found my answer (got it of course from comparing 1.34 with 1.33):

in frontend/ConfirmAccountUI.hooks.php, line 32:


if ( isset( $personal_urls['login'] ) ) {


if ( isset( $personal_urls['login'] )

        || isset( $personal_urls['login-private'] ) ) {

... which shows that the problem originated from my wiki being private!

MyWikis-JeffreyWang (talkcontribs)

Strange how this bug has yet to be fixed in REL1_35. This makes ConfirmAccount essentially useless for private wikis. Being private doesn't mean the button shouldn't appear.

Rrosenfeld (talkcontribs)

The above patch solved the issue for me too, but I had to learn first, that the "Request Account" button has moved from above the login form (where it was in 1.31) to the upper right corner of the screen (where I didn't expect it after using 1.31)...

Flyingratchet (talkcontribs)

Thank you—this was a lifesaver! This was still a problem for me in version 1.36

Reply to "[SOLVED] Request account button not showing up on main page for 1.34 -- working for 1.33"
BAMaustin (talkcontribs)

The "Interaction diagram of a successful account creation process." illustration in Extension:ConfirmAccount#Usage does not include any New User "talk page" creation. It is the most persistent place to that the Admin/bureaucrat has to give newbie instruction to the new account holder about how to begin editing.

Our site's welcome message is a "Welcome to Gramps! We hope you will contribute much and well. You will probably want to read the help pages. Again, welcome and have fun! <approving admin name> (talk) <datestamp>"

Pretty useless. We've created a "Welcome survey" transclusion template but have to manually add it after each new user creation. (See https://www.gramps-project.org/wiki/index.php/User_talk:JohnRSibert)

But it has been SO long since the site was set up that we cannot find where to customize this message. The Manual:User creation page does not any obvious place detailing the New Account creation process... it says what triggers the User creation but does not have a flowchart of the overt steps performed by the wiki nor how to find documentation on controlling those steps.

I'd really appreciate a section on this Extension:ConfirmAccount page that lists the template pages (or documentation pages) used to generate content communicating with a new account applicant.

It should be easier to find all the interaction generators/templates if admins/bureaucrats want to customize the verbiage on:

  • the new account web request form
  • the eMail sent to the admin (so they can add links to New User Approval policy or blacklisted user lists)
  • the confirmation eMail sent to a New User
  • the Welcome message created on the New User's Talk page
  • the temporary password eMail
  • the log-on and change password page

I also do not know if these are the same communications that the user normally sees from the MediaWiki during "direct account creation". Googling for that "direct account creation" term only finds the ConfirmAccount extension documentation. Is there a searchable term for this process?



Reply to "Update interaction diagram"
Grlucas (talkcontribs)

Hello, I'm getting the following when using the plugin. Any suggestions for addressing it would be appreciated.

[bddb5397a66d499e1af05db6] /wiki/Special:RequestAccount Error: Call to a member function timeanddate() on null


from /home/litwnaqg/public_html/extensions/ConfirmAccount/includes/backend/ConfirmAccount.class.php(121)

#0 /home/litwnaqg/public_html/extensions/ConfirmAccount/includes/business/AccountRequestSubmission.php(256): ConfirmAccount::sendConfirmationMail(User, string, string, string)

#1 /home/litwnaqg/public_html/extensions/ConfirmAccount/includes/frontend/specialpages/actions/RequestAccount_body.php(343): AccountRequestSubmission->submit(RequestContext)

#2 /home/litwnaqg/public_html/extensions/ConfirmAccount/includes/frontend/specialpages/actions/RequestAccount_body.php(83): RequestAccountPage->doSubmit()

#3 /home/litwnaqg/public_html/includes/specialpage/SpecialPage.php(646): RequestAccountPage->execute(NULL)

#4 /home/litwnaqg/public_html/includes/specialpage/SpecialPageFactory.php(1386): SpecialPage->run(NULL)

#5 /home/litwnaqg/public_html/includes/MediaWiki.php(309): MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext)

#6 /home/litwnaqg/public_html/includes/MediaWiki.php(913): MediaWiki->performRequest()

#7 /home/litwnaqg/public_html/includes/MediaWiki.php(546): MediaWiki->main()

#8 /home/litwnaqg/public_html/index.php(53): MediaWiki->run()

#9 /home/litwnaqg/public_html/index.php(46): wfIndexMain()

#10 {main}

MarioSuperstar77 (talkcontribs)

Apparently, you are missing a line of text from the error log. Maybe you're missing a dependency?

If you could, it would be interesting if you would give out more information since I am wondering whether you installed the extension fresh out of the box or it suddenly stopped working after you updated MediaWiki.

Grlucas (talkcontribs)

@MarioSuperstar77 I installed a fresh version on an upgraded wiki. I installed per the instructions and all goes well until I actually try to use it, producing the backtrace above. I just rechecked.

Scottsmithnorwich (talkcontribs)

Hello, I am getting the same errors and new users cannot request accounts. I do not have ConfirmEdit running yet. I have tried the work arounds on the extension page (actually completely broke my page). I then removed the extension and reinstalled with the latest version of the extension and still have the same issue.

Did something break with the update to Mediawiki 1.36.1?

Grlucas (talkcontribs)

@Scottsmithnorwich Sorry for your trouble, but glad to see I'm not the only one.

Anyone have any idea about this?

Reply to "MW 1.36.1 Internal Error"

Captcha result is ignored when submiting account creation request

MyWikis-JeffreyWang (talkcontribs)

It seems like there's some issues with ConfirmAccount working with ConfirmEdit. Namely, the captcha value doesn't need to be valid in order to be submitted! Topic:Vky60p231ng9i1i4 seems to report the same issue. I can confirm this is not only affecting QuestyCaptcha but also other types such as hCaptcha, and affects versions between MediaWiki 1.31 and 1.35.

Apparently this has been an issue for nearly 4 years. https://phabricator.wikimedia.org/T168783

MyWikis-JeffreyWang (talkcontribs)

Borrowing Kghbln's terminology in another thread, an immediate but not final solution is offered here for hCaptcha only. (It is not very pretty and needs a lot of revising to commit to the codebase, but it works as a patch.) Make patches to the following files by replacing their contents with the contents in the link:

MediaWiki 1.35+:

MediaWiki 1.31:


1. You might ask, how would I get hCaptcha working on MediaWiki 1.31 when it is only for MediaWiki 1.35+?

Simple, just make sure you change line 139 protected function addCaptchaAPI( (as seen at https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/blob/master/hCaptcha/includes/HCaptcha.php#L139) to public function addCaptchaAPI(. That's it! Follow instructions for installing hCaptcha as normal otherwise and ignore the fact that it is only made for 1.35+. Another issue might appear that will cause pages such as Special:CreateAccount to error with the call to the addCSPSources() method on line 41 of HTMLHCaptchaField.php, but it can be fixed by removing that function call, since MediaWiki 1.31 doesn't offer support for this (as seen at https://github.com/wikimedia/mediawiki-extensions-ConfirmEdit/blob/master/hCaptcha/includes/HTMLHCaptchaField.php#L41).

2. Why does this patch only work for hCaptcha?

The way that ConfirmEdit and ConfirmAccount work together currently to "handle" captchas (or more precisely, don't handle captchas) is not easily fixable. This interim solution simply enables the form to accept the necessary captcha fields and adds a cURL request to the hCaptcha endpoint and evaluates its response. This was pretty easy to implement without referring to too many ConfirmEdit configuration variables and functions. We only made this patch for hCaptcha because MyWikis has moved to using hCaptcha on all wikis instead of QuestyCaptcha or reCAPTCHA. Our reasons for this choice are listed on our blog, and in our experience, reCAPTCHA is useless and has long been cracked by spambots. If you have a compelling reason for us to develop a temporary patch for QuestyCaptcha, leave a message below.

3. Are there any known issues with this patch?

I should note there is a small bug where hCaptcha doesn't populate the token passed along in the form submission if you previously submitted the form and ConfirmAccount gave you an error. But the patch makes up for it by adding an error message that encourages the user to leave and come back to the page to try again. Plus, nobody would be submitting the page without a captcha done in the first place except by mistake.

Reply to "Captcha result is ignored when submiting account creation request"

IPv6 // Error 1406: Data too long for column 'acr_storage_key' at row 1 in tables "account_requests" and "account_credentials"

Kghbln (talkcontribs)

There seems to be an issue in some environments for MW 1.35.x, probably also for other versions. Tracked with task T275522.

Kghbln (talkcontribs)

Turns out that the extension is not yet up for requests from users with IPv6. :|

Kghbln (talkcontribs)

An immediate but not final solution is offered at task T275522

Reply to "IPv6 // Error 1406: Data too long for column 'acr_storage_key' at row 1 in tables "account_requests" and "account_credentials""

How do I a make the Real Name a required field

Ken Roy (talkcontribs)

How do I make the Real Name a required field in the MW 1.35 LocalSettings.php. I have the following

defined in LocalSettings.php after the extension is loaded

## option to create User: page set to true

$wgMakeUserPageFromBio = true;

## option to create User talk: page set to true

$wgAutoWelcomeNewUsers = true;

$wgConfirmAccountRequestFormItems = [
    'UserName'        => [ 'enabled' => true ],
    'RealName'        => [ 'enabled' => true ],
    'Biography'       => [ 'enabled' => true, 'minWords' => 1 ],
    'AreasOfInterest' => [ 'enabled' => false ],
    'CV'              => [ 'enabled' => false ],
    'Notes'           => [ 'enabled' => false ],
    'Links'           => [ 'enabled' => false ],
    'TermsOfService'  => [ 'enabled' => true ],

In testing I am able to submit a request account with an empty field for the real name, which we use in the User: profile

Extension:ConfirmAccount page indicates

The default values are in ConfirmAccount.config.php, but you should not edit that file.

but I am not able to find that file.

Reply to "How do I a make the Real Name a required field"