Extension talk:ConfirmAccount/LQT Archive 1


 * Archive 1

Update
Could you please modify the system message calls in confirmaccount_body.php into these:
 * $wgOut->setPagetitle( wfMsg( "requestaccount" ) );
 * $wgOut->addWikiText( wfMsg( "requestaccount-dup" ) );
 * $wgOut->addWikiText(wfMsg( "requestaccount-text" ) );

That way it would become possible to use Templates in the calls. Thanks! --130.233.141.220 08:13, 19 June 2008 (UTC)
 * Templates in the title? hehe ;) Aaron 00:33, 20 June 2008 (UTC)
 * OK, did the others. Aaron 00:34, 20 June 2008 (UTC)
 * Thanks, enabling that gives a lot of possibilities to config the looks of the account requests etc :-) 83.145.207.200 20:56, 10 August 2008 (UTC)

Localizing account creation look and feel
It strikes me that editing the account creation text would be one of the most desired things to do, even for an administrative newbie like me who has no Template management experience at all. Personally, I would welcome in this discussion page some brief elementary best practices (or a link thereto) for simple changes to the distributed message text, in ways that might minimize pain should I fetch a later version of ConfirmAccount. For example, if I simply want to add or change some text to one of the fields in $wgConfirmAccountMessages, is the proper route to adjust that field in LocalSettings.php? --Bob 13:52, 23 August 2008 (UTC)

By the way, in v 1.41, there is message text "submited" where "submitted" is intended. Also a few fields in $wgConfirmAccountMessages have names beginning with "requestacount" instead of "requestaccount". I can imagine this could cause pain, no matter how brief, for someone who didn't notice that when coding against it. --Bob 13:52, 23 August 2008 (UTC)


 * Late answer: try to find the string you want to modify in the ConfirmAccount folder in the file ConfirmAccount.i18n.php. For example, to modify the legend "Personal information" search for this string, finding the key 'requestaccount-leg-person' in front of it. Go into the wiki and modify the URL of a page, changing the page name to, e. g., "MediaWiki:Requestaccount-leg-person". Modifying the content of this page will change the string that is used in ConfirmAccount. --G.Hagedorn 21:32, 11 December 2008 (UTC)

What to do with previous users
I got this trying to connect : « wfConfirmAccountsNotice ». MySQL a renvoyé l’erreur « 1146 : Table '12345.wiki_account_requests' doesn't exist (localhost) », probably due to that my own Username hasn't been checked yet...--NewMorning 21:58, 28 June 2008 (UTC)
 * Sounds more like you haven't made the tables in ConfirmAccount.sql. FunPika 22:05, 28 June 2008 (UTC)
 * True : had not carrefully red : "Replace /*$wgDBprefix*/ with the proper prefix"
 * Many thanks, --NewMorning 11:39, 29 June 2008 (UTC)

Default settings for config options?
What are the defaults? It would be nice to know to stop the config getting cluttered ;-) --Dmb 16:52, 30 July 2008 (UTC)
 * D'oh! "The default values are in SpecialConfirmAccount.php" - Perhaps this text could appear first? (its a big list...) hrm... that gives me an idea... --Dmb 16:59, 30 July 2008 (UTC)

This extension together with LDAPAuthentication extension
Using this extension together with the LDAPAuthentication extension is not optimal. We want to achieve ldapauthentication for users that have passed the ConfirmAccount steps ie been approved by the wiki sysop. So we have turned off the autocreation of users that tries to logon to the wiki and use their LDAP password, if they now use the Confirmaccount request form the username they fill in will be checked against the LDAP server and the message back is that the username already exists. That's true that it exist in LDAP but not in the wiki, this scenario is good but lacks one thing and that is that the request form can't be sent.

The check against LDAP is good, we now know that it's a real id on the account form, and now we need to be able to send the account request to the wiki sysop that will apply or reject the request. After an apply of the request the user can login with his username and ldap password.

