Extension talk:ConfirmAccount/LQT Archive 1


 * Archive 1
 * Archive 2

Misc Bugs
--84.63.27.64 12:22, 19 March 2011 (UTC)
 * In MySQL acr_bio and acd_bio may not be null, but empty bios are stored as NULL -> change table definition (done locally) or save 'em as empty strings
 * acr_email's type is tinytext although it's stored in a index -> change to varchar
 * In i18n: it's de_formal - not de-formal
 * Wishlist: Add support for disabling biographie

Some clarifying instructions for noobs because that's basically what I am.

 * If you don't see the file ConfirmAccount.php in the folder /ConfirmAccount but you see instead SpecialConfirmAccount.php, make sure you download the Development Version instead of 1.16x version.
 * Many shared web hosting accounts will not give you shell access to run update so you need to import ConfirmAccount.sql using phpMYAdmin. But if you are using a database prefix, you must first edit this file using notepad.
 * I use MW_ as a prefix so I made the following changes: CREATE TABLE mw_account_requests and down further in the file: CREATE TABLE mw_account_credentials.
 * Now go to phpMYAdmin, select your database so it shows on the top as localhost > yourdb_name.
 * Note the number of records in this database. It will increase by 2 if you are successful.
 * Click the import tab and browse to your local folder where you have modified your ConfirmAccount.sql file and import.
 * Now go to the structure tab and you should see the two new files created as mw_account_requests and mw_account_credentials if your prefix is mw_.

Once installed correctly, account creators will see a new screen when they click create account. Users will no longer be able to create accounts directly but must request an account. This is nothing more than an email confirmation. No admin action is required at this point. A confirmation email will be sent to the user and when the user confirms, the user will be placed in a approval list which must be acted on by an admin. Once the account is approved, the user will be sent another email confirming the account creation.

Personally, I think these steps are too demanding and intrusive and will drive away registered users. I recommend turning this on only in rare occasions when your wiki is under a spam attack. As you can see from my block list, I was receiving dozens of spam registrations per day. This extension brought that to a halt immediately.

Error sending mail: mailer error
I can't figure out what this error even means, or where it's coming from. I grep'ed for the text and didn't find anything in the folder containing the ConfirmAccount code. What's the cause of this error? How can I fix it?

155.99.202.108 23:41, 19 October 2010 (UTC)

"efCheckIfAccountNameIsPending failed to return a value; "
Seems like I'm missing something obvious here, but so far not seeing it. Have upgraded wiki to latest release (1.15.4), and re-installed fresh versions of both ConfirmAccount and ConfirmEdit. ReCaptcha is not being used. Here's what I get when a user clicks the "submit" button:

Internal Error Detected bug in an extension! Hook efCheckIfAccountNameIsPending failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:


 * 1) 0 /var/www/w/extensions/ConfirmAccount/RequestAccount_body.php(239): wfRunHooks('AbortNewAccount', Array)
 * 2) 1 /var/www/w/extensions/ConfirmAccount/RequestAccount_body.php(74): RequestAccountPage->doSubmit
 * 3) 2 /var/www/w/includes/SpecialPage.php(559): RequestAccountPage->execute(NULL)
 * 4) 3 /var/www/w/includes/Wiki.php(229): SpecialPage::executePath(Object(Title))
 * 5) 4 /var/www/w/includes/Wiki.php(59): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 6) 5 /var/www/w/index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
 * 7) 6 {main}

This looks like something reported below that was supposed to be fixed, so I'm assuming I probably have something out of sync, but I can't find it -- any guidance would be most appreciated. On a bit of a deadline here, of course ;)

Thanks!

Ok, got this working ... here's what I had to do with MW 1.15.4 to get it working.

(1) install latest ConfirmEdit.

(2) install latest TRUNK version of ConfirmAccount -- NOT the 1.15 release (this has not been fixed, apparently).

(3) Hand edit the ConfirmAccount.sql file to specify database table prefix, then run maintenance/update.php -- note this is different from install instructions...

(4) follow install instructions for 1.16 -- not 1.15 -- in other words, use the extensions/ConfirmAccount/ConfirmAccount.php in LocalSettings.php, NOT SpecialConfirmAccount.

At this point, every thing seems to be working, will report back if not.


 * Installed 1.15 version on MW1.15, also using manual sql update (step #3), but above error came up. Removed files of CA1.15 and placed files of CA1.16, worked perfectly.
 * Under MW 1.15.5 I get problems with TRUNK and 1.15 BRANCH.  Branch gets above error and trunk fails to show correct login / request register dialog.

Using template on "bio" section"?
Hi! First of all: This extension is great! But I have a little problem. I´m trying to use an existing wiki template on the "bio" section. Is this posible? The goal is that the information that the new users inputs on the bio (and, the template), they can get their "users profiles" almost ready. Thanks!!! --Tango granada 01:04, 5 October 2009 (UTC)

Any ideas??
Same issue, I putzed around with the PHP, but now it loads the 'template' I created at load-time and at submit time, so even if the user requesting the account filled in the details as needed, it gets replaced by the template text.

Bureaucrat's do not have permission to confirm an account.
Permission error when trying to confirm an account with User 'bureaucrat'. I see the file "SpecialConfirmAccount.php", and this has a line of code to configure the group bureaucrats. In file: $wgGroupPermissions['bureaucrat']['confirmaccount'] = true;
 * 1) Grant account queue rights

The account then I try confirm is the admin of wiki. They have bureaucrats group add. So, i have something more to do?

Email sent with password contains line I would like to remove
The email sent out with username and password contains the line "Welcome to the forums. Thank you for your interest in joining our forum." by default. How do I remove this? I've tried looking at MediaWiki:confirmaccount-email-body (2,3,4,5,6) but that line doesn't appear to be present and I would like to remove it. --90.192.146.115 13:06, 26 October 2009 (UTC)

Installing reCAPTCHA with ConfirmAccount
Just a little public service for those trying to do what I've done:
 * 1) Create a private wiki using these guidelines: Manual:Preventing_access
 * 2) Use Extension:ConfirmAccount to set up an account request queue
 * 3) Use Extension:reCAPTCHA to keep the bots from filling up my account request queue

First off, after adding Extension:ConfirmAccount and Extension:reCAPTCHA to my installation, I went to test. Starting at my Main_Page, I clicked log in, then clicked the Create an account link to request an account. But it took me right back to Main_Page. Clearly, not the desired effect. After cursing a little and pondering the meaning of life, I recalled that when I worked on LocalSettings.php to restrict viewing, editing and account creation, those configuration flags included $wgWhitelistRead (see Manual:Preventing_access). Naturally, "Special:UserLogin&type=signup" (usually called "Special:RequestAccount" on standard MediaWiki installs) wasn't in the list. Duh. Added that in to LocalSettings.php, FTP'd it over to the server and voilà! Fixed. Sort of.

After figuring out how to let an anonymous user get to the account request page, I moved on to a more serious issue. I was getting an error on the screen that pointed to Extension:ConfirmEdit as the culprit. The errors looked pretty much like this:
 * Extension_talk:ConfirmAccount

While Extension:reCAPTCHA was installed (but not working), Extension:ConfirmEdit wasn't. The Extension:ConfirmAccount and Extension:reCAPTCHA gurus know this (of course, I didn't), but Extension:reCAPTCHA is really a combination of some .php files from the reCAPTCHA people at Carnegie Mellon University and some other .php files for Extension:ConfirmEdit. You can either run Extension:ConfirmEdit (with it's very basic text CAPTCHA implementation) or the more sophisticated Extension:reCAPTCHA (with graphical CAPTCHAs), but not both.

After much trial n' error, Googling and a piecing together comments HERE, HERE and HERE, I figured out that I needed to use the ConfirmEdit.php file from Extension:ConfirmEdit instead of the file with the same name supplied with the reCAPTCHA download. I also needed to add the ConfirmEdit_body.php file from Extension:ConfirmEdit as this file is not in the Extension:reCAPTCHA package.

I re-downloaded both Extensions just to make sure I had clean, un-edited .php files (I had been experimenting with several files as I did my trial n' error), then replaced the ConfirmEdit.php and ConfirmEdit_body.php files in the Extension:reCAPTCHA package with those from the Extension:ConfirmEdit package. I deleted the /your_wiki's_root/extensions/recaptcha directory on the server, FTP'd over a new /recaptcha directory with the correct files and everything came up as desired.

Hope this helps someone else down the road.

Problems using this with SQLite
I'm having a bear of a time getting this to play nice with an SQLite backend. To start, the .sql script is for MySQL. That is mostly solved except for the account_credentials table having two primary keys, which isn't supported in SQlite.

Then, for some reason none of the database requests work. I can submit a request, it gets committed to the database, but it won't be read/counted properly for some reason.

Anyone got experience using it with SQLite?

Got it working with SQLite
To get this extension working with SQLite, I had to edit ConfirmAccount.sql: CREATE TABLE /*$wgDBprefix*/account_requests (   acr_id INTEGER PRIMARY KEY AUTOINCREMENT,    acr_name varchar(255) NOT NULL default ,    acr_real_name varchar(255) NOT NULL default ,    acr_email tinytext NOT NULL,    acr_email_authenticated BLOB(14) default NULL,    acr_email_token BLOB(32),    acr_email_token_expires BLOB(14),    acr_bio mediumblob NOT NULL,    acr_notes mediumblob NOT NULL,    acr_urls mediumblob NOT NULL,    acr_ip VARCHAR(255) NULL default ,    acr_filename VARCHAR(255) NULL,    acr_storage_key VARCHAR(64) NULL,    acr_type tinyint(255) default 0,    acr_areas mediumblob NOT NULL,    acr_registration char(14) NOT NULL,    acr_deleted bool NOT NULL,    acr_rejected BLOB(14),    acr_held BLOB(14),    acr_user INTEGER NOT NULL default 0,    acr_comment varchar(255) NOT NULL default ,    UNIQUE (acr_name),    UNIQUE (acr_email),    UNIQUE (acr_email_token)  ); CREATE INDEX acr_type_del_reg on /*$wgDBprefix*/account_requests(acr_type,acr_deleted,acr_registration); CREATE TABLE /*$wgDBprefix*/account_credentials (   acd_id INTEGER PRIMARY KEY AUTOINCREMENT,    acd_user_id INTEGER NOT NULL,    acd_real_name varchar(255) NOT NULL default ,    acd_email tinytext NOT NULL,    acd_email_authenticated BLOB(14) default NULL,    acd_bio mediumblob NOT NULL,    acd_notes mediumblob NOT NULL,    acd_urls mediumblob NOT NULL,    acd_ip VARCHAR(255) NULL default ,    acd_filename VARCHAR(255) NULL,    acd_storage_key VARCHAR(64) NULL,    acd_areas mediumblob NOT NULL,    acd_registration char(14) NOT NULL,    acd_accepted BLOB(14),    acd_user INTEGER NOT NULL default 0,    acd_comment varchar(255) NOT NULL default '',    UNIQUE (acd_id)  );

I saved this to a file (e.g., ConfirmAccount_SQLite.sql) and loaded the new tables to the SQLite database with: sqlite3 wikiDB.sqlite < ConfirmAccount_SQLite.sql

To get it working, I also had to make one small edit to the code. Apparently, SQLite doesn't like to set a default value for NOT NULL columns. So, I added this line to the account_requests insert query in RequestAccount_body.php (around line 384):

'acr_deleted' => 0,

I haven't tested everything, but the basic functionality seems to be working now.
 * Updates made to /trunk. Aaron 21:00, 7 April 2011 (UTC)

Problem with "position" titles starting with the same letter
I am experiencing a problem that is preventing me from having the "position" labels starting with the same letter. Basically, you can not have two position titles that start with the same letter. (Example: "Reader" and "Reviewer")

Sample synerio:
 * A user requests an account with the position of "reviewer."
 * Admin navigates to Special:ConfirmAccounts to confirm the pending account.
 * Admin clicks "open requests" for "reviewers" (second queue listed) you are brought to the "readers" queue.

I noticed that the url that you are sent to is represented by the first letter of the position. Example: xxxxx/Special:ConfirmAccounts/r&ShowHeld

NOTE: If there is only one default position group (array is commented out) then you are sent to: xxxxx/Special:ConfirmAccounts/reviewers&ShowHeld

Can the "open request" links be formatted to always use the entire position name, not just the first letter?

Sorry for the over explaining..I know it is a strange sounding problem.

Thanks in advance,

-Dgennaro 21:09, 13 January 2010 (UTC)
 * How did you set $wgAccountRequestTypes? Aaron 21:38, 13 January 2010 (UTC)


 * $wgAccountRequestTypes = array('reader', 'reviewer');


 * Thanks! Works great! -Dgennaro 13:12, 22 January 2010 (UTC)
 * Just for good measuere, I also tried it:


 * $wgAccountRequestTypes[0] = 'reader';


 * $wgAccountRequestTypes[1] = 'reviewer';


 * -Dgennaro 14:28, 14 January 2010 (UTC)
 * I think you want:

Aaron 20:35, 14 January 2010 (UTC)


 * This does not work. And I am not certain why you are putting an array inside another array.
 * -Dgennaro 21:03, 14 January 2010 (UTC)


 * Never mind, I thought you wanted something different. The above code would make a 'reader' queue and the approved users are in the 'reviewer' group. If you want a 'reader' and 'reviewer' queue, then you want:

Aaron 21:29, 14 January 2010 (UTC)

Error when confirming email account
I am receiving an HTTP 500 Internal Server Error when a potential user clicks the link provided in the "Email Confirmation" email.

I am running MediaWiki 1.14.0 with ConfirmAccount 1.46 (x1.15).

Any ideas?

Thanks in advance. -Dgennaro 22:18, 21 January 2010 (UTC)


 * I've heard Zend Optimizer can cause 500s. Redirects to invalid URLs can cause thus too. The apache and PHP error logs may have useful info. By the way, did you ever fix the $wgAccountRequestTypes value? Aaron 04:06, 22 January 2010 (UTC)


 * Yes, I did. The advice worked perfect! I must have forgotten to post.


 * I tried using the 1.14x version of ConfirmAccount also with no success. My next step today was to check out the PHP and IIS error logs. I am determined to make this extension work for me! I will post an update with my findings.


 * Just to recap...what is happening is: the user requests an account and they receive an email to confirm their email address and when the user clicks the link within the email they receive a HTTP 500 error, but when I look in the database their email address has been confirmed. This would be fine, but I added the bit of code in that enables the "admin" to receive an email when there is a pending user account for approval...this step is not happening. I am assuming that the HTTP 500 error is not allowing this step to happen since the email confirmation step was not "fully completed." Do you think I am on the right track?


 * Thanks again! -Dgennaro 13:20, 22 January 2010 (UTC)

Problem with latest 1.15 release of ConfirmAccount
I'm getting the following error report: Internal error Detected bug in an extension! Hook efCheckIfAccountNameIsPending failed to return a value; should return true to continue hook processing or false to abort. Backtrace: Herwin 15:58, 8 February 2010 (UTC)
 * 1) 0 /Users/harryerw/Sites/mediawiki/extensions/ConfirmAccount/RequestAccount_body.php(239): wfRunHooks('AbortNewAccount', Array)
 * 2) 1 /Users/harryerw/Sites/mediawiki/extensions/ConfirmAccount/RequestAccount_body.php(74): RequestAccountPage->doSubmit
 * 3) 2 /Users/harryerw/Sites/mediawiki/includes/SpecialPage.php(559): RequestAccountPage->execute(NULL)
 * 4) 3 /Users/harryerw/Sites/mediawiki/includes/Wiki.php(229): SpecialPage::executePath(Object(Title))
 * 5) 4 /Users/harryerw/Sites/mediawiki/includes/Wiki.php(59): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
 * 6) 5 /Users/harryerw/Sites/mediawiki/index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
 * 7) 6 {main}

The console shows this: PHP Warning: Parameter 1 to efCheckIfAccountNameIsPending expected to be a reference, value given in /Users/harryerw/Sites/mediawiki/includes/Hooks.php on line 117, referer: http://crowan-scat.sunderland.ac.uk/~harryerw/mediawiki/index.php/Special:RequestAccount Herwin 16:09, 8 February 2010 (UTC)
 * The 1.15 version does not have that problem. I just looked at the code. Aaron 18:00, 8 February 2010 (UTC)

I'll do a reinstall Tuesday and see if the problem still exists. Herwin 22:32, 8 February 2010 (UTC)

Done and it now asks for a biography. Let's see... At least the error isn't showing up. Herwin 10:14, 9 February 2010 (UTC)


 * It's fixed in trunk. Liangent 14:38, 20 June 2010 (UTC)

How to let a user edit his biography (that is not confirmed yet)?
I do not really get the meaning of the "Hold" option when confirming account requests. When I choose this option, then an email with the following contents is sent to the email address requesting the account: Before your request for an account "Klaus Mustermann" can be accepted on Wiki you must first provide some additional information.

 Your biography needs editing. Please add your birth date, place, address, etc.

There may be contact lists on site that you can use if you want to know more about user account policy.

Now, assuming that the person wants to edit his/her biography according to my request, how can he/she do it? Is it possible at all? If not, what is the point of the "Hold" option?

Not receiving any email to administrator after the email address is confirmed
Even after setting (either directly in SpeciaConfirmationAccount.php or in LocalSettings.php) : $wgConfirmAccountContact = 'myemail@example.com' That administrator does not receive any email notification once the user confirmed his email address. Looking at the archives, seems like it was a problem already before and there is no answer there.

I am using mediawiki 1.15.2, the extension from 1.15.x branch. Even if I enable debug messages, I don't see it complaining about anything. Help please !


 * I have this same problem, although I am going to try it with an email address rather than the way I have it which is:
 * $wgConfirmAccountContact = true
 * Hbmallin 21:47, 26 January 2011 (UTC)

Doesn't respect $wgDBprefix
Using trunk as of 2010/04/18 & just wanted to point out, the setup steps are not quite correct.

1. they do not take into account if you are using $wgDBprefix in your settings. I had to run these mysql statements to post-fix: mysql> rename table account_requests to mw_account_requests; mysql> rename table account_credentials to mw_account_credentials;

2. The include in LocalSettings.php is (now) actually require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");

—- The missing step that solves #1 above is you have to edit ConfirmAccount/ConfirmAccount.sql and perform a change as the remark there says: (this is actually included within the "Setup" steps as "substituting db prefix")

-- Replace /*$wgDBprefix*/ with the proper prefix

PeterS3 06:52, 23 June 2010 (UTC)

1.15x snapshot missing ConfirmAccount.php
Seems a bit fatal to me. (unsigned by 128.194.196.117 20:19, 21 April 2010)


 * I couldn't agree more. There is no ConfirmAccount.php in the package. Joly 05:10, 28 April 2010 (UTC)

AccountRequestMinWords
$wgAccountRequestMinWords, doesn't work on my wiki 1.15. when i add to Localsettings.php $wgAccountRequestMinWords=20; for example

It writes bio min=20, but really requires 50 words as default.
 * Note that it should be added *after* the "include" call. Aaron 19:59, 29 April 2010 (UTC)

AccountRequestMinWords works well only with english text of Bio but I need russian. How to fix it? --94.51.8.36 14:55, 5 June 2010 (UTC)DrShtopor

Problem with Special:UserCredentials
The display isn't right! Here is what it looks like:


 * If I go to Special:UserCredentials:
 * the page title shows as &amp;lt;usercredentials&amp;gt;
 * there is a box with the title , and an input field with the title &amp;lt;usercredentials-user&amp;gt;


 * When I type in a username, it goes to the display page:
 * If the user does not exist (or existed before ConfirmAccount was installed - which is only 3 accounts on my wiki) the message reads &amp;lt;usercredentials-badid&amp;gt;
 * If the user does exists and was confirmed, the following is displayed:
 * 

&amp;lt;usercredentials-leg-user&amp;gt;Username: test &amp;lt;usercredentials-email&amp;gt; test@xxxxx.com &amp;lt;confirmaccount-leg-areas&amp;gt; &amp;lt;usercredentials-leg-person&amp;gt;&amp;lt;usercredentials-real&amp;gt; Test Name

&amp;lt;usercredentials-bio&amp;gt; This is the bio provided when signing up &amp;lt;usercredentials-leg-other&amp;gt; &amp;lt;usercredentials-ip&amp;gt; 99.99.99.99

Does anyone know how I can get this to display properly? -- Phantom Steve /talk &#124;contribs \ 09:02, 21 June 2010 (UTC)

doesn't create tables
I have Mediawiki 1.15 running, and am trying to install ConfirmAccount. I substituted the dbprefix, but everytime i try to create an account, I get the message that the table account_requests doesn't exist.

can anyone help me with this?

thnx! --Gallomane 09:55, 22 June 2010 (UTC)
 * In the directory in which you installed ConfirmAccount, there is a file called.

If you are using phpmyadmin, you can import this in to create the tables. Otherwise, here is the SQL code which you need to create the table:

Hope this helps! -- Phantom Steve /talk &#124;contribs \ 19:53, 24 June 2010 (UTC)

I replaced the code, substituted the dbprefix again to match what is in my localsettings, but I still get the error: “1146: Table 'admin_anja_wiki.account_requests' doesn't exist (localhost)”. Teruggeplaatst van "http://wiki.familiekock.nl/index.php/Hoofdpagina"

I don't get it! Could it be because I don't really have a dbprefix? It says "" in my localsettings, so I put // in the sql file. --Gallomane 08:59, 28 June 2010 (UTC)

Using version 1.12, I had the same problems, and solved them like this: Then the tables were created, the field and index changes were attempted, and failed gracefully because they were redundant. --Nick Russo 18:12, 10 September 2010 (UTC)
 * create three new files in archives/:
 * patch-account_requests.sql -- contains the CREATE command copied from ConfirmAccount.sql, which never seems to be used
 * patch-acr_del.sql -- contains the INDEX lines from patch-account_credentials.sql
 * patch-acr_type.sql -- contains the ADD lines from patch-account_credentials.sql
 * add three lines to SpecialConfirmAccount.php in the $wgDBtype == 'mysql' section:
 * $wgExtNewTables[] = array('account_requests', "$base/archives/patch-account_requests.sql" );
 * $wgExtNewFields[] = array('account_requests', 'acr_type', "$base/archives/patch-acr_type.sql" );
 * $wgExtNewIndexes[] = array('account_requests', 'acr_type_del_reg', "$base/archives/patch-acr_del.sql" );

MediaWiki:Confirmaccount-welc
Is it possible to pass templates of pages through this page to the user's talk page when an account is created? For example if I wanted to add sections as the welcome to the new user's talk page?

Will the page also handle the and tags? Hutchy68 03:35, 8 August 2010 (UTC)

"biography will be set as default userpage" even though $wgMakeUserPageFromBio=false
(Applies to ConfirmAccount 1.46)

When setting $wgMakeUserPageFromBio to false (meaning "don't set the person's bio as his/her userpage"), the page Special:RequestAccount still claims that "Your biography will be set as the default content for your userpage" (first sentence of box "personal information").

To remove this inconsistency, two files have to be changed in ConfirmAccount 1.46: $form .= wfMsgExt( 'requestaccount-bio-text', array('parse') )."\n"; by global $wgMakeUserPageFromBio; if ( $wgMakeUserPageFromBio ) { $form .= wfMsgExt( 'requestaccount-bio-text1', array('parse') )."\n"; } $form .= wfMsgExt( 'requestaccount-bio-text2', array('parse') )."\n"; The modified file is available at my web site.
 * ConfirmAccount/RequestAccount_body.php: Replace the line
 * ConfirmAccount/ConfirmAccount.i18n.php: The requestaccount-bio-text has to be split into requestaccount-bio-text1 and requestaccount-bio-text2 for all languages. This new version of ConfirmAccount.i18n.php is available at my web site . For a few languages (most notably Chinese) I was not sure where to split the text. In these cases I left requestaccount-bio-text1 empty and renamed requestaccount-bio-text to requestaccount-bio-text2; this way the new version behaves the same as the old one (well, almost, see below).

Note: When $wgMakeUserPageFromBio is true, a line break is inserted between the two parts of the bio-text, which was not there before applying the patch. This is caused by the extra call to wfMsgExt, which wraps p-tags around the text. Maybe some knowledgeable person gets rid of this extra paragraph. Or we declare the new formatting to be the preferred one.
 * Does this have a bug report?Aaron 19:12, 12 September 2010 (UTC)

Invalid Argument in LocalisationCache, line 683
Hi,

upgraded to MW 1.16. and re-installed ConfirmAccount, now I get the error mentionend above - I traced it back to this extension - whenever I disable it in Localsettings everything is fine again. How does this fit? Any help is greatly appreciated THANKS --Fxk2
 * Hey, until now I have to keep this extension disabled because it somehow wrecks my install. can someone help or give any hints on the issues mentionend above? cheeers --Fxk2
 * Any help, anyone??? Please --Fxk2

log of actions other than approval
When an account is not approved, instead being actioned as 'Reject', 'Hold' or 'Spam', these actions should be in a log somewhere, but I can't see a log. I think the log should be private, like the suppression log, and only accessible to people with the permission to approve accounts. Is this an RFE ? John Vandenberg 08:11, 26 October 2010 (UTC)

Internationalisation does not work
Latest SVN code from http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/ConfirmAccount (revision 75783) installed in MW1.15.5 produces no internationalisation (i18n) text.

Instead, the raw tags are printed.

It appears the line ... wfLoadExtensionMessages('ConfirmAccount'); ... is missing from __construct in the files ConfirmAccount_body.php and UserCredentials_body.php

Adding this line to both files fixes the problem.
 * You need the 1.15 version of the extension. Aaron 06:39, 28 January 2011 (UTC)

Database error
I followed the first two steps, however was unsure about this step:

''Run maintenance/update.php (run ConfirmAccount.sql if not possible, substituting db prefix and options) mysql -h DB_HOST -u WIKIUSER -p WIKIDB < ConfirmAccount.sql''

I tried a few things however this error still occured.

The error message below would show when you click on "Request Account" on the registration page.

''A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "efCheckIfAccountNameIsPending". Database returned error "1146: Table ' .account_requests' doesn't exist ".'' Any help please?


 * You need to run the update script. If you don't have command line access, do you have phpMyAdmin?  It allows you to execute SQL&mdash;you can copy the code from ConfirmAccount.sql. —Emufarmers(T 03:29, 17 November 2010 (UTC)

Creation wiki
Looking through this list I know of one MediaWiki site ( CreationWiki ) that has the extension that is not in that list. MyrtonosGive me new messages 08:13, 27 December 2010 (UTC)

1.16 still missing ConfirmAccount.php?
I just downloaded the 1.16-r62787 package and the file isn't in there. Sort of unfortunate... 71.182.152.5
 * Indeed, is there any word on when this will be up and working? I'm combating spam like crazy right now, and I was really relying on this extension to assist.  FrankCarroll 23:33, 3 February 2011 (UTC)


 * Take a look at the setup instructions. —Emufarmers(T 23:41, 3 February 2011 (UTC)


 * Indeed it's confusing. The file is not supposed to be there. I assumed the snapshot was the latest version, so I followed the instructions for >1.16 without thinking. --ScottJ 23:41, 26 February 2011 (UTC)


 * In the instructions: " version =< 1.16 " should be written " version >=1.16 " and " version > 1.16 " should be written " version < 1.16 ". Makes sense (and works!) then. --Ozstang65 13:03, 28 February 2011 (UTC)

Installed confirm account extension, but now people cannot see my web page
I've installed the extension and was able to get it working, but now people cannot see my wiki unless they're already logged in. How do I fix it so everyone even if they're not logged in can see the wiki, but need to request and account if they want to edit? Brothejr 03:48, 28 January 2011 (UTC)
 * ConfirmAccount doesn't change 'read' permissions...you must have some other setting/extension causing this. Aaron 06:42, 28 January 2011 (UTC)
 * I understand, but everything I've seen in my localsettings.php file says that anonymous viewers should be able to view the pages, yet they cannot. Plus, I've noticed that anonymous users can view other pages just fine, but some pages like the main page, they cannot see that. My wiki is www.asylumprojects.org.  I'm not sure what to do and if you don't know or this isn't the place, please point me to the place where I can go.  We decided we needed this extension after a massive spammer attack which has been going on for over a couple days now with no end in sight without us implementing this change.  Edit: I think I've localized it just to just the main page not showing, plus I've noticed that there seems to be an issue with the preview button too on the main page, where if an editor his preview after editing, they get a blank page.  Brothejr 11:23, 28 January 2011 (UTC)
 * Check your PHP error logs. Aaron 07:06, 31 January 2011 (UTC)

Duplicate confirmation e-mails sent
Just installing this extension on my wiki and it looks really great. I have set $wgConfirmAccountContact to my e-mail address, but when a new user confirms their address I get *two* identical e-mails telling me to visit Special:ConfirmAccounts. Reloading the confirmation page (confirming the user's e-mail address a second time) results in a second set of two e-mails arriving. Commenting out $wgConfirmAccountContact results in me receiving no e-mails at all, as expected. This is with MW 1.16.2. -- Malvineous 09:10, 19 March 2011 (UTC)

1.17 problem
I just installed in 1.17 and when clicking lg in/create account I get Fatal error: Call to undefined method OutputPage::addModules in /home/nycwikiadmin/nycwiki/w/extensions/ConfirmAccount/ConfirmAccount.php on line 157

and also, going in on Special and clicking on Request account gives Fatal error: Call to undefined method OutputPage::addModules in /home/nycwikiadmin/nycwiki/w/extensions/ConfirmAccount/RequestAccount_body.php on line 77

Any clues? Wwwhatsup 19:22, 29 March 2011 (UTC)
 * Please use the 1.17 version of the extension. Aaron 01:35, 31 March 2011 (UTC)


 * Since no 1.17 version is listed here I went for 'trunk' i.e. 'ConfirmAccount-trunk-r84919'. Am I missing something? Wwwhatsup 07:56, 31 March 2011 (UTC)

Hmm. I switched to the 1.16 version and it seems to be working fine! Wwwhatsup 18:29, 31 March 2011 (UTC)
 * It's here. I guess the distributor isn't set for 1.17 yet. Aaron 01:15, 1 April 2011 (UTC)
 * Hey, it looks like I have a similar problem, my versions: MW 1.16. // ConfirmAccount r85197, my errors are exactly as described above, on line 77 and on line 157 - I'd like to switch to working version soon, using svn, but I don't know which one is it. --Fxk2 15:54, 2 April 2011 (UTC)
 * SVN switch to svn.wikimedia.org/svnroot/mediawiki/branches/REL1_16/extensions/ConfirmAccount. Aaron 19:42, 6 April 2011 (UTC)
 * I tried, it seems the extension (r85609) works fine now, but I keep having that other error message, as soon as your logged in: Warning: Invalid argument supplied for foreach in /home/...../includes/LocalisationCache.php on line 683.
 * Do you have any ideas on this? Thanks a lot --Fxk2 08:41, 7 April 2011 (UTC)

Internal & External IP address issue
Hi, I know that this is probably a very basic issue, but I am running Mediawiki with an internal IP address within our organisation, but we are presenting a different External IP address to the world. When a user uses the Request Account feature, it displays the INTERNAL IP address instead of the External IP Address. I have looked through the ConfirmAccount code and noticed that you are using the function getfullurl. There must be someplace where the External IP address is defined in a PHP config file but although I have read through lots of config settings for MediaWiki, I havent found a setting that yells "External IP address".

Could someone kindly point me to the correct way of configuring the external IP address so that when the ConfirmAccount Extension sends emails to the users, the correct IP address (EXTERNAL) is displayed on the links for the users to get back to the site rather than displaying the INTERNAL IP Address
 * You mean the site operates behind proxies somehow? If so, then look at wfIsTrustedProxy in ProxyTools.php. You might want to add a listener to that hook in there to ignore the proxy IPs. This works only if the proxies send XFF headers. Aaron 19:39, 6 April 2011 (UTC)

Perhaps I haven't been clear. We use NAT on the router so that a Public IP Address is routed to the internal Private IP address. But my MediaWiki is blissfully unaware of this and uses the Internal IP Address within hyperlinks that it includes on emails to users. How do I tell MediaWiki that I am using a different External IP Address. I have tried looking up phrases such as "External IP", "Public IP" and "NAT" all without success. Lorenzo 23:05 08 APR 2011 (UTC)
 * Did you set $wgServer? Aaron 08:02, 15 April 2011 (UTC)

Fatal error
Hello everybody. My ConfirmAccount version is 1.46. I recently updated to Mediawiki 1.16 – now everytime I want to confirm an user a "fatal error" occurs:

Fatal error: Class 'FileStore' not found in /www/htdocs/w00c0c62/extensions/ConfirmAccount/ConfirmAccount_body.php on line 481

I don't even use file attachments, $wgAccountRequestExtraInfo and $wgAllowAccountRequestFiles are set to "false". What can I do? Help, please! --188.110.236.197 23:31, 7 April 2011 (UTC)
 * Did you upgrade to the 1.16 version of the extension? Aaron 23:59, 7 April 2011 (UTC)


 * That must be the point, since FileStore is removed in MW 1.16 but used by the extension. How can I upgrade the extension? Just by replacing the files or do I have to run the SQL-script again, too? Is there anything special to consider? Thanks for your help! --188.110.236.197 10:00, 8 April 2011 (UTC)
 * Just replace the extension files with the 1.16 ones (it's easier to do with SVN with svn-switch, but using the unpacked tar files is OK). The uploaded files don't have to be moved or anything, there is backwards-compatibility code (in SpecialConfirmAccount.php for 1.16). Aaron 18:45, 8 April 2011 (UTC)

Error

SQL query:

-- (c) Aaron Schulz, 2007 -- Table structure for table `Confirm account` -- Replace /*$wgDBprefix*/ with the proper prefix -- This stores all of our reviews, -- the corresponding tags are stored in the tag table CREATE TABLE /*$wgDBprefix*/account_requests ( acr_id int UNSIGNED NOT NULL AUTO_INCREMENT, -- Usernames must be unique, must not be in the form of -- an IP address. _Shouldn't_ allow slashes or case -- conflicts. Spaces are allowed, and are _not_ converted -- to underscores like titles. See the User::newFromName for -- the specific tests that usernames have to pass. acr_name varchar(255) BINARY NOT NULL DEFAULT , -- Optional 'real name' to be displayed in credit listings acr_real_name varchar(255) BINARY NOT NULL DEFAULT , -- Note: email should be restricted, not public info. -- Same with passwords. acr_email tinytext NOT NULL, -- Initially NULL; when a user's e-mail address has been -- validated by returning with a ma[...]

MySQL said: Documentation
 * 1) 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=InnoDB' at line 65