Extension talk:ConfirmAccount

From MediaWiki.org
Jump to: navigation, search
Start a new discussion
First page
First page
Previous page
Previous page
Last page
Last page

Could not create directory "mwstore://accountcreds-backend/accountcreds-public/w/wi/wik".

MediaWiki 1.25beta (696dc35) Extension: code from GIT (both master and REL_25)


  • I ran into this problem: Could not create directory "mwstore://accountcreds-backend/accountcreds-public/w/wi/wik"
  • Several persons reported this in older archieved messages, but my file permission are ok (i.e I can upload an image)
  • $wgFileStore to manually specify a directory will not work (has been removed since MW 1_24

Workaround (I find this truly freaky since the version appear to be the same, according to the "version" page in the wiki):

git checkout REL1_24

- cheers ! Daniel

Daniel K. Schneider (talk)13:55, 10 April 2015

I had this exact same problem, and your trick worked for me too.

But why?...

Lajosb (talk)12:12, 14 May 2015

It means the lastest code of the extension is not compatible with your MediaWiki.

Nemo09:54, 15 May 2015

Yes, of course that's what it means, but that's really very odd. Like Daniel, I'm using WM 1.25 and the extension version for WM 1.25 (i.e. the version intended for that MW version) isn't working, while an older version (namely that for MW 1.24) is. In other words, the "right" version doesn't work, while a "wrong" version does.

(By the way, I had this problem also with the WikiForum extension. In that case too the 1.25 version had a problem that was solved by downgrading to the 1.24 version.)

Lajosb (talk)12:00, 15 May 2015

There is no guarantee that extensions work with any version. The branches are just a time approximation.

Nemo16:29, 3 June 2015

Usually that type of error is caused by a permission issue. The extension defaults to $wgUploadDirectory . "/accountcreds" as the directory to use. Make sure that php can create that directory and any subdirectories (e.g. Let the php user [usually www-data] own that directory).

Well $wgFileSotre was removed, you can still set it in LocalSettings.php. The more proper way would be to adjust $wgConfirmAccountFSRepos

Bawolff (talk)02:51, 28 June 2015

Any solution to this? I don't get the comment "git checkout REL1_24", 2 July 2015

Any solution to this? I don't get the comment "git checkout REL1_24", 2 July 2015

How to customize messages in the RequestAccount page?


I would like to give specific instructions for requesting a new account (e.g. to use an institutional email address @domain.org): how could I do that? I can not find any relevant messages in special:allmessages, neither can I find the related text in the UI files.

Many thanks.

JP, 14 May 2015

You can find the strings in the i18 JSON files. If a key "confirmaccount-somekey" has a value you want to change, you can edit MediaWiki:confirmaccount-somekey to override it (see Special:AllMessages).

Aaron (talk)21:29, 18 June 2015

Email notification

I don't get an email to the one specified in $wgConfirmAccountContact. Is there anything else I need to set up for this? Generally sending mails with php works for the rest of my Mediawiki installation.

Here is my configuration:

require_once "$IP/extensions/ConfirmAccount/ConfirmAccount.php";
$wgWhitelistRead = array( 'Spezial:Benutzerkonto_beantragen', 'Hauptseite' );

$wgConfirmAccountSaveInfo = true;
$wgConfirmAccountContact = 'my@email.address';
$wgAutoWelcomeNewUsers = true;
$wgGroupPermissions['bureaucrat']['lookupcredentials'] = true;
$wgGroupPermissions['sysop']['lookupcredentials'] = true;
$wgGroupPermissions['sysop']['confirmaccount'] = true;
$wgConfirmAccountRequestFormItems = array(
# Let users make names other than their "real name"
'UserName' => array( 'enabled' => true ),
# Real name of user
'RealName' => array( 'enabled' => true ),
# Biographical info
'Biography' => array( 'enabled' => false, 'minWords' => 50 ),
# Interest checkboxes (defined in MediaWiki:requestaccount-areas)
'AreasOfInterest' => array( 'enabled' => false ),
# CV/resume attachment option
'CV' => array( 'enabled' => false ),
# Additional non-public info for reviewer
'Notes' => array( 'enabled' => true ),
# Option to place web URLs that establish the user
'Links' => array( 'enabled' => false ),
# Terms of Service checkbox
'TermsOfService' => array( 'enabled' => false ),
Noboddy (talk)09:50, 16 June 2015

Did you wait till the user confirmed their email? Also there was a change in core that broke the extension in terms of sending certain emails. This was fixed in the "master" branches, but some older extensions versions might not work with newer core versions.

Aaron (talk)21:26, 18 June 2015

A database query error has occurred. This may indicate a bug in the software.

I installed ConfirmAccount, all went well. I updated the database via the web.

I tested the account request, and I rejected my test account, and it worked. Today someone requested an account; I wanted to accept it, but when I submit, it gives me that error message: "A database query error has occurred. This may indicate a bug in the software." See screenshot of the error page: http://screencast.com/t/lPU4IyEXjX

Can anyone help? I don't know what to do to fix this issue. Thanks!

FYI my environment info: MediaWiki 1.23.2 PHP 5.3.28 (cgi-fcgi) MySQL 5.1.67-rel14.3-log

OlivierCompagne (talk)22:19, 4 September 2014

I have the same exact version and issue, 1 October 2014

I have this error as well. As far as I can see everything about the confirm account extension seems to work. If I confirm an account to approve it, then I get the same error on the wiki page. Any one understanding this issue and willing to help?

Donkey Kong Genius (talk)10:21, 5 October 2014

Same for me. I have this error for a few days. I deleted all my tables in the db and all files on my space so I have a complete clean installation. But I still can't install mediawiki.

No my error changes from the one above to: Function: DatabaseBase::sourceFile( /home/webpages/lima-city/wod-berlin/html/maintenance/tables.sql ) Error: 1146 Table 'db_287222_1.user' doesn't exist (mysql.lima-city.de)

So what am I supposed to do now?!, 20 October 2014

I have the same problem on a new installation, though I have copied tables from another database. I'm now wondering if that's where the problem lies?

A database query error has occurred. This may indicate a bug in the software.

  • MW 1.24.0
  • PHP 5.3.3 (apache2handler)
  • mySQL 5.1.73
  • Confirm account – (75bdde7) 20:50, 12 November 2014
CookipediaChef (talk)11:48, 3 December 2014

Copied tables? And did you run update.php then?

Nemo21:39, 3 December 2014

I have exactly same problem after upgrade to MW 1.24. Reinstalled confirmaccount, and run update.php but it's not helping

Database error A database query error has occurred. This may indicate a bug in the software.

Query: INSERT INTO `y5m_account_credentials` (acd_user_id,acd_real_name,acd_email,acd_email_authenticated,acd_bio,acd_notes,acd_urls,acd_ip,acd_xff,acd_agent,acd_filename,acd_storage_key,acd_areas,acd_registration,acd_accepted,acd_user,acd_comment,acd_id) VALUES ('682','Ričardas','ryckaxxl60@gmail.com','20141202143609',,,,'',,'Mozilla/5.0 (Windodws NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36',NULL,'soft_escwiki-y5m_:acctrequest:ip:',,'20141201022523','20141204123207','2',,NULL) Function: AccountConfirmSubmission::acceptRequest Error: 1054 Unknown column 'acd_xff' in 'field list' (localhost), 4 December 2014

Same: SELECT COUNT(*) FROM `account_requests` WHERE acr_type = '0' AND acr_deleted = '0' AND (acr_held IS NULL) LIMIT 1 1146 Table 'wiki.account_requests' doesn't exist (localhost), 25 December 2014

So there is no way to fix it?

Tymek1988 (talk)10:25, 16 December 2014

ALTER TABLE /*_*/account_credentials ADD COLUMN acd_xff VARCHAR(255) NULL default ;

Aaron (talk)00:17, 25 December 2014

This did not fix my mediawiki 1.22.6 install.

Grantbow (talk)14:53, 3 April 2015

Same Problem. Read somewhere we can try to create these fields manually. Could someone give us the field definition ? (Type, attribute, Null, Default...) Thanks !

tiix13:11, 13 April 2015

I not only have that issue, but I'd get the same message when I clicked the Recent Changes link, until I commented out the extension., 9 May 2015

I had this same error. I noticed it right after blocking several of what I thought were fictitious users.

After further review I figured out what was causing the error. Someone at my work created an account without updating any pages so I blocked them thinking they were also a fictitious user. Well, when I blocked them I also blocked their IP address & since we have a static IP at my work that caused me to unintentionally block myself which was ultimately causing in the error message. After unblocking the user with the same IP as mine my problems went away.

Mojorhino (talk)12:37, 25 March 2015

how to set multiple $wgConfirmAccountContact?

I would like two admin users to be notified when a user tries to make an account. How do I set $wgConfirmAccountContact = to multiple users? Should I use an array? eg $wgConfirmAccountContact = array("admin1@gmail.com" , "admin2@gmail.com");

LTech (talk)10:08, 26 April 2015

If the array doesn't work, you can set up an email alias; if you don't control the domain, you can set up a forward to both addresses from a single email address of pretty much any email provider.

Nemo11:24, 27 April 2015

German Mediawiki 1.24.2

The update script does not create the new database tables. Please assist

[[User:Bmrberlin| Bernd M.]] (talk)11:52, 14 April 2015

Userpage is created even if its empty

Edited by another user.
Last edit: 22:24, 8 January 2015

To avoid this, you must change: /ConfirmAccount/business/AccountConfirmSubmission.php.

Function createUserpage() the last part must look like this

#Create userpage!
if( !empty($body) ) {  // <- new
$article = new WIkiPage( ...
$article->doEdit( ...
}  // <- new, 8 January 2015

I'll just make a patch for that in gerrit.

Aaron (talk)04:49, 11 February 2015

Problem with emails after unistalling ConfirmAccount

Dear MW users,

we've have test this great extension ConfirmAccount on our wiki, but we then realize that it doesn't suit our current needs...

We then uninstall it following the usual procedure: http://www.mediawiki.org/wiki/Manual:Extensions#Uninstalling_an_extension

Unfortunately, after this a strange thing occurs: when a new user try to register, it seems he/she doesn't received any email with the confirmation link... Well, I said "it seems" because in truth the situation is kinda weird: if a user try to register with a Gmail email address it works coorectly (email is received by the users), but if he/she use a different one, the email doesn't arrive (We have try with addresses @yahoo.com, @hotmail.com, @live.com, ...)

This thing is getting us crazy... anyone has an idea of what's going on ? Any suggestion about what we should check to fix this problem ? Please Help

Many thanks in advance for any helpful tip


PS Yes, of course we've checked if the emails were in the spam folders, but they werent..., 7 February 2015

Does the sender email address you are using have a SPF policy?

Nemo20:11, 7 February 2015

Dear Nemo,

thanks a lot for your reply... we don't know actually if/which the sender email address used have a SPF policy

Anyway, your comment remided us that we have the email server for our domainame located elsewhere, not on the same cloud server where our Mediawiki is installed (and pointed trough the same domainame for which we have modified DNS accordingly).

Said this, do you think such a configuration could be the reason of the weird behaviour we're experiencing ?

In that case, what about this: http://www.mediawiki.org/wiki/Manual:$wgSMTP

Do you thinkit could be the way to go to set thing correctly ?

Thanks again for your kind support


PS By the way, in the meantine we tried to add $wgUserEmailUseReplyTo = true; to LocalSettings.php and like thatwe add a little improvement: like that it now works for @gmail.com and @yahoo.com, but it is still not working for @hotmail.com, @live.com, @libero.it, @virgilio.it, ...

3biano (talk)15:44, 9 February 2015

Well, it's possible the server you are using is blocked; maybe SpamHaus can tell you if your IP had problems in the past. There are many websites around the web which ask users to only register with gmail because all the others block their emails.

So, yes, using Manual:$wgSMTP to configure a "trusted" email sender will hopefully help, though I can't be sure.

Nemo19:06, 9 February 2015

Language selection with $wgLoginLanguageSelector

Edited by another user.
Last edit: 11:54, 15 January 2015

How can I have the language selection available with $wgLoginLanguageSelector=true with the ConfirmAccount extension? With the default direct account creation it was possible, but after installing ConfirmAccount the language selection disappeared... Thanks a lot in advance for any suggestion

Fabio, 14 January 2015

Did you try Extension:UniversalLanguageSelector?

Nemo11:54, 15 January 2015
Edited by another user.
Last edit: 12:31, 7 February 2015

Dear Nemo,

thanks for your reply... yes we had a look to that extension as well by it didn't suit the model we have in mind for our wiki

Here is an alternative we found possible helpful: https://www.mediawiki.org/wiki/Extension:LanguageSelector

Fabio, 7 February 2015

Successful registration with same email id twice.

This is a bug, right? Is this the problem of extension or the mediawiki s/w?, 4 February 2015

Same email but different username? If the usernames are different, there is no limit to the number of times an email address can be used for MediaWiki accounts. So, yes, a MediaWiki core thing.

Nemo09:26, 7 February 2015

Is it possible to add more fields to the sign up form?

Does this extension provide options to add more fields to the signup form? If yes, then how? If no, then do I have any other option?, 4 February 2015

AreasOfInterest not showing up in the form

I have enabled areas of interest in Localsettings.php using 'AreasOfInterest' => array( 'enabled' => true ), but it didn't show up in the form., 3 February 2015

How is the From addess derived?


This is a really great extension! I have a question though, how does the extension determine the from address? I'm having problems with an ISP blocking messages because they don't like the from address in the confirmation emails.

Many thanks.

Mitchelln (talk)11:46, 20 January 2015

It uses the address set in $wgPasswordSender.

Nemo15:08, 22 January 2015

How to deny access to login-type-signup page or redirect to requestAccount page?

I added to LocalSettings.php code from Enhancements (https://www.mediawiki.org/wiki/Extension:ConfirmAccount).
So I don't have direct link to register page. But if I go to login -> I can see a button which is link to http://localhost/mediawiki/index.php?title=Special:Login&type=signup -> and on this page anonymous user can register himself, what I don't want. Does anyone have any idea, how to always redirect from this site to site with RequestAccount?

I have:
MediaWiki 1.23.0
PHP 5.3.28 (cgi-fcgi)
MySQL 5.5.40
Confirm User Accounts – (Version d7bd12d)

Monic abc (talk)13:50, 22 December 2014

By "site", do you mean "page"?

Nemo08:25, 23 December 2014

Yeah, sorry for my English. :P

Monic abc (talk)09:06, 23 December 2014

Well, some extensions do things like:

31-             if ( !$this->hasPermissionToUse() ) {
32-                     if ( $this->getUser()->isLoggedIn() ) {
33:                             $out->redirect(
34-                                     Title::newFromText( $wgTranslateSecondaryPermissionUrl )->getLocalUrl()
35-                             );

You could probably code your conditions and execute them via an appropriate hook.

However I'm not convinced this is really what you need: if "anonymous user can register himself" for real, you didn't configure your MediaWiki correctly. Pleae read the documentation again and check that you did as it says:

  • put the configuration in the correct order in your LocalSettings.php,
  • don't add $wgGroupPermissions['*']['createaccount'] = true; or similar.
Nemo12:09, 25 December 2014

Thanks for reply. ;)
1. Configuration in correct order? Which lines of code are important and their order can change something?
2. I only have these lines with word createaccount:

   $wgGroupPermissions['*']['createaccount'] = false;
   $wgGroupPermissions['sysop']['createaccount'] = false;
Monic abc (talk)12:51, 9 January 2015

1.23.6 Upgrade error

Everything Food & Drink
MediaWiki 1.23.5
PHP 5.3.28 (cgi-fcgi)
MySQL 5.5.37-35.1
Lua 5.1.5

Catchable fatal error: Argument 3 passed to ConfirmAccountUIHooks::setRequestLoginLinks() must be an instance of SkinTemplate, none given in /public_html/w/extensions/ConfirmAccount/frontend/ConfirmAccountUI.hooks.php on line 27

Just tried the 1.23 version and am getting same error.
Mlpearc (open channel)08:47, 3 November 2014

How delete a rejected user with a confirmed email?

Hello all!

I used some test users with real email addresses to check extension to work properly (and it works :-). Now all email addresses are in recently rejected cue: is it possibile to remove them? Can i remove them manually or there is an automatic scheduled process (if yes how long does it takes)?

Thank you in advance for any reply.

Midimarcus (talk)18:31, 23 September 2014

I anyone found a solution yet. I would also like to know how to please, 3 October 2014

Why do you want to remove them?

Nemo12:38, 3 October 2014

Same question: I would like to test a few times after a recent upgrade, and I have already used up 3 email addresses. How can I purge the email address history and rejected username history? Thanks!, 16 October 2014

How do I set language strings with the latest version?


I've just upgraded to MW 1.23.3 and the latest version of ConfirmAccount (rev. 34ddc24). I ran update.php.

With an older version, the language strings could be set via Special:AllMessages by searching for "request". Now if I do that nothing is returned. So how do I set the language strings now?


Mitchelln (talk)10:18, 23 September 2014

Reminder for anyone reading: system messages are translated on translatewiki.net.

If Special:AllMessages is not working, you have a bug. However, you can always look up the message keys in the extension's json files or on translatewiki.net and visit/edit them directly, for instance MediaWiki:requestaccount-page (of course on your wiki, not here). Can you link your wiki?

Nemo17:34, 23 September 2014


Thanks for the reply. It looks like it is definitely a bug then. On two wiki's I've upgraded MW to 1.23.3 and ConfirmAccount to rev 34ddc24 the localisation strings no longer appear in Special:AllMessages

I can edit them direct via MediaWiki:requestaccount-page, for example. Thanks for the info :)

Unfortunately the wikis are internal, so I cannot provide a link to them.

Mitchelln (talk)10:52, 25 September 2014

I can confirm my account

Fatal error: Call to undefined method ConfirmAccount::getAdminsToNotify() in /home/soft/public_html/escforumwiki/extensions/ConfirmAccount/frontend/specialpages/actions/RequestAccount_body.php on line 364

What I am doing now? :(, 17 September 2014

$wgGroupPermissions error

In section Configuration. Note: Sysops can still create accounts directly. To disable this, add to LocalSettings.php:

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

This causes an error message on 1.23.2 "Notice: DB transaction callbacks still pending (from User::invalidateCache)."

Instead $wgGroupPermissions['*']['createaccount'] = false; Still allowing only sysops to create accounts works fine.

Rob Kam (talk)11:46, 12 September 2014

Error with confirmaccont


I'm getting the following error trying to run the extension:

PHP Catchable fatal error: Argument 3 passed to ConfirmAccountUIHooks::setRequestLoginLinks() must be an instance of SkinTemplate, none given in /var/www/kennyburgess-wiki/extensions/ConfirmAccount/frontend/ConfirmAccountUI.hooks.php on line 28

Any ideas?, 11 July 2014

Same here., 10 September 2014

For future reference: I fixed the error by making VERY SURE I installed the correct version of ConfirmAccount for my wiki! I was installing one 2 minor numbers too new., 10 September 2014
First page
First page
Previous page
Previous page
Last page
Last page