there should be an check, if the username doesn't exist in the wiki database but exists in LDAP the request form should be sent. If the username doesn't exist in LDAP the request form should not be sent. And if the username exist in wiki database or in request queue, the request form should not be sent.

For the moment I just commented the code that made the check if user exist in LDAP and it works as I want, but I loose the possibility to just allow LDAP users to make requests. Any comments/advise on this ?

regards Hex
 * I can make a configuration variable for this. However, it will need to check that the local and global (ldap) accounts have the same password. Aaron 15:28, 23 August 2008 (UTC)


 * I do not see why the account password in the wiki must match the ldap password.

After the account is created, the user will logon with his ldap userid (which will be the same as is wiki id) and the password will be authenticated against the ldap server.

The user will not receive the created wiki password in the confirmation mail, so he/she will be unaware of it or at least not know it.

The local password will not be used at logon. Only ldap authentication is allowed.

We don't have access to add a LDAp id, just userid/password validation.

The matrix of how we wanted to have the account creation in wiki when using LDAPAutentication and ConfirmAccount together. WIKIid        LDAPid           Result account creation

No            NO               Deny creation of account in wiki  (request form will say nothing for the moment)

NO            YES              Allow creation of account in wiki

Yes           NO               Dup id in wiki deny creation in wiki (request form will say userexists)

YES           YES              DUP id in wiki deny creation in wiki (request form will say userexists) I have now altered the code in RequestAccount_body.php like this around line 261

This let the user submit the reuquest form without getting the message that the account exists (in LDAP)

He will unfortunatly not get a message that the account doesn't exist in LDAP if it's really doesn't exist in LDAP, but the form can't be submitted.

if( 0 != $u->idForName ) { $this->showForm( wfMsgHtml('userexists') ); return; }	       if( !$wgAuth->userExists( $u->getName ) ) { return; } Also needed to change ConfirmAccount_body.php around line 432 This let the sysop to confirm the request and get the wiki account created, the same goes here about the message to the sysop if the ldap account really doesn't exist (should only happend if ldap account is deletet since the request was done).
 * 1) Check if already in use disabled code by hex new code below
 * 2) 	if( 0 != $u->idForName || $wgAuth->userExists( $u->getName ) ) {
 * 3) 		$this->showForm( wfMsgHtml('userexists') );
 * 4) 		return;
 * }
 * 1) new code by hex

# Check if already in use disabled code by hex new code below #	if( 0! = $user->idForName || $wgAuth->userExists( $user->getName ) ) { #		$this->showForm( wfMsgHtml('userexists') ); #		return; #	}		   # new code by hex if( 0 != $user->idForName ) { $this->showForm( wfMsgHtml('userexists') ); return; }	   if( !$wgAuth->userExists( $user->getName ) ) { return; } I must also say thank You for this extension

/hex
 * If you don't check the passwords, then any person can create an account in the name of an LDAP users and then be treated as that user. Aaron 22:32, 28 August 2008 (UTC)
 * We do validation against LDAP, so if someone creates an account request of another id and that reguest is approved and the user has confirmed the email address, then when logging on with the ldap id you must know the password of the ldap id, not the local password (never used and is never mailed out to user, ie local password id unknown to all)

Invalid confirmation code. The code may have expired.
I'm testing ConfirmAccount on my local wiki prior to deploying it to my site. When my test user clicks the link in the e-mail, a page opens with the message:

“Invalid confirmation code. The code may have expired.”

My test site was using 1.11 and my main site is using 1.13, I just tried upgrading the test site in case that might be the problem. I'm still getting this error message.

What am I overlooking? --RKH 14:45, 26 September 2008 (UTC)

Resolution
I discovered the solution. I didn't have timezone set in PHP so when submitting the account request, MediaWiki displayed an error message box in red, noting that timezone wasn't set. Apparently that also caused problems with the ConfirmAccount confirmation code. When I set the timezone in PHP.ini, ConfirmAccount worked correctly.

Conclusion: You MUST set a valid timezone in order for ConfirmAccount to work correctly. --RKH 16:50, 26 September 2008 (UTC)

Error in code?
Hi. when i want to confirm a new user, th efollowing error massage occurs: Fatal error: Call to undefined method User::addNewUserLogEntry in /Users/patrick/Sites/mediawiki/extensions/ConfirmAccount/ConfirmAccount_body.php on line 561 how to fix? (by the way, i use MediaWiki 1.13.1 and the German localization)--89.196.67.174 05:56, 30 September 2008 (UTC).


 * You've already stated your problem...incompatible versions of extensions and MediaWiki software. You're attempting to use trunk (bleeding-edge) version of ConfirmAccount with an older, non-trunk version of MediaWiki software. You'll either have to use the branched version of ConfirmAccount extension or upgrade your wiki to trunk (see download from SVN for info on how to do that if you decide so...also be aware that trunk might even be broken at times). -- Sayuri 07:56, 30 September 2008 (UTC)


 * I'm also receiving this error with MediaWiki 1.13.2

Resolution
Without having this tried myself I'd say you need to edit "ConfirmAccount.i18n.php" and look for the entry "requestaccount-submit" in the $messages Array. Replace the text after the "==>" with what you desire.

--GangMan 07:56, 21 October 2008 (UTC)

Desired Additional Options
Aaron thanks for developing the MediaWiki extension. We are looking at implementing your ConfirmAccount extension for the TNG Wiki and would like to see the following options added


 * to the Request Account
 * optionally make List of websites, if any (separate with newlines): a required input field that would be used instead of the bio for creating the User:userpage
 * make some of the Request Account messages variables to allow localization of the request (as mentioned in Localizing account creation look and feel above)


 * to the create User:userpage
 * optionally add the Real Name as the first field in the User:userpage
 * optionally add a message line from a variable, such as My Genealogy Web Sites
 * optionally add the web site URLs from the List of websites, if any (separate with newlines):

so the userpage would look something like the following User:Ken Roypage

While we might be able to hack your extension to accomplish this, we would prefer not to have to modify the code.

TIA, Ken Roy

Reject or hold reason not showing in queue
Were any of the Extension_talk:ConfirmAccount/archive_1 added? Specifically was #3 in their list, the reason for Reject or Hold added to the review queue?

If it has not, we would also like to see this feature added to the ConfirmAccount Extension, since we also think that is critical for the other Reviewers to know why a request was rejected when it is received again as a different username.

Thanks

Ken Roy
 * You have to click the "(Review)" link (after the dates) to see it. Aaron 13:06, 9 October 2008 (UTC)


 * Thanks, I initially did not see the information, since I was looking in the comment box. Information shows as Rationale given to applicant: Thanks for the quick response. Ken Roy

No Special Page Exists error
I have followed all of the instructions to install this extension, but when I navigate to the special pages, I receive an error that says that none of the pages exist. What am I doing wrong? 99.141.103.173 22:48, 27 October 2008 (UTC)

Account Confirmation gets stuck after accepting.
Hi everyone,

I was just wondering, I installed this extension and everything seems to be working the way described.

I do have an issue when accepting new users. I open the https://mywiki/wiki/upgrade/index.php/Special:ConfirmAccounts and go to confirm the new account requests. It takes me to the user request, where I hit the confirm button at the bottom. Then it take me to https://mywiki/wiki/upgrade/index.php/Special:ConfirmAccounts/authors where nothing, it's a blank page. The user gets the confirmation email with the Password. After exiting the page, the request I just accepted is still in the queue. Is there something I'm doing wrong?

Thanks for help!
 * Probably an issue with https. Voice of All 18:45, 13 November 2008 (UTC)

Ok, I removed Require SSL and the ReWrite Rule, now it's just http. Same issue exists.

Thanks for the suggestion, anything else it could be?

I'm able to reject and hold, the only part not working properly is the confirm.

Here is more information about my install:
 * Product 	Version:
 * MediaWiki 	1.13.2
 * PHP 	5.1.6 (apache2handler)
 * MySQL 	5.0.45
 * Installed extensions:
 * Confirm user accounts (Version 1.46) 	Gives bureaucrats the ability to confirm account requests 	Aaron Schulz
 * wikicalendar 		Christof Damian
 * Add 'error_reporting( E_ALL | E_STRICT );' to localsettings.php Voice of All 07:16, 22 November 2008 (UTC)

Error in trying to use reCaptcha with ConfirmAccount
Hi Aaron,

Thank you for developing the ConfirmAccount extention. It appears it will meet our TNG Wiki needs. However, when I attempted to install the reCaptcha extension, it only appears to work when in Edit, but not for the ConfirmAccount, which returns a fatal error. When the debug variable is included, the traceback returned is shown in the problem I reported on the Support Desk.

Any clue as to where I need to look in order to resolve this issue will be greatly appreciated.

TIA, --Ken Roy 03:22, 27 November 2008 (UTC)
 * Use the current version of ConfirmEdit, not the one bundled with reCaptcha. Voice of All 06:59, 27 November 2008 (UTC)
 * Aaron, Thank you so much for your response, which did in fact resolve my problem. --Ken Roy 15:27, 27 November 2008 (UTC)

I might note here, having the same problem and not finding the available resolutions to be thorough enough, here is a step-by-step explanation of how I finally got it to work.

Downloaded and installed latest version of reCaptcha according to directions on the reCaptcha site. Downloaded and installed latest version of ConfirmEdit from here. Downloaded and installed latest version of ConfirmAccount from here. Here was the key for me. Copied ConfirmEdit.php, ConfirmEdit.i18n.php, and ConfirmEdit_body.php into the recaptcha directory. I did -not- need the configuration line for ConfirmEdit.php in my LocalSettings.php file. That just seemed to make things worse. Now it all works for me as I would think it was intended. - AsaJay

"log in / create account" link in Personal navbar missing
After installing ConfirmAccount plugin the link in the personal navbar (top right hand corner of page) changes from "log in / create account" to "log in". Any idea how to change this back, so that it is easy for users to see how to register? I tried editing in Special:Allmessages but to no effect. Many thanks for such a great plugin! Tommcd 11:21, 12 December 2008 (UTC)
 * Edit MediaWiki:Nav-login-createaccount. —Emufarmers(T 11:45, 12 December 2008 (UTC)

Feature request: make requestaccount-urls part optional
We like to support providing some confidential information in a request, but find a separate field for urls distracting and adding to barriers to participation. We currently change the requestaccount-urls legend text to tell users to ignore the next field, but we would prefer to be able to hide the field altogether. Can an additional "if( $wgAccountRequestExtraURLs )" be added to the code? We track mediawiki through subversion, so manual code modification is not desirable. Many thanks! --G.Hagedorn 15:17, 13 December 2008 (UTC)

Fatal Error after confirming
This extension works well; smoothly integrates with MW and does exactly what I need. Not sure if anyone else gets this error after approving a user's application, though -

Fatal error: Call to undefined method User::addNewUserLogEntry in (snip)\wiki\extensions\ConfirmAccount\ConfirmAccount_body.php on line 568.

The user is actually created, so I can keep working but obviously it looks horrible to see a fatal error. I'm running MediaWiki 1.13.3 with PHP 5.2.0 on Windows (yeah, the email setup was a PITA), plus Confirm User Accounts 1.46. Line 568 looks like a standard MW function: $user->addNewUserLogEntry;. Advice? -- Gth-au 03:15, 24 December 2008 (UTC)

I get exactly the same Error on fresh installed Wiki. MediaWiki 	1.13.3 PHP 	5.2.4-2ubuntu5.4 (apache2handler) MySQL 	5.0.51a-3ubuntu5.4

Same error here, MediaWiki 1.13.3
 * Either upgrade to 1.14 use use the 1.13 branch version of the extension. Voice of All 04:19, 15 January 2009 (UTC)

Don't understand MySQL step. Help please?
I'm quite lost at this part of the instructions:


 * Run the SQL query, substituting in your wiki's table prefix. ConfirmAccount.pg.sql is for PostgreSQL, and ConfirmAccount.sql is for MySQL. That is, find whichever of those two files, and send a query that creates the account_credentials and account_requests tables, with /*$wgDBprefix*/ replaced according to whatever is appropriate.

How do I "run the SQL query"? Do I just type "ConfirmAccount.SQL" at a command prompt? If it's something I have to do inside MySQL, I'm completely unfamiliar with how to use it. Is there somewhere I can look up exactly which commands to enter?

Thanks in advance for any help you can give me! --Quixote7 04:00, 24 December 2008 (UTC)

Also, when it says "replace /*$wgDBprefix*/ with whatever is appropriate" could you give an example? I have no idea what is meant. My database for my wiki on my server? "SQL" to stand for MySQL as opposed to Postgres? Some other database entirely? --Quixote7 04:14, 24 December 2008 (UTC)


 * Files ending in .SQL can usually be executed with an SQL database engine directly - refer to the MySQL documentation for the exact command-line syntax. As an alternative, if you have PhpMyAdmin you can highlight your database and select Query Window to paste the contents of the .SQL via a web browser.  Just remember that inside the ConfrmAccount.SQL file, you will need to make two smalls edits: you need to update the lines CREATE TABLE /*$wgDBprefix*/account_requests ( and CREATE TABLE /*$wgDBprefix*/account_credentials ( to match your installation's table-prefix.  If you're still lost as to what the prefix should be, open LocalSettings.php file and search for $wgDBprefix - this prefix value is what the ConfirmAccount SQL code needs to match. -- Gth-au 11:38, 24 December 2008 (UTC)


 * As you request an example of these edits, if your $wgDBprefix value was "mywiki_" then the two lines would be:
 * CREATE TABLE mywiki_account_requests (
 * and then further down, the second change would appear as:
 * CREATE TABLE mywiki_account_credentials (
 * Enjoy. -- Gth-au 11:41, 24 December 2008 (UTC)

That's much clearer. Thanks! Anything to do with MySQL is pretty much of a nightmare, as far as I'm concerned. In the ideal world, there'd be a front-end script that could just do all this :-) . I'll look for a Request For Features page for ConfirmAccount. --Quixote7 19:23, 24 December 2008 (UTC)

Bug with SharedDB
It don't works with $wgSharedDB, tries to access using the local prefix.Eloy 16:57, 31 December 2008 (UTC) Eloy 17:04, 31 December 2008 (UTC)
 * Ok, I fix it. I forget add the tables in LocalSettings:

Undefined method?
In trying to get ConfirmAccount to work, I get this error message when I try to approve a user:

Call to undefined method User::addNewUserLogEntry in /home/cpsquare/public_html/wiki/extensions/ConfirmAccount/ConfirmAccount_body.php on line 568

I'm also seeing problems re the simple Captcha, where it rejects correct information (I'm sure that I'm adding correctly). --Smithjd 01:24, 13 January 2009 (UTC)


 * r40769 broke compatibility with 1.13; use the 1.13.3 version instead. —Emufarmers(T 02:26, 13 January 2009 (UTC)


 * That fixes it -- for Firefox only. (It does just what I need!) However, the same account request input that works with Firefox, when submitted with Internet Explorer results in "Incorrect or missing confirmation code." (I'd use Firefox to approve requests, but need to have IE users able to request an account!) --Smithjd 17:52, 14 January 2009 (UTC)

Must be logged in to request an account
Trying to explain different behavior of CoonfirmAccount on different machines. Ruling out browsers, OS, etc. Surprise! I do not get the dreaded "Incorrect or missing confirmation code" message when I'm logged in creating an account for someone else, but I do get it when I'm not logged on. Does that signal an incorrect parameter I've set? Surely it's not designed to work that way. --Smithjd 17:40, 19 January 2009 (UTC)
 * ConfirmEdit is on I assume? Aaron 19:10, 19 January 2009 (UTC)
 * ConfirmEdit is "on" if this one statement in LocalSettings.php turns it on: --Smithjd 22:37, 20 January 2009 (UTC)
 * And r45908 has the same issue? Aaron 22:47, 20 January 2009 (UTC)
 * Yes it does --Smithjd 23:26, 20 January 2009 (UTC)
 * ConfirmEdit requires cookies by default. It may fail for some anons. You can try  to work around it. Aaron 01:17, 21 January 2009 (UTC)
 * That doesn't seem to make a difference.--Smithjd 05:45, 21 January 2009 (UTC)
 * And you added it *after* '"$IP/extensions/ConfirmEdit/ConfirmEdit.php"'? If it still fails, I'd just disable ConfirmEdit, not really needed on large sites. Aaron 06:34, 21 January 2009 (UTC)

Is ConfirmEdit required to run ConfirmAccount
The reason I installed ConfirmEdit was that I thought it was required to run ConfirmAccount, which is what I really want. I'd rather run a regular "captcha". ConfirmAccount was generating an error message saying that it couldn't find ConfirmEdit. Perhaps I can find and remove the call to ConfirimEdit? --Smithjd 16:38, 21 January 2009 (UTC)
 * ConfirmEdit is not needed. Aaron 20:53, 21 January 2009 (UTC)

Getting ConfirmAccount to run
Thanks Aaron for all the help. I'm happy to report that it works! Here's how it works for me: to get ConfirmAccount to run with the current trunk release of mediawiki, I had to use the MW1.13-r38539 release of ConfirmAccount. And I had to comment out all the lines that link to or depend on ConfirmEdit extension (since I couldn't seem to get it to work on my installation): --Smithjd 17:32, 22 January 2009 (UTC)
 * in RequestAccount_body.php, comment 16 lines beginning with.
 * in SpecialConfirmAccount.php, comment out
 * As long as both extensions are on, ConfirmAccount will be effected by ConfirmEdit unless $wgConfirmAccountCaptchas is set to false. Aaron 06:48, 24 January 2009 (UTC)

The Localized Text is far from readable!(zh-hans)
I've updated the $messages['zh-hans']. Please consider using this translation in the next version. /** Simplified Chinese (‪中文(简体)‬) */ $messages['zh-hans'] = array(	'requestaccount'            => '请求账户',	'requestaccount-text'        => "填写并提交以下的表格来请求一个用户账户.  	请确认您在请求一个账户之前，先读过|服务细则. 	一旦该账户获得批准，您将会收到一个电邮通知信息，该账户就可以在Special:Userlogin中使用. ",	'requestaccount-dup'         => "注意: 您已经登录为一个已注册的账户. ",	'requestaccount-acc-text'    => '当完成请求时，一封确认信息会发到您的电子邮件地址. 	请在该封电子邮件中点击确认链接以继续. 同时，当您的账户被创建后，您账户的密码将会通过电子邮件寄给您. ',	'requestaccount-ext-text'    => '以下的资料将会保密，只用于在这次请求.  	您可能需要列出联系信息，如电话号码等来帮助证明您的确认. ',	'requestaccount-bio-text'    => '您的传记将被设置为您用户页的预设内容. 试着加入一些凭证. 	确保这些信息都是可以被发布的. 您的名字可以通过参数设置更改. ',	'requestaccount-real'        => '真实名字:',	'requestaccount-same'        => '(同真实名字)',	'requestaccount-email'       => '电子邮件地址:',	'requestaccount-bio'         => '个人传记:',	'requestaccount-notes'       => '附加注解:',	'requestaccount-urls'        => '网站列表，如果有 (以新行分开):',	'requestaccount-agree'       => '您一定要确保您的真实名字是正确的，并且您同意我们的服务细则. ',	'requestaccount-inuse'      => '已经有正在请求的使用该用户名的账户. ',	'requestaccount-tooshort'   => '您的传记必须最少有$1个字的长度. ',	'requestaccount-tos'        => '我已经阅读以及同意坚持遵守的服务细则. ',	'requestaccount-submit'     => '请求账户', 'requestaccount-sent'       => '您的账户请求已经成功发出，现正等候复审. ',	'request-account-econf'     => '您的电子邮件地址已经确认，将会在您的账户请求中列示. ',	'requestaccount-email-subj' => '电子邮件地址确认', 'requestaccount-email-body' => '有人，可能是您，使用IP地址$1，在中用这个电子邮件地址请求一个名叫"$2"的账户.

要确认在上面的这个账户确实属于您，请在您的浏览器中打开这个链接:

$3

当该账户被创建时，只有您才会通过电子邮件收到密码. 如果这个账户*不是*属于您的话，不要点击这个链接. 这个确认码将会在$4过期. ',	'acct_request_throttle_hit' => '抱歉，您已经请求了$1个账户. 您不可以请求更多账户. ',	'requestaccount-loginnotice' => "要取得用户账户，请点击请求帐户. ", 'confirmaccounts'           => '确认帐户请求', 'confirmaccount-list'       => '以下是正在等候批准的帐户请求列表. 已经批准的账户将会被创建，并从这个列表中移除. 已拒绝的用户将只会从这个列表中移除. ',	'confirmaccount-list2'      => '以下是一个先前拒绝过的帐户请求，可能会在数日后删除. 它们仍旧可以被批准创建账户，但是在您批准之前请先询问先前拒绝该账户请求的管理员. ',	'confirmaccount-text'       => "这是在中等待确认的账户请求的页面. 	请认真阅读以下信息. 	要批准这个请求，请通过下拉列表来设置用户的状态. 	对申请表中传记的修改不会影响任何的永久存储的信息. 	注意当用户名与其他人的名字有冲突时，您可以更换用户名来创建这个账户. 	如果你对这个页面不选择确认或者拒绝请求的话，等候状态将会保持下去. ", 'confirmaccount-review'     => '批准/拒绝', 'confirmaccount-badid'      => '没有对应这一ID的未答复的请求. 这一请求可能已经被处理过了. ',	'confirmaccount-name'       => '用户名', 'confirmaccount-real'       => '姓名', 'confirmaccount-email'      => '电子邮件', 'confirmaccount-bio'        => '传记', 'confirmaccount-urls'       => '网站列表:', 'confirmaccount-confirm'    => '用以下的按钮来批准或拒绝这个请求. ',	'confirmaccount-econf'      => '(已批准)', 'confirmaccount-reject'     => '(已被$1在$2拒绝)', 'confirmaccount-create'     => '接受 (创建账户)', 'confirmaccount-deny'       => '拒绝 (不加入)', 'confirmaccount-reason'     => '原因 (在电子邮件中使用):', 'confirmaccount-submit'     => '确认', 'confirmaccount-acc'        => '账户请求已经成功确认；已经创建一个新的用户帐户User:$1. ',	'confirmaccount-rej'        => '账户请求已经成功拒绝. ',	'confirmaccount-summary'    => '正在创建一个新用户的具有传记的用户页面. ',	'confirmaccount-welc'       => "欢迎来到'！'''我们希望您会作出更多更好的贡献.  	您可能想要阅读|帮助页面. 再一次欢迎你！ 	Crlf0710 08:49, 27 January 2009 (UTC)", 'confirmaccount-wsum'       => '欢迎！', 'confirmaccount-email-subj' => '账户请求', 'confirmaccount-email-body' => '您请求的账户已经在中批准.

账户名称: $1

密码: $2

为了保密的原因，您需要在第一次登录时更改密码. 要登录，请前往. ',	'confirmaccount-email-body2' => '您请求的账户已经在中被批准.

账户名称: $1

密码: $2

$3

为了保密的原因，您需要在一次登入时更改密码. 要登入，请前往. ',	'confirmaccount-email-body3' => '抱歉，你在请求的账户"$1"已经遭到拒绝.

有很多原因会造成这一结果. 您可能没有正确地填写申请表，可能在您的回复中字数不够，也可能未能符合一些政策的要求. 在这个网站中提供了联系方式列表，您可以通过它了解更多关于用户账户方针的信息. ',	'confirmaccount-email-body4' => '抱歉，你在请求的账户"$1"已经遭到拒绝.

$2

在这个网站中提供了联系方式列表，您可以通过它了解更多关于用户账户方针的信息. ', );
 * May want to suggest that to BetaWiki Voice of All 07:19, 8 February 2009 (UTC)

Alerting sysops when an account is requested
It would be really nice if the sysop were sent an email advising that an account request form has been completed -- in the same way and at the same time that the requester receives an email.

Problem with hotmail email addresses
We are having problems with some hotmail/msn users not receiving their "confirm email" emails. The email is also not appearing in their spam folder. Any ideas?

Can't confirm users
When I go to the upper right hand corner to confirm/approve a new user, I click on it and it goes to: http://www.myhostname.com/wiki/index.php/Special:ConfirmAccounts and nothing comes up on the screen. No errors or anything and the user is not confirmed.

Any ideas how to fix? I have made sure all files in the extensions folder are chmod'd to 775 and owned/grouped to my apache user.

Registered users (after confirmed request) can create new account
Hi everybody, I'm using mediawiki and this plugin for the university (a project for the Academic Degree). I've to say that both (mediawiki and ConfirmAccount) are very very good. This morning I found a bug on the plugin (I think). When a logged user (after confirming the request) try to go on Special Pages, and then in the Log in/ Create Account page, can create a new account without asking a request to the admin. In my opinion is like a bug and I've solved the problem on adding this line in the /includes/DefaultSettings.php file : $wgGroupPermissions['user']['createaccount']   = false; You can put this line where you want.. But it's better something like this:

$wgGroupPermissions['user']['createaccount']   = false; $wgGroupPermissions['user']['read']            = true; $wgGroupPermissions['user']['edit']            = true; $wgGroupPermissions['user']['createpage']      = true; $wgGroupPermissions['user']['createtalk']      = true; $wgGroupPermissions['user']['writeapi']        = true; $wgGroupPermissions['user']['upload']          = true; $wgGroupPermissions['user']['reupload']        = true; $wgGroupPermissions['user']['reupload-shared'] = true; $wgGroupPermissions['user']['minoredit']       = true; $wgGroupPermissions['user']['purge']           = true; // can use ?action=purge without clicking "ok" Now logged users that try to go on Log in /Create Account page have to request a new account. I think it's better.. Let me know

Bugzilla bug 18053: Special:RequestAccount form post results in BadTitle page
I have just filed a bug in Bugzilla: With the ConfirmAccount extension installed on the server, after posting a Special:RequestAccount form, users get a BadTitle page, making them unable to actually request an account.

The bug occurs with french localized MediaWiki ($wgLanguageCode = "fr") but not in english ($wgLanguageCode = "fr"). I further figured out that it occurs only when the localized name for the special namespace has special characters, for instance: - "Spécial" with $wgLanguageCode = "fr" - "Служебная" with $wgLanguageCode = "ru" It works with $wgLanguageCode = "de" ("Spezial") and of course with $wgLanguageCode = "de".

As a workaround I have set the french name of the special namespace to "Special" instead of "Spécial" ($namespaceName[NS_SPECIAL] = 'Special') in MessagesFr.php

Is the extension responsible of that?

By the way, why isn't the ConfirmAccount extension listed in the Bugzilla bug report form?

Warning: Invalid argument supplied for foreach
Thanks a lot for coming up with a great extension! Everything worked really well with MediaWiki 1.12.0 but I recently upgraded to MediaWiki 1.14.0 and I also upgraded to ConfirmAccount-MW1.14-r45462 and now, everytime I confirm an account, I'm getting a nasty warning: "Warning: Invalid argument supplied for foreach in [...] /w/extensions/ConfirmAccount/ConfirmAccount_body.php on line 778". Any ideas? Thanks and cheers, --Till Kraemer 23:25, 24 March 2009 (UTC)