Extension talk:ConfirmAccount/archive 3

Misc Bugs

• 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 them 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

--84.63.27.64 12:22, 19 March 2011 (UTC)

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.

-If it's cPanel based hosting, you usually have access to cronjobs. Set a temporary cronjob to run say, every five minutes, for the update.php script. Let it run and then disable the cronjob again. This is a slightly cleaner way than requiring the manual editing of the sql file. Ashimema (talk) 08:18, 11 April 2012 (UTC)

• 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.

I'm running Mediawiki 1.15 which still is considered the stable version on Debian Squeeze. I had the same problem with this extension, but then I just installed ConfirmAccount for Mediawiki 1.16 which is working perfectly. Leif B. Kristensen (talk) 23:35, 31 October 2012 (UTC)

I fixed this in Squeeze (1.15 + downloaded the extension (corresponding version) from the page). According to error_log, ConfirmAccount/SpecialConfirmAccount.php:247 requires that the user is passed as a reference. The call from extensions/ConfirmAccount/RequestAccount_body.php:239, however, passes the user as a value. I changed this:

if( !wfRunHooks( 'AbortNewAccount', array( $u, &$abortError ) ) ) {

To this:

if( !wfRunHooks( 'AbortNewAccount', array( &$u, &$abortError ) ) ) {

(note the ampersand before $u. Probably a compatibility bug. --Felipe Franciosi 17:21, 30 December 2012 (UTC)

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.

It would be a great feature to add to this extension.. I see it working best as an integration using the hooks availabel in semantic forms. Ashimema (talk) 12:40, 7 August 2012 (UTC)

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:

1. Grant account queue rights

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

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#efCheckIfAccountNameIsPending.28.29_error

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:

$wgAccountRequestTypes = array( 0 => array( 'reader', 'reviewer' ) ); 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:

$wgAccountRequestTypes = array(
   0 => array( 'reader', SOME USER GROUP ),
   1 => array( 'reviewer', SOME USER GROUP )
);

Aaron 21:29, 14 January 2010 (UTC)

Thanks for this useful example (perhaps add it to the page?). What does autotext do? The note, "The optional autotext value is added to the end of the user page of new accounts" is quite confusing. What is the 'user page of new accounts'? Cheers, excellent extension!--Dmb 10:10, 5 October 2011 (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:
#0 /Users/harryerw/Sites/mediawiki/extensions/ConfirmAccount/RequestAccount_body.php(239): wfRunHooks('AbortNewAccount', Array)
#1 /Users/harryerw/Sites/mediawiki/extensions/ConfirmAccount/RequestAccount_body.php(74): RequestAccountPage->doSubmit()
#2 /Users/harryerw/Sites/mediawiki/includes/SpecialPage.php(559): RequestAccountPage->execute(NULL)
#3 /Users/harryerw/Sites/mediawiki/includes/Wiki.php(229): SpecialPage::executePath(Object(Title))
#4 /Users/harryerw/Sites/mediawiki/includes/Wiki.php(59): MediaWiki->initializeSpecialCases(Object(Title), Object(OutputPage), Object(WebRequest))
#5 /Users/harryerw/Sites/mediawiki/index.php(116): MediaWiki->initialize(Object(Title), NULL, Object(OutputPage), Object(User), Object(WebRequest))
#6 {main}

Herwin 15:58, 8 February 2010 (UTC)

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.

<Here is the text that I type in the text input box. For example I say:>
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)

I had the sample problem but I found out that I had to whitelist the page Special:RequestAccount for anonymous users --85.181.85.33 11:25, 2 May 2011 (UTC)

I had the same problem because of the following mistake in LocalSettings.php. I used

$wgConfirmAccountContact='mymail@mydomain.com';

before

require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");

. Switching the order solved the problem.--95.89.17.149 02:42, 23 November 2012 (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

Fix

Extension can't count number of words in UTF8. You can fix it this way:

• ConfirmAccount/business/AccountRequestSubmission.php
• Find:

# Check if biography is long enough
if ( str_word_count( $this->bio ) < $wgAccountRequestMinWords ) {

• Replace with:

# Check if biography is long enough
$bioWordCount = preg_match_all("/\\p{L}[\\p{L}\\p{Mn}\\p{Pd}'\\x{2019}]*/u", $this->bio, $matches);
if ($bioWordCount < $wgAccountRequestMinWords) {

I used workaround from http://php.net/manual/en/function.str-word-count.php. --Jossmart (talk) 08:30, 12 September 2012 (UTC)

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 <usercredentials>
• there is a box with the title <usercredentials-leg>, and an input field with the title &lt;usercredentials-user&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 &lt;usercredentials-badid&gt;
• If the user does exists and was confirmed, the following is displayed:

• <usercredentials-text>
  
  &lt;usercredentials-leg-user&gt;Username: test
  &lt;usercredentials-email&gt; test@xxxxx.com
  &lt;confirmaccount-leg-areas&gt;
  &lt;usercredentials-leg-person&gt;&lt;usercredentials-real&gt; Test Name
  
  &lt;usercredentials-bio&gt;
  
  This is the bio provided when signing up
  &lt;usercredentials-leg-other&gt;
  &lt;usercredentials-ip&gt; 99.99.99.99

Does anyone know how I can get this to display properly? -- PhantomSteve/talk|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 ConfirmAccount.sql.

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:

-- (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 mailed token, this is
  -- set to the current timestamp.
  acr_email_authenticated binary(14) default NULL,
  -- Randomly generated token created when the e-mail address
  -- is set and a confirmation test mail sent.
  acr_email_token binary(32),
  -- Expiration date for the user_email_token
  acr_email_token_expires binary(14),
  -- A little about this user
  acr_bio mediumblob NOT NULL,
  -- Private info for reviewers to look at when considering request
  acr_notes mediumblob NOT NULL,
  -- Links to recognize/identify this user, CSV, may not be public
  acr_urls mediumblob NOT NULL,
  -- IP address
  acr_ip VARCHAR(255) NULL default '',
  -- Name of attached file (.pdf,.doc,.txt etc...)
  acr_filename VARCHAR(255) NULL,
  acr_storage_key VARCHAR(64) NULL,
  -- Prospective account access level
  acr_type tinyint(255) unsigned default 0,
  -- Areas of interest
  acr_areas mediumblob NOT NULL,

  -- Timestamp of account registration.
  acr_registration char(14) NOT NULL,

  -- Flag for rejected accounts
  acr_deleted bool NOT NULL,
  -- Time of rejection (if rejected)
  acr_rejected binary(14),
  -- Time request was put on hold (if held)
  acr_held binary(14),
  -- The user who rejected/held it
  acr_user int unsigned NOT NULL default 0,
  -- Reason
  acr_comment varchar(255) NOT NULL default '',

  PRIMARY KEY (acr_id),
  UNIQUE KEY (acr_name),
  UNIQUE KEY (acr_email(255)),
  INDEX (acr_email_token),
  INDEX acr_type_del_reg (acr_type,acr_deleted,acr_registration)
) TYPE=InnoDB;

-- This stores all of credential information
-- When accounts are confirmed, the identity info goes here
CREATE TABLE /*$wgDBprefix*/account_credentials (
  -- Revision ID #
  acd_id int unsigned NOT NULL auto_increment,
  -- Foreign key to user.user_id
  acd_user_id int unsigned NOT NULL,
  -- Optional 'real name' to be displayed in credit listings
  acd_real_name varchar(255) binary NOT NULL default '',
  -- Note: email should be restricted, not public info.
  -- Same with passwords.
  acd_email tinytext NOT NULL,
  -- Initially NULL; when a user's e-mail address has been
  -- validated by returning with a mailed token, this is
  -- set to the current timestamp.
  acd_email_authenticated binary(14) default NULL,
  -- A little about this user
  acd_bio mediumblob NOT NULL,
  -- Private info for reviewers to look at when considering request
  acd_notes mediumblob NOT NULL,
  -- Links to recognize/identify this user, CSV, may not be public
  acd_urls mediumblob NOT NULL,
  -- IP address
  acd_ip VARCHAR(255) NULL default '',
  -- Name of attached file (.pdf,.doc,.txt etc...)
  acd_filename VARCHAR(255) NULL,
  acd_storage_key VARCHAR(64) NULL,
  -- Areas of interest
  acd_areas mediumblob NOT NULL,

  -- Timestamp of account registration.
  acd_registration char(14) NOT NULL,

  -- Timestamp of acceptance
  acd_accepted binary(14),
  -- The user who accepted it
  acd_user int unsigned NOT NULL default 0,
  -- Reason given in email
  acd_comment varchar(255) NOT NULL default '',

  PRIMARY KEY (acd_user_id,acd_id),
  UNIQUE KEY (acd_id)

) TYPE=InnoDB;

Hope this helps! -- PhantomSteve/talk|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:

• 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" );

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)

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? {{Welcome}} {{Rules}} {{Help:Contents}} Will the page also handle the <noinclude> and <includeonly> 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:

• ConfirmAccount/RequestAccount_body.php: Replace the line

$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 [1].

• 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 [2]. 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

Oha, I activated the extension, fresh snapshot-install and the same error occurs. And the page "Confirm Account Requests" doesn't show up on "Special Pages" - how is that possible? - Any suggestions for solving this problem? PLEASE & Thanks --Fxk2 06:24, 27 April 2011 (UTC)

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 '<database name>.account_requests' doesn't exist <database address>". 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—you can copy the code from ConfirmAccount.sql. —Emufarmers^(T|C) 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. Myrtonos^{Give 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|C) 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)

Sorry, I didn't understand what you mean, but neither do I understand the instructions - what to use for 1.16.4 ?? -- cheers Fxk2 06:21, 27 April 2011 (UTC)

DNHDNYUSCCCCCDAXXXXDGGGJZZZZZGMMF§[[:Image:]]

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)

SQL syntax error

Hey, i can not run update.php or add in the code in phpmyadmin from the sql file stated because there is an error in syntax. I have mysql 5.5.8.

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

SOLVEDReplace Type==InnoDB; with ENGINE=InnoDB; Type is deprecated and removed.

Use With Godaddy?

I'm wondering how to use this with GoDaddy? I can't execute a PHP file (at least that I can find), and the 3rd step says it's needed. If I only edit LocalSettings.php, I get a SQL error indicating that a table doesn't exist.

I tried setting the file permissions to allow execution of the update.php file, and accessed it through the browser, but I still had the error. I'm using 1.16.2, and so I removed the line that I had added to LocalSettings.php, and the wiki works fine, but I would really like to get ConfirmAccount working.

Thanks for any help! Misty Fowler

Hi Misty Fowler - to run a command on the command line at godaddy, you need to be on a server that supports SSH. I just moved mine that way recently for the same reason. godaddy has full documentation on how to perform the upgrade/move as well as how to connect via SSH using putty. At that point to run the update.php you'll need to use the full path to php5, /web/cgi-bin/php5 maintenance/update.php. If that still doesn't work, you can run the sql script via cut and paste into a phpmyadmin session (this is what I ended up doing) and if you receive an 1170 error on an index, there is a message on that further below.

Hope this helps

link to added file

Hi, I am using version 1.16 of Mediawiki and appopriate version of Confirm account. Currently I am customizing the MediaWiki on localhost. I am trying to create an account and attach a file. However, once I log in as a bureaucrat and attempt to view the file that was added (for example cv.pdf) and press on the link, the file that is being opened is not cv.pdf, but index.php. How can I view the file that was attached? Thank you in advance!

Hello-- encountering the same issue in version 1.22 of MediaWiki and using the most current version of the extension.

FAIL

I have read over all these comments and everything on how "CREATE TABLE mw_account_requests and down further in the file: CREATE TABLE mw_account_credentials."

Let's face it Aaron, this table making thing needs to be explained better. I have spent days trying to understand this. Your not explaining it at all. There is too many assumptions in the Setup section on the page. You need to explain there in detail what you have to do. I don't get it, and I'm getting very frustrated. I have even asked friends that are also programers and they tell me that Aaron or whoever made that didn't give proper info to work from. Devilmanozzy 15:17, 28 May 2011 (UTC)

Running the update.php file in the MediaWiki/maintenance folder will run ConfirmAccount.sql and create the tables in your database automatically. --Dgennaro 13:54, 31 May 2011 (UTC)

SQL Error 1091

I run update.php and I get this error:

The last attempted database query was: "ALTER TABLE `account_requests`

ADD acr_type tinyint(255) default 0,
DROP INDEX acr_deleted_reg,
ADD INDEX acr_type_del_reg (acr_type,acr_deleted,acr_registration)"

from within function "DatabaseBase::sourceStream". Database returned error "1091: Can't DROP 'acr_deleted_reg'; check that column/key exists (127.0.0.1)"

Lordy lord, this extension has been a nightmare. First I had the SQL error where I had to change the code to ENGINE=InnoDB and now I have this. Any solution?

Someone?

I just delete this line DROP INDEX acr_deleted_reg, in patch-account_credentials.sql at ConfirmAccount\backend\schema\mysql

And it worked for me.

--118.161.176.39 19:20, 14 February 2013 (UTC)

SQL Error 1060

I run update.php and I get this error:

The last attempted database query was: "ALTER TABLE `wikidbaccount_requests`

ADD acr_type tinyint(255) unsigned NOT NULL default 0,
ADD INDEX acr_type_del_reg (acr_type,acr_deleted,acr_registration)

" from within function "DatabaseBase::sourceFile( /var/www/html/wiki/extensions/ConfirmAccount/backend/schema/mysql/patch-account_credentials.sql )". Database returned error "1060: Duplicate column name 'acr_type' (localhost)"

I'm running on wiki 1.21.1 and I can't handle this, do you have some ideas?

I'm having the same issue on 1.20 (after having and resolving the 1091 error). Help? -User:K_llandon (1/20/2013)

One Issue (Chrome), One request (Group Permission)

Installed extension, took about an an hour to get the extension installed to work. (some of the options set in Localsettings.php need to be in a certain order to work).

Only issue I have is with the Chrome Browser. On the main page, upper right, were it tells you if you have any confirmed accounts waiting for approval. On IE/firefox, the redirect link works, while on the Chrome browser, there is no link at all.

The request I have, is instead off of drop down menau of author/editor, how about a check box series for all available groups. My wiki, i have uploadaccess, editor, user, forumreadonly, and etc groups. This would make creating an account a breeze, instead of having to go to multiple locations on the wiki to setup the account.

Beyond this, great extension, works in MediaWiki 1.16.5/ PHP 5.2.17 (cgi)/ MySQL 5.0.91mm-log / Hosted/Shared server Lynxcub 18:48, 29 July 2011 (UTC)

Request Account Problem

I get the following error, when trying to request an account: Fatal error: Call to undefined method Status::toString() in ..\extensions\ConfirmAccount\RequestAccount_body.php on line 375

Install the right extension version for your MW version (and sign your posts ;-) --Dmb 13:03, 5 October 2011 (UTC)

I get the same error as the anonymous user is reporting: PHP Fatal error: Call to undefined method Status::toString() in XXXX/extensions/ConfirmAccount/RequestAccount_body.php on line 375 This is with ConfirmAccount-MW1.17-r90727.tar.gz, and MediaWiki 1.17, PHP 5.3.2-1ubuntu4.10. -- Hazelnusse Tue Oct 25 00:03:51 UTC 2011

I just tried setting this up and also get the same error :( . Setup using latest versions of xampp and MW/ConfirmAccount extension. Any ideas? -- Ad Tue Oct 25 17:24 UTC 2011

Fixed in r100948. Aaron 06:02, 27 October 2011 (UTC)

Question about "option"

the Command of $wgAccountRequestThrottle states that "Count of how many requests can come from an IP address per day. This only matters if throttling is true. [Type: positive integer]."

Question is, what is the command to set the "throttling" to true/false Lynxcub 14:56, 3 August 2011 (UTC)

Questions related to Request Account Tempate and Confimation E-mail

Let me preface this by apologizing for being a complete novice nonetheless I would greatly appreciate help with these issues:

1) On the Special:RequestAccount the user is unable to follow the path to the Terms of Service link how can I open this page to the potential user?

2) How do I edit the phrase "Personal Biography" to something which fits my wiki more appropriately?

3) How do I edit the language contained in the e-mails which are sent to users as a result of creating an account?

Thank you.

To answer your questions:

1) use the following command inside your LocalSettings.PHP

$wgWhitelistRead = array ( "Main Page", "Special:Userlogin", "Special:RequestAccount", "Special:Login", "XXXX:Terms_of_Service");

replace XXXX with whatever comes after /index.php?title= in your titlebar

2) 2 and 3 are the same answer. Go to your SpecialPages, then find System messages. In the Filter by prefix section search for both requestaccount and confirmaccount. Look for the items you are wanting to change. Save and test. You might need to go in there a few times to change what you need. There is more than one section with "Biography" Lynxcub

Wonderful. Thank you. -Brad

Forms

I'm wondering if there's been any thoughts on adding support for including extra forms fields in the request form without butchering the php code manually.

There's a number of Form extensions (my personal favourite being SemanticForms so I'm wondering if some sort of compatibility could be added in? Ashimema 17:40, 31 August 2011 (UTC)

$wgPasswordSenderName for admin email

Minor change, but identifies email by admin specified name. Revise RequestAccount_body.php line 330 to: $source = new MailAddress( $wgPasswordSender , $wgPasswordSenderName ); Not a big deal, but perhaps better identifies the email, if $wgPasswordSender is an unusual address.PolicyReformer 21:30, 4 October 2011 (UTC)

Added in r99331. Aaron 00:05, 9 October 2011 (UTC)

Check previously confirmed accounts

Hi,

Quick question - how do I check previously accepted accounts and the information that was presented to me at the time of review (IP, email, short description etc.)? Is there a log somewhere?

Thanks Veryhuman 12:16, 5 October 2011 (UTC)

Special:UserCredentials. Aaron 23:57, 8 October 2011 (UTC)

Docs bad or a bug...

I'm using http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_17/extensions/ConfirmAccount

and configuring $wgAccountRequestTypes. I don't find it written anywhere that I need to edit MediaWiki:Requestaccount-level-0 / MediaWiki:Requestaccount-level-1 / etc.

I expected the strings here to come from the array ... "The subpage param (string) is used to separate the queues when browsing Special:ConfirmAccount."

Is this a bug in the docs or in the code?

I found values like 'author', 'editor', '<requestaccount-level-2>' in the 'Position' field of Special:RequestAccount and in the display of Special:ConfirmAccount. This text lead me to find the above mentioned messages and edit them to reflect what I had already put in the subpage param of the $wgAccountRequestTypes array.

I guess I'll log this if you don't reply.

Cheers, --Dmb 13:02, 5 October 2011 (UTC)

This is as intended. The subpage parameter used in the URL is decided by the array, where as the name of the request type is determined by the MediaWiki:requestaccount-level-* page. Also, if the requesting user is viewing the form in language xx, and MediaWiki:requestaccount-level-*/xx exists, that will be used instead of MediaWiki:requestaccount-level-*. Aaron 00:15, 9 October 2011 (UTC)

$wgAccountRequestTypes > 1

The LocalSettings.php file contains an array (sample)

$wgAccountRequestTypes = array(
   0 => array( 'abc', 'read')
   1 => array( 'def', 'write')
);

There's a check within the RequestAccount_body.php file, if the $wgAccountRequestTypes array has size > 1 and it seems that the array won't be overwritten. It always contains only one Entry (Authors). Is there something wrong with my configuration?

Mediawikie version: 1.17 Extension Version: latest version (at about 7 days old)

You are missing a comma after "'read')". Aaron 06:20, 10 November 2011 (UTC)

Sorry, my fault..define the array before loading the extension is not a good idea ;)

The selectbox is available now, but...

...a defined array

$wgAccountRequestTypes = array(
  0 => array( 'read', 'Lehrer'),
  1 => array( 'write', 'Eltern'),
  2 => array( 'read-write', 'Schueler')
);

creates this selectlist ?!

<select name="wpType">
   <option value="0" selected="selected">Autor</option>
   <option value="1">Bearbeiter</option>
   <option value="2">&lt;requestaccount-level-2&gt;</option>
</select>

Create the page MediaWiki:Requestaccount-level-2 with what you'd like to be displayed there. —Emufarmers^(T|C) 00:10, 11 November 2011 (UTC)

Wiki is on Virtual Domain. Email From is showing webmaster@wrong_domain.

I am running MediaWiki 1.16.4 with a ConfirmAccount extension with file dates no newer than 28 Jul 2010. This is on a server that has multiple Apache virtual domains using a single IP address. I have the $wgConfirmAccountContact set to the email address of a mailing list run by Mailman (wiki-admin@RIGHT_DOMAIN). Email is going to that list and distributed to the folks who can review accounts.

The problem is that the "From: " field in all email sent by the extension shows "webmaster@WRONG_DOMAIN" where WRONG_DOMAIN is another domain on this server.

I have set the Apache ServerAdmin to webmaster@RIGHT_DOMAIN for every virtual host.

What is the source of the "From: " field in the emails sent by ConfirmAccount? How can I change it?

You might want to look at $wgSMTP. Aaron 07:43, 2 December 2011 (UTC)

Automatic confirmation

Hello, would it be easy/possible to add the following feature: a configuration options specifies a list of domain names (in the form of a regular expression, e.g. like *@wikimedia.org), and if an email address that matches one of these is confirmed, the account is automatically created without any need for manual approval. This would be very useful for accounts given within an organization in which email addresses are well controlled. I have looked at the source code, and adding the configuration option and the check seem straightforward, but I am not too sure about how to jump from the "email confirmed" part to the "create account" part. Best wishes, Schutz 11:11, 22 November 2011 (UTC)

I don't see any easy way to that atm. Aaron 07:59, 2 December 2011 (UTC)

Says that I must be logged in to use special:requestaccount

I needed to whitelist the the page. Manual:Preventing access#Restrict account creation

Notification of a new account request

There is the clear notification option for confirmations. But is there an option for admins being notified upon every request?

My wiki is small and if new users have to wait a day before getting their account, then they might lose interest and not come back. Not a good user experience.... Maybe there is an option for me to "watch" the Special:ConfirmAccounts page???

Admins can see notices on their watchlists about email confirmed account requests. I'm not sure exactly what is desired here. Aaron 08:34, 4 January 2012 (UTC)

$wgConfirmAccountContact='email@here'; will notify you when user confirms account. if they don't confirm account, why would you care?

SQL Error 1170: BLOB/TEXT column 'acr_email' used in key specification without a key length (localhost)

I've got MW 1.18 installed and downloaded ConfirmAccount using the >=1.17 link today. My server has PHP 5.3.5 (cgi-fcgi) and MySQL 5.1.54-log. I ran the maintenance/update.php script from the command line in Terminal and the table appears to have been created successfully, but when it tried to create the index on acr_email_token it failed with the following error:

Creating account_requests table...A database query syntax error has occurred. The last attempted database query was: "CREATE INDEX acr_email_token ON `mw_account_requests` (acr_email_token) " from within function "DatabaseBase::sourceFile( /users/home/dreimiller/domains/newlondonrocks.com/web/public/wiki/extensions/ConfirmAccount/ConfirmAccount.sql )". Database returned error "1170: BLOB/TEXT column 'acr_email' used in key specification without a key length (localhost)"

I tried using phpMyAdmin to set the index on that field and got the same error. Any ideas or suggestions? --Dreimiller 21:05, 3 January 2012 (UTC)

That error seems to be about acr_email, but the index on that is given a prefix length already. Can you pastebin what the sql file looks like? I don't see how this can happen. Aaron 08:33, 4 January 2012 (UTC)

Here you go, Aaron: ConfirmAccount.sql. --Dreimiller 20:38, 4 January 2012 (UTC)

It seems to be a problem with some MySQL versions. The following worked for me: I dropped the index acr_email, then created those ohter two indices, and finally created the acr_email index again.

I dropped the mw_accoount_requests table, which is the only one that was created before the SQL failed. I then edited the ConfirmAccount.sql file to move the line "CREATE UNIQUE INDEX /*i*/acr_email ON /*_*/account_requests (acr_email(255));" so that it followed the "CREATE INDEX /*i*/acr_type_del_reg ON /*_*/account_requests (acr_type,acr_deleted,acr_registration);" line. I then re-ran maintenance/update.php and the SQL ran without error. Thanks for the help, Aaron. --Dreimiller 13:02, 24 February 2012 (UTC)

I confirm this change works on a pre-set up wiki using godaddy hosting using the pre-loaded MediaWiki 1.19.0 set up and MySql 5.0.95 and PHP 5.3.6.

yes, this worked for me too. Deleting (dropping) the account_requests table using MySQL and then changing ConfirmAccount.sql as above did the trick. Make sure you don't just tweak ConfirmAccount.sql - if you don't delete the account_requests table, it doesn't work Jpmaytum (talk) 17:17, 25 September 2012 (UTC)

This was very helpful for me as well, as I was running into the same error. Dropping the acr_email index, then creating the missing indexes, followed by recreating the acr_email mail index resolved the problem. My installation is also on godaddy. --Jrandomguy (talk) 03:57, 25 June 2012 (UTC)

Same error here, but solution above did not work for me. Using standard debian 5.1.63-0+squeeze1 and testing newest 1.20 trunk (git). Why is acr_email "tinytext NOT NULL" but still desires a unique index? tinytext is essentially a blob, like text, and indexing behavior is special (and might perhaps be mysql-version dependent? I don't know but others report similar problems on the web). varchar(255) would make much more sense to me... Tried changing acr_email to varchar(255), -> ./maintenance/update.php goes through. Not sure yet whether any downstream problems with the ConfirmAccount code will occur. --G.Hagedorn (talk) 23:57, 24 September 2012 (UTC)

I had the same trouble; Dreimiller's solution worked for me. Do i need to restore ConfirmAccount.sql afterwards? Meng6 (talk) 06:15, 12 October 2012 (UTC)

I had the same problem but did another approach: logging into mysql and did "ALTER TABLE account_requests MODIFY acr_email varchar(255);" and re-run update.php. I also do not see why this column is tinytext. 80.64.189.81

Anyone Watching this Extension!?

This extension has been a living nightmare! Why have you made such an unnecessarily difficult script?

I am consistiently receiving the following AFTER I upload the .sql file to my database:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: SELECT 1 FROM `mdw_account_requests` WHERE acr_name = 'Test' LIMIT 1 from within function "UserAccountRequest::acquireUsername". Database returned error "1146: Table 'neveren6_mdw2.mdw_account_requests' doesn't exist (localhost)

Whats going on here? I have wasted 3 days trying to get SOMEWHERE with this...I dont see anywhere in the above with an error quite like this.

I am begging at this point for some assistance on this.

Did you run update.php? Aaron 05:54, 23 January 2012 (UTC)

Sure did, several times. Heres what I get:

<Fatal error</b>: call to undefined method MysqlUpdater::addExtensionField() in <b>public_html/extensions/ConfirmAccount<br>
/backend/schema/ConfirmAccountUpdater.hooks.php</b> on line <b>17</b><br />

....so, seriously, any idea's here? Its effectively caused my site to linger in limbo cause its just as puzzeling the results I get when attempting to remove the extension. And really, I have so many spam sign ups I have no choice but to wait for someone to figure this out. In addition, this extension bleeds into other areas of my site, namely Special Pages:Recent changes. I get this error when trying to access it:
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

SELECT COUNT(*) FROM `mdw_account_requests` WHERE acr_deleted = '0' AND <br />
(acr_held IS NULL) AND (acr_email_authenticated IS NOT NULL) LIMIT 1

from within function "ConfirmAccount::getOpenEmailConfirmedCount". Database returned error "1146: Table 'neveren6_mdw.mdw_account_requests' doesn't exist (localhost)".
Seriously? Guido 19:53, 23 January 2012 (UTC)

Are you running a version of MW and a version of the ConfirmAccount extension that don't match? addExtensionField() is definitely defined in the /trunk version of MW. Aaron 06:05, 24 January 2012 (UTC)

Also, faster feedback can happen on #mediawiki IRC. Aaron 06:08, 24 January 2012 (UTC)

Just installed this extension on a MW 18.1 that was subject to heavy spam despite all anti-spam tricks I could figure out - Had no problem at all :) - Daniel K. Schneider (talk) 10:59, 21 February 2012 (UTC)

I had the same problem. It occurred because I was using MW REL_18_0 and the svn trunk of this extension. As Aaron pointed out, you need to make sure that you get the ConfirmAccount version that matches your MW version. Pgr94 (talk) 13:17, 26 March 2012 (UTC)

I am having this same problem on a MW REL_18_3 install. 8.30.79.4 13:26, 2 May 2012 (UTC);

I had the same problem when trying to install the 1.19 version to a 1.19 wiki but using the 1.20 version of account confirm fixed it

Problem with 1.18x

I encounter the following error when trying to create an account on the version for 1.18x on 1.18.1: Fatal error: Call to a member function getName() on a non-object in [masked]/mediawiki-1.18.1/extensions/ConfirmAccount/ConfirmAccount.php on line 178 Hello? Any help on this?

You might have another extension triggering one of the user hooks without a User argument. Aaron (talk) 00:24, 25 February 2012 (UTC)

Hi. I have no other extension installed. Just ConfirmAccount and it happens when I try to create an account. (Peter)

Search your copy of the code for "wfRunHooks( 'AbortNewAccount'" and see what turns up. All of those should pass a User object. The one in Special:Login clearly would have fataled if it wasn't before even reaching the hook. Aaron (talk) 05:08, 23 March 2012 (UTC)

Updating 1.18.1 fails with webupdater

when calling the mediawiki 1.18.1 webinstaller to run the update.php I'm running into the following problem

An error occured:
A database query syntax error has occurred.
The last attempted database query was:
"ALTER TABLE `account_requests`
 ADD acr_type tinyint(255) unsigned NOT NULL default 0,
 DROP INDEX acr_deleted_reg,
 ADD INDEX acr_type_del_reg (acr_type,acr_deleted,acr_registration)
"
from within function "DatabaseBase::sourceFile( /home/httpd/vhosts/wiki-products.org/subdomains/en/httpdocs/extensions/ConfirmAccount/archives/patch-account_credentials.sql )".
Database returned error "1091: Can't DROP 'acr_deleted_reg'; check that column/key exists (localhost)"
Backtrace:
#0 httpdocs/includes/db/Database.php(827): DatabaseBase->reportQueryError('Can't DROP 'acr...', 1091, 'ALTER TABLE `ac...', 'DatabaseBase::s...', false)
#1 httpdocs/includes/db/Database.php(3026): DatabaseBase->query('ALTER TABLE `ac...', 'DatabaseBase::s...')
#2 httpdocs/includes/db/Database.php(2924): DatabaseBase->sourceStream(Resource id #290, false, false, 'DatabaseBase::s...')
#3 httpdocs/includes/installer/DatabaseUpdater.php(362): DatabaseBase->sourceFile('/home/httpd/vho...')
#4 httpdocs/includes/installer/DatabaseUpdater.php(379): DatabaseUpdater->applyPatch('/home/httpd/vho...', true)
#5 httpdocs/includes/installer/DatabaseUpdater.php(233): DatabaseUpdater->addTable('account_credent...', '/home/httpd/vho...', true)
#6 httpdocs/includes/installer/DatabaseUpdater.php(201): DatabaseUpdater->runUpdates(Array, Array)
#7 httpdocs/includes/installer/DatabaseInstaller.php(248): DatabaseUpdater->doUpdates(Array, true)
#8 httpdocs/includes/installer/WebInstallerPage.php(513): DatabaseInstaller->doUpgrade()
#9 httpdocs/includes/installer/WebInstaller.php(254): WebInstaller_Upgrade->execute()
#10 httpdocs/mw-config/index.php(50): WebInstaller->execute()
#11 httpdocs/mw-config/index.php(18): wfInstallerMain()
#12 {main}

update.php stalls.

--Francishunger (talk) 22:42, 19 February 2012 (UTC)

Are you trying to install it for the first time? I've seen other people have the acr_email error. Have you tried #SQL_Error_1170:_BLOB.2FTEXT_column_.27acr_email.27_used_in_key_specification_without_a_key_length_.28localhost.29? Aaron (talk) 20:53, 29 February 2012 (UTC)

thanks for pointing me there. The proposed solution worked. --Francishunger (talk) 20:34, 1 March 2012 (UTC)

http 500 when a new user try to register (version 1.18.1)

I have installed the extention according to the manual and the database is updated with "account_creditals" and "account_requests" fields. However when I test the application by filling out the account request form and it the request button (send button), I recieve a http 500 error message, page can't be shown. What could the problem be ? Anything I've missed ? I am using Norwegian language if that matters.

Regards Petter Enge

Check the PHP or apache error logs. Aaron (talk) 17:06, 7 March 2012 (UTC)

Could you please tell me were I find this log ? I am using an external provider. (Petter)

Found the problem. I had a Blacklist extention enabled. I disabled the extention in the LocalSetting and the error went away. I will continue the testing.-

Error sending mail: Policy restriction in effect. The fifth parameter is disabled on this system

Can anyone solve this problem?

Error sending mail:

Policy restriction in effect. The fifth parameter is disabled on this system

Mediawiki 1.18.0

Safe mode off

What are your other extensions?--Jasper Deng (talk) 16:20, 31 March 2012 (UTC)

ConfirmAccount - get the error message here

ConfirmEdit -disabled at the moment

Gadgets

intersection

Nuke

ParserFunctions

Renameuser

RSSReader

SpamBlacklist

Vector

WikiEditor

Most of them are in the standard installation.

OK, so is email enabled in your PHP settings?--Jasper Deng (talk) 19:11, 31 March 2012 (UTC)

yes, and it works fine. I can fill out the form and send it. The reciver get an email with an activation link, that works fine too. After sending the form the error shows.

Did you start debugging?--Jasper Deng (talk) 18:29, 1 April 2012 (UTC)

Fatal error: Call to undefined method User::getEditToken() in

I am running MW 1_18_3 (just updated) and get this error when someone tries to create an account:

Fatal error: Call to undefined method User::getEditToken() in $HOME/wikidir/extensions/ConfirmAccount/frontend/specialpages/actions/RequestAccount_body.php on line 234

Also, as others have noted, I still see this error on attempts to update:

$ php update.php 
MediaWiki 1.18.3 Updater

Going to run database updates for fwiki-fwiki
Depending on the size of your database this may take a while!
Abort with control-c in the next five seconds (skip this countdown with --quick) ... 0
Fatal error: Call to undefined method MysqlUpdater::addExtensionField() in $HOMEW/wikidir/extensions/ConfirmAccount/backend/schema/ConfirmAccountUpdater.hooks.php on line 17
$

As you can see, I am running MW 1.18.3.

The version of ConfirmAccount I am using is:

$ svn info
Path: .
URL: http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/ConfirmAccount
Repository Root: http://svn.wikimedia.org/svnroot/mediawiki
Repository UUID: dd0e9695-b195-4be7-bd10-2dea1a65a6b6
Revision: 115105
Node Kind: directory
Schedule: normal
Last Changed Author: raymond
Last Changed Rev: 115102
Last Changed Date: 2012-05-01 11:42:15 -0700 (Tue, 01 May 2012)

Any thoughts?

You should use the 1.18 version of the extension. Aaron (talk) 06:19, 6 May 2012 (UTC)

I get the same. I couldn't get the "get snapshot" to work (I get Invalid response from remote subversion client.) - so went to SVN checkout-url and copied the files/directories from there (Revision 115157) - which appears to be the most recent version... which revision do I need for 1.18.0?. The db database worked ok by the way (tables created: account_requests - with 4 indexes;account_credentials - with 1 index).

However, the "request account" link on my wiki gives the "Fatal error: Call to undefined method User::getEditToken() in /home/sepe5826/public_html/wiki/extensions/ConfirmAccount/frontend/specialpages/actions/RequestAccount_body.php on line 234" message - and if I go to Special:ConfirmAccounts, I get an internal error (with a message "Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.")

If I use $wgShowExceptionDetails = true; then I get this:

Call to undefined method ConfirmAccountsPage::getLanguage
Backtrace:
#0 /home/sepe5826/public_html/wiki/extensions/ConfirmAccount/frontend/specialpages/actions/ConfirmAccount_body.php(211): SpecialPage->__call('getLanguage', Array)
#1 /home/sepe5826/public_html/wiki/extensions/ConfirmAccount/frontend/specialpages/actions/ConfirmAccount_body.php(211): ConfirmAccountsPage->getLanguage()
#2 /home/sepe5826/public_html/wiki/extensions/ConfirmAccount/frontend/specialpages/actions/ConfirmAccount_body.php(105): ConfirmAccountsPage->showQueues()
#3 /home/sepe5826/public_html/wiki/includes/SpecialPageFactory.php(458): ConfirmAccountsPage->execute(NULL)
#4 /home/sepe5826/public_html/wiki/includes/Wiki.php(226): SpecialPageFactory::executePath(Object(Title), Object(RequestContext))
#5 /home/sepe5826/public_html/wiki/includes/Wiki.php(626): MediaWiki->performRequest()
#6 /home/sepe5826/public_html/wiki/includes/Wiki.php(533): MediaWiki->main()
#7 /home/sepe5826/public_html/wiki/index.php(57): MediaWiki->run()
#8 {main}

I am using MediaWiki v1.18.0. Regards, -- PhantomSteve/talk|contribs\ 21:51, 7 May 2012 (UTC)

The version in Subversion should always be assumed to be trunk, i.e. it may be liable to fail if you aren't using a trunk version of MediaWiki.--Jasper Deng (talk) 21:53, 7 May 2012 (UTC)

OK, I get that - but without the "Download snapshot" working, how can I find out which version I should use for my version of MediaWiki? In this case, I am probably going to try to install the latest version of MW, but in future I may not wish to do that, so need to download "older" versions from SVN -- PhantomSteve/talk|contribs\ 22:04, 7 May 2012 (UTC)

That I do not know. I think the extension distributor needs to be upgraded to work with Git - something's awfully wrong.--Jasper Deng (talk) 22:07, 7 May 2012 (UTC)

PHP Fatal error: Call to undefined method MysqlUpdater::addExtensionField()

Hi,

I am running 1.18.3. When I try to make the update, I have the following error:

php maintenance/update.php 
MediaWiki 1.18.3 Updater

Going to run database updates for wikidb Depending on the size of your database this may take a while! Abort with control-c in the next five seconds (skip this countdown with --quick) ... 0 PHP Fatal error: Call to undefined method MysqlUpdater::addExtensionField() in /opt/www/mediawiki/extensions/ConfirmAccount/backend/schema/ConfirmAccountUpdater.hooks.php on line 17

my svn info

svn info
Path: .
URL: http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/ConfirmAccount
Repository Root: http://svn.wikimedia.org/svnroot/mediawiki
Repository UUID: dd0e9695-b195-4be7-bd10-2dea1a65a6b6
Revision: 115126 
Node Kind: directory
Schedule: normal
Last Changed Author: raymond
Last Changed Rev: 115102
Last Changed Date: 2012-05-01 18:42:15 +0000 (Tue, 01 May 2012)

Any idea ?

Thank you

You are mixing MW 1.18 with the trunk version of ConfirmAccount. That always tends to cause breakage due to core interfaces changes. Aaron (talk) 21:44, 12 May 2012 (UTC)

Hijacking?

OK, I've updated my wiki to 1.19.0. I can use the "Request" page OK.

However, when I go to confirm, it doesn't work! Special:ConfirmAccounts works ok, showing the queues available. Obviously, the only queue with anything in it is the "open requests" queue. When I go to that queue, it shows all the entries correctly (including "confirmed" where appropriate against the email address). However, when I go to the individual entry to "Review", although everything is showing OK, whichever option I choose out of "Accept", "Reject", "Hold", "Spam" - or, indeed, if I choose none of these options - I get a box at the top of the screen saying "There seems to be a problem with your login session; this action has been cancelled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.".

I have used Chrome 18.0.1025.168, Safari 5.1.5, IE 9.0.8112.16421 64-bit edition, Firefox 12.0 and Opera 11.62 - they all have the same error.

I am using MediaWiki 1.19.0 and the latest version of ConfirmAccount.

Any ideas? -- PhantomSteve/talk|contribs\ 00:21, 8 May 2012 (UTC)

Did you try clearing your browser's cache?--Jasper Deng (talk) 00:28, 8 May 2012 (UTC)

Yes, I did - it still happens. -- PhantomSteve/talk|contribs\ 04:09, 8 May 2012 (UTC)

Then I really don't know... of interest is that I get this error message if I try to rollback an edit to a fully protected page on enwiki, in addition to the full protection message.--Jasper Deng (talk) 04:11, 8 May 2012 (UTC)

Fixed in r115264. Aaron (talk) 21:40, 12 May 2012 (UTC)

Fatal error: Call to a member function

If the applicant forget to fill in his/her's user name, the script breaks with the message:

Fatal error: Call to a member function getName() on a non-object in /..../ConfirmAccount.php on line 193

I.m using Mediawiki 1.18

Could you solve this? -Bert

account request submission error

On submission of an account request, if the 'Real name' field is left empty, we get -

Fatal error: Call to a member function getName() on a non-object in /home/atwork/public_html/devwiki/w/extensions/ConfirmAccount/SpecialConfirmAccount.php on line 151

Mediawiki ver. 1.162 - appears to be the same error that was just posted by Bert...

Any idea why?

Thanks for any leads, Paul N.

what happened to notification of account requests?!

I recall older versions of this extension had notifications for bureaucrats notifying them of open requests. E-mail and site notifications used to be available. However, I am not seeing either anymore.

I just did a fresh install of the extension checked out from the latest SVN revision (r115546) on MediaWiki 1.19 running PHP 5.3.

I think this is a pretty critical function for bureaucrats and administrators.

Any help?

Sure - Just add

$wgConfirmAccountContact='email@here';

to your LocalSettings.php after the inclusion of ConfirmAccount. This will not send a mail to all administrators, only to the email-adress (i use a mailing-list)
--BLinz (talk) 20:26, 26 June 2012 (UTC)

Download currently broken?

I rather urgently need to download the latest version of this extension.

Sadly there isn't one: All the links to the GIT repository give me a 404 error and the main download link says this:

Download MediaWiki extension Jump to: navigation, search

No such extension "ConfirmAccount"

Can someone provide me with a mirror or possibly fix this?

http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_19/extensions/ConfirmAccount/ 24.130.249.87

"Review" doesn't work. SpecialPage doesn't exist

Hi.

This extension works up until I try and do either of these two things.

1. Click the Review in which I get this: The website encountered an error while retrieving http://localhost:8888/4/index.php?title=Special:ConfirmAccounts/authors&acrid=2. It may be down for maintenance or configured incorrectly.

2. When I go to user credentials. I get this: The website encountered an error while retrieving http://localhost:8888/4/Special:UserCredentials. It may be down for maintenance or configured incorrectly.

I am thinking the update.php didn't work but I don't know why it wouldn't. 24.130.249.87

Thank you.

You installed the matching version (release for MediaWiki 1.19 and MediaWiki 1.19)? Please always tell us what version do you use. Tim (SVG) 08:08, 1 July 2012 (UTC)

I am using MediaWiki 1.19.1 but upgraded from 1.16. . I am thinking maybe I have the legacy version of ConfirmAccount but I can't verify from SpecialVersion. I went to download the 1.19 version to test and the only available download was here since git isn't working yet : http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_19/extensions/ConfirmAccount/ . I am very confused as to the file structure of these files and how I am suppose to order them in terms of directories and subdirectories. Should I have a folder for "backend" and "frontend" etc? They are definitely different than the version I am using. Thank you 24.130.249.87

BTW I have a version of MW 1.17 running this extension and it works fine. When I updated to 1.19.1 it breaks the special pages I mentioned 24.130.249.87

I'm equally confused about the file and folder structure and I'm struggling to get the version proved via http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_19/extensions/ConfirmAccount/ to work properly with MW 1.19.1.

I took the time to download that entire thing again one-by-one and use the exact same file structure as it is listed with and it seems to have worked. 24.130.249.87 04:52, 10 July 2012 (UTC)

Accept Requests doesn't work after update

After updating both, Wikimedia and this extension to the current version, I get a weird error when I try to accept a new account. Can somebody help me to understand and repair this? The rest of the extension seems to work fine with the new versions.

Catchable fatal error: Argument 1 passed to AccountConfirmSubmission::acceptRequest_rollback() must be an instance of Database, instance of DatabaseMysql given, called in /www/htdocs/w00ee632/wiki/extensions/ConfirmAccount/business /AccountConfirmSubmission.php on line 205 and defined in /www/htdocs/w00ee632/wiki/extensions/ConfirmAccount/business /AccountConfirmSubmission.php on line 333

There is a "type hint" that should be DatabaseBase. Aaron (talk) 19:14, 9 July 2012 (UTC)

This was fixed in git (master branch). Aaron (talk) 19:53, 7 August 2012 (UTC)

Snapshot from Extension Distributor is currently unavailable

Trunk doesn't work with MW 1.18.2 and I can't get the appropriate snapshot from Extension Distributor. If I go to http://www.mediawiki.org/wiki/Special:ExtensionDistributor/ConfirmAccount, the error message is No such extension "ConfirmAccount".

#Download currently broken?

It is on git now. Aaron (talk) 19:52, 7 August 2012 (UTC)

Error sending mail:Unknown error in PHP's mail() function.

The extension seems to work fine except when the user gets to the point of sending a request for an account. Then this error appears : Error sending mail:Unknown error in PHP's mail() function.

The server error log error is:

qmail-inject: fatal: unable to parse this line: Return-Path:apache@ 216.70.110.23:7081

Thank you 24.130.249.87 09:00, 12 July 2012 (UTC)

mw-config

Hi, I installed the extension and I have this error when running mw-config/?page=ExistingWiki

Fatal error: Class 'ConfirmAccountUISetup' not found in /home/rocket/public_html/wiki/extensions/ConfirmAccount/ConfirmAccount.php on line 42

I'm getting this same error. Anyone have any advice?

---

I had the same problem and got pass it by temporarily disabling ConfirmAccount by remarking it out in LocalSettings.php. Find the line

require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");

add // in front so it looks like this.

// require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");

Complete the upgrade and reverse it by removing the //.

---

can't confirm account

Hi, when I'm accepting a new user, this error occurrs:

«1146: Table 'rocket_wiki.mw_account_credentials' doesn't exist (localhost)».

I run update script, and it helped to solve the same error when a new user request an account, but when I tried to accept a new user, the error shows again.

Someone can help me?

$wgConfirmAccountRequestFormItems undocumented

The README.txt says to go to this page for documentation, and says that a bunch of variables have been folded into "$wgConfirmAccountRequestFormItems", but there is no documentation on the format of this variable. Is it an associative array? Or some kind of bit mask number thing?

The .config.php file in the extension has inline documentation. Aaron (talk) 19:50, 14 August 2012 (UTC)

Invisible table - CSS error

The file confirmaccount.css contains background colour declarations but the matching text colour declarations are missing. This produces invisible or near-invisible text unless the skin in use happens to be using a dark text colour. There are two obvious ways to correct this - either add something like this to confirmaccount.css:

.mw-confirmaccount-type-0 td, .mw-confirmaccount-body-0 td, .mw-confirmaccount-type-1 td, mw-confirmaccount-body-1 td { color: black; }

or else simply delete the four offending rules. This works just fine on my site, and there seems to be no reason why it wouldn't be equally OK on any other - the foreground and background colours default back to the site-wide standards, so that should not be a problem.

Brilliant extension by the way! It has saved us untold amounts of work!

Tannin (talk) 12:30, 22 August 2012 (UTC)

PS: it turns out that there are also hard-coded background colours with missing foreground colour declarations in ConfirmAccount_body.php. RequestAccount_body.php and UserCredentials_body.php. Simply removing these appears to work just fine. Tannin (talk) 12:59, 22 August 2012 (UTC)

Installation failed completely

Hey,

no way to get it run.

I have no access to the server via SSH or Telnet or similar and cannot run the update.php directly. Web-updater didn't work, no tables were installed.

After extraction of the downloaded gz, confirmaccount.sql is not in the extension's directory but in the backend subdirectory, but does not contain the prefix (search and replace failed: the one and only occurrence of the string to replace was in the replace instruction itself).

In the meantime my spam pages in the Wiki are getting more and more.

Please, somebody out there who can save me and my wiki??

Thanks --Thorsten (talk) 13:55, 11 September 2012 (UTC)

Fixed

I found the way my hoster allows to execute SQL via PHPMyAdmin. Afterwards, the tables were present and the extension worked.

Nevertheless, accounts are created by spammers as before, although I edited the group permissions according to the instructions, in so far I do not see how this extension may help.

--Thorsten (talk) 12:54, 12 September 2012 (UTC)

The extension sets $wgGroupPermissions['*']['createaccount'] = false;. Are you setting that back to true anywhere? Aaron (talk) 05:30, 13 September 2012 (UTC)

Update to 1.19.2 and mwstoreerror occurs

Any idea how to fix this?

Unable to find the wrapper "mwstore" - did you forget to enable it when you configured PHP? in /wiki/extensions/ConfirmAccount/backend/ConfirmAccount.class.php on line 26

TeraS (talk) 18:40, 11 October 2012 (UTC)

Having the exact same problem and will be interested to find out a solution

--Gmatthews (talk) 19:51, 14 October 2012 (UTC) Same here. Any clue on a fix? Mine reads the same, except AccountConfirmSubmission.php and line 308.

Problems Running ConfirmAccount with PostgreSQL

Problem #1:

For a new user request, ConfirmAccount attempts to insert NULL into acr_id column, which is marked NOT NULL. This can be fixed by commenting out the following line in UserAccountRequest.php (line 313):

$dbw->insert( 'account_requests', array(

   #          			'acr_id'			=> $acr_id,

'acr_name' => strval( $this->name ), 'acr_email' => strval( $this->email ),

However, it's unclear on why the following code, above that section, does not work:

               # Allow for some fields to be handled automatically...
               $acr_id = is_null( $this->id )
                       ? $this->id
                       : $dbw->nextSequenceValue( 'account_requests_acr_id_seq' );

Problem #2: Cannot Approve Accounts

1. Go to Pending Requests.
2. Click "Review" on any resquest
3. Get:

"There is no pending request corresponding to the given ID. It may have already been handled."

I haven't been able to confirm any requests for this reason. ConfirmAccount.php won't let me review/look at any individual request.

What do the "review" link URLs look like? Do they have IDs that are actually in the table? Aaron (talk) 08:11, 18 November 2012 (UTC)

Actually that code is broken (I fixed it in https://gerrit.wikimedia.org/r/#/c/33976/). Aaron (talk) 08:11, 18 November 2012 (UTC)

Thanks for the patch. It doesn't do anything to fix the "Unable to review" issue, though. Here's what the Review link looks like: http://www.ceramicist.org/index.php?title=Special:ConfirmAccounts/authors&acrid=1

And acr_id 1 definitely does exist.

Try changing acr_deleted to "INTEGER NOT NULL DEFAULT 0". Aaron (talk) 19:26, 18 November 2012 (UTC)

Aaron:

That worked! Thanks. I presume you'll fix the SQL file in the source code?

BTW, if anyone else needs to fix this like I did, the series of commands for an already installed database are:

alter table account_requests alter column acr_deleted drop default;

alter table account_requests alter column acr_deleted type integer using ( 0 );

alter table account_requests alter column acr_deleted set default 0;

Thanks so much for the very rapid turnaround on this bug. Above and beyond!

If it helps anyone, I had to add the "mediawiki" schema to the path to make these commands work:  'SET search_path TO "$user",public,mediawiki;' (Its probably best to do a 'SHOW search_path;' first to make sure you include any schemas that are already in the path when you set the search_path)

The source was changed. Aaron (talk) 08:39, 8 December 2012 (UTC)

Error

Hi, I have installed the extension, if it works :) I can delete, and reject the users.

But i want a user to confirm / accept I come to the site: (link to the press)

http://.../Spezial:Benutzerkonto_bestätigen/authors

See in the picture:
(Image) http://labs.wikibyte.org/w/images/c/cc/Error-extension-ConfirmAccount.png

Confirmed the user is not in the DB table "account_credentials" enrolled!

the error log:

HP Notice:  
Undefined property: stdClass::$acr_xff 
in:  /.../w/extensions/ConfirmAccount/backend/UserAccountRequest.php on line 55, 
referer: http://testwiki.domain.tld/w/index.php?title=Spezial:Benutzerkonto_best%C3%A4tigen/authors&acrid=1

PHP Notice:  
Undefined property: stdClass::$acr_agent 
in:  /.../w/extensions/ConfirmAccount/backend/UserAccountRequest.php on line 56, 
referer: http://testwiki.domain.tld/w/index.php?title=Spezial:Benutzerkonto_best%C3%A4tigen/authors&acrid=1

PHP Catchable fatal error:  
Argument 1 passed to:
AccountConfirmSubmission::acceptRequest_rollback()

must be an instance of Database, 
instance of DatabaseMysql given, called in:

/.../w/extensions/ConfirmAccount/business/AccountConfirmSubmission.php on line 205 

and defined in: 

/.../w/extensions/ConfirmAccount/business/AccountConfirmSubmission.php on line 333, 

referer: http://testwiki.domain.tld/w/index.php?title=Spezial:Benutzerkonto_best%C3%A4tigen/authors&acrid=1

I use InnoDB and the new user is created. However, it remains the user in the "Confirm account requests" as open requests. My Wiki software is 19.2 maybe you have an info? I have a lot of spam and it seems to me that the good solution extension. Sorry for my bad english, i'am german user.

--Extemist (talk) 22:35, 21 November 2012 (UTC)

The "DatabaseMysql" errors seems fixed in the latest version of the code. There was a bug where the type hint was for "Database" when it should have been "DatabaseBase". Aaron (talk) 08:43, 8 December 2012 (UTC)

Disable account request limit from the same IP

Hi! Since my MediaWiki instalaltion is behind a proxy configuration, every request is interpreted as coming from Localhost (127.0.0.1). As a result, sending request for accounts doesn't work at all because every user get's this error:

Sorry, you have already requested 1 account. You cannot make any more requests. 

Is there any configuration option to diable this IP check or maybe some way to increment that limit per IP? Thanks!. --FrancoIacomella (talk) 11:02, 29 November 2012 (UTC)

See $wgAccountRequestThrottle. Aaron (talk) 08:44, 8 December 2012 (UTC)

Account confirmation status does not appear in Special:ConfirmAccounts (and related pages)

Just upgraded to MW 1.20.1 and ConfirmAccount-master-6712353.

In the ConfirmAccounts section, it looks like the status of account requests now misses whether or not the user has confirmed their email address - so admins can't tell if they've been verified or not. Apologies if I've missed something, but if not I think this is an important omission.

On a related note, in older versions, when logging into mediawiki as Admin, the login page used to display a line at the top saying that there were accounts waiting to be approved - this seems to have disappeared. This is really just a cosmetic comment.

Could I also suggest that the ConfirmAccount Wiki page is updated to reflect that the wgAccountRequestMinWords and some other variables are no longer in use having been wrapped into wgConfirmAccountRequestFormItems?

Thanks for the effort in this, we've been happily running ConfirmAccount for some time now.

-sysad77

Where is the email confirmation status missing? On the list view or the page for a single account request? Aaron (talk) 08:48, 8 December 2012 (UTC)

Hi - Under SpecialPages, Confirm account requests (i.e. Special:ConfirmAccounts), the only indication of an unconfirmed account is the "prospective authors(open requests...) link:-

prospective authors (open requests [1] | held requests [0] | recently rejected requests [0] | expired requests)

Selecting this page for the Confirm account requests page (showing the prospective authors queue for review) does not displays:-

Queue: prospective authors [open requests | held requests | rejected requests | expired requests] (show all queues)

I'm fairly sure that there should be the email status displayed in this second page, or if not that, then the first.

Account confirmation error: Could not create directory "mwstore://accountcreds-backend/accountcreds-public/w/we/wes".

Upgraded from MW1.16 to MW1.20.2, and to ConfirmAccount-master-5ef9b44.

I've run the maintenance/update.php file, with the updated LocalSettings.php with require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");

When I try to approve an account, I get the following error: Could not create directory "mwstore://accountcreds-backend/accountcreds-public/w/we/wes"

Any ideas?

02:19, 6 December 2012 (UTC)

Look in the php error log (often apache.log). Aaron (talk) 08:48, 8 December 2012 (UTC)

Same problem here, exactly upgrading from 1.16 to 1.20.2 causes this problem. Upgrading from 1.18 does not. --G.Hagedorn (talk) 08:18, 11 January 2013 (UTC)

Very similar error here. I get: Could not create directory "mwstore://accountcreds-backend/accountcreds-public/w/wi/wik". I just upgraded MW from 1.19 to 1.20.2 and PHP 5.2 to 5.3. Any thoughts?

--Richardbourke (talk) 14:15, 6 May 2013 (UTC) I hit this one too, same error in the front-end. Mw 1.20.3, php53. From the apache error.log:

[error] [client x.x.x.x] PHP Warning:  wfMkdirParents: failed to mkdir "$IP/images/lockdir" mode 0777 in 
$IP/includes/GlobalFunctions.php on line 2546, referer: 
http://hostname/index.php5?title=Special:ConfirmAccounts/authors&acrid=3

[error] [client x.x.x.x] PHP Warning:  fopen($IP/images/lockdir/mr8nbqustvfawd5s79sstwq28n9vjok.lock): 
failed to open stream: No such file or directory in $IP/includes/filebackend/lockmanager/FSLockManager.php 
on line 123, referer: http://hostname/index.php5?title=Special:ConfirmAccounts/authors&acrid=3

What I think happened was: I had done an upgrade from 1.16 and had mixed userids and privilieges in the mediawiki directory tree, not all of which belonged to the user running the apache, so not every php component had write access.

solution (for me): chown -R on the m/w directory tree to the user running apache, and everything worked

--DaveMFoote (talk) 20:26, 16 September 2013 (UTC) This happened for me with a new install of version 1.21.2 on Ubuntu. Instead of giving the Apache user (www-data) rights to the whole Mediawiki tree, I gave it only to images/accountcreds/ and it got rid of the error.

Account confirmation error : Impossible de créer le dossier « mwstore://accountcreds-backend/accountcreds-public/e/eu/euq »

Upgraded from latest 1.19 version to 1.20.2 and experience above message. Any idea on how to fix problem? RiskManager (talk) 15:22, 21 February 2013 (UTC)

see above note. It's a privilege problem at filesystem level, The ConfirmAccount backend needs to create a temporary lockfile, and doesn't have write access to do it. --Richardbourke (talk) 14:26, 6 May 2013 (UTC)

Account confirmation error

MW: 1.20.2, when I try to approve an account:

Warning: file_exists() [function.file-exists]: Unable to find the wrapper "mwstore" - did you forget to enable it when you configured PHP? in /html/w/extensions/ConfirmAccount/business/AccountConfirmSubmission.php on line 304

| Jaider ^Msg 16:53, 19 December 2012 (UTC)

See https://gerrit.wikimedia.org/r/#/c/41815/. This was broken by some core refactoring many months back. Aaron (talk) 00:21, 1 January 2013 (UTC)

Has this been fixed? My site is showing the error

Warning: file_exists() [function.file-exists]: Unable to find the wrapper "mwstore" - did you forget to enable it when you configured PHP? in/home/petwiki/public_html/extensions/ConfirmAccount/business/AccountConfirmSubmission.php on line 304 The file business/AccountConfirmSubmission.php on line 304 reads.

# Delete any attached file and don't stop the whole process if this fails if ( $wgAllowAccountRequestFiles ) { $key = $accReq->getFileStorageKey(); if ( $key ) { $repoOld = new FSRepo( $wgConfirmAccountFSRepos['accountreqs'] ); $pathRel = UserAccountRequest::relPathFromKey( $key ); $oldPath = $repoOld->getZonePath( 'public' ) . '/' . $pathRel; if ( file_exists( $oldPath ) ) { unlink( $oldPath ); // delete! } } } The patch doesn't make sense for this code. How do I fix this? --LTech (talk) 09:33, 11 December 2013 (UTC)

How to send automatically email with login password after confirmation of the email address

After the email confirmation, How can automatically send the login password to the specified email address without administrator validation?

A part of the LocalSettings.php

• require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");
• require_once( "$IP/extensions/ConfirmEdit/ConfirmEdit.php" );
• $wgCaptchaClass = 'SimpleCaptcha';
• $wgGroupPermissions['*']['edit'] = false;
• $wgAutoWelcomeNewUsers = true;
• $wgAccountRequestMinWords = 0;
• $wgLoginLanguageSelector=true;
• $wgUseCombinedLoginLink=true;
• $wgGroupPermissions['emailconfirmed']['edit'] = true;
• $wgGroupPermissions['emailconfirmed']['skipcaptcha'] = true;
• $ceAllowConfirmedEmail = true;
• $wgCaptchaTriggers['addurl'] = false;
• $wgGroupPermissions['user']['createaccount'] = false;

How can I have the language selection available with $wgLoginLanguageSelector=true with the ConfirmAccount extension? Is it possible?

Thanks. ---Pascal Beaujeant

If you just autoconfirm everyone, what's the point in having this extension installed? You might as well just use email confirm settings. 96.46.197.227 13:11, 29 September 2013 (UTC)

SQL import error

When I try importing the SQL to set this up, I get:

ERROR 1170 (42000) at line 64: BLOB/TEXT column 'acr_email' used in key specification without a key length

72.78.144.124 23:48, 22 January 2013 (UTC)

And, ah, any thoughts on how to get around and/or fix that? 72.78.144.124 12:58, 12 February 2013 (UTC)

Am I to assume, then, that this extension is broken, unusable, and unsupported? 192.251.134.5 21:52, 28 February 2013 (UTC)

I wouldn't assume that. It's got up-to-date code, and the maintainer responds on here. I've no idea why you're getting the error. I had all sorts of sql errors (probably caused by wrong string delimiters for the command-line client) when trying to run the ConfirmAccount.sql from the mysql command-line. As soon as I ran it with maintenance/update.php they went away. There's quite a lot of code in the extension to hook into the update script, and it makes it a lot less error prone.--Richardbourke (talk) 14:40, 6 May 2013 (UTC)

Fatal Error Call to undefined method

I installed the ConfirmAccount with little to no problems in June of last year. I'm currently using MediaWiki version 1.19.2 I'm unsure when this first started happening, as it was only recently brought to my attention, but if someone tries to create an account, they get this error which is on Line 204 (when I look at Line 204, it seems to be the start of the failure message output):

Fatal error: Call to undefined method Xml::hidden()

I'm not sure why it was working before and now all of a sudden it isn't... I'm the only one with access to the SQL database and the actual wiki files on my server and I know I've not changed them.

Any suggestions?? KLivianHF (talk) 13:23, 24 January 2013 (UTC)KLivianhf

looks like a mediawiki/extension mismatch to me. Search for "Call to undefined method Xml::hidden()" and you'll see lots of similar errors, as Xml::hidden() went away in 1.18.x. Download a newer version of this extension for 1.19 and try again.--Richardbourke (talk) 14:33, 6 May 2013 (UTC)

Which version for MW 1.6.5

I followed the instructions but only saw versions 1.19, 1.20 and latest dev.--Spiros71 (talk) 15:11, 13 February 2013 (UTC)

you carnt use this for 1.6.5 you have to upgrade to 1.19 or 1.21 or higher. 86.173.52.65 14:20, 20 April 2014 (UTC)

Database error 1and1 (or how to run update.php on 1and1)

I'm getting the following error when new users try to request an account. I check myPHPadmin and don't see the account_requests table. :(

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 "UserAccountRequest::acquireUsername". Database returned error "1146: Table 'db423534347.account_requests' doesn't exist (db423534347.db.1and1.com)".

Thanks! Todrobbins (talk) 23:32, 14 March 2013 (UTC)

Did you remember to run update.php? (see instructions).--Jasper Deng (talk) 23:46, 14 March 2013 (UTC)

My wiki is currently hosted on 1and1 so I'm not sure how to run update.php without access to the command line. Ideas? --Todrobbins (talk) 05:45, 15 March 2013 (UTC)

Here is how to get this running with Mediawiki 1.21 using 1and1 as a host. Note that I did not use the 1and1 app installer because I don't think you can access config files. Here are the details; First you have to be able to FTP into your account. I use Filezilla. You can find your FTP username and create a password in the 1and1 control panel (Access tab then FTP Account). Once you can get in you need to created a directory for the wiki, copy the mediawiki files into the directory (this takes forever) and run setup (I'll leave out details here for that). Then you need to create an .htaccess file with the text "AddHandler x-mapp-php6 .php" (remove quotes). If you are in Windows, notepad forces the .txt extension. Just leave it, FTP to file to the wiki directory and then use Filezilla to rename it .htaccess. Next you need to download the ConfirmAccount extension and place it into your extension directory. Note that you must rename the folder to ConfirmAccount. Delete the rest of the text in the folder name of the download. Next download a copy of your LocalSettings.php file from the server. You need to edit the file and place the appropriate text from the instructions at the bottom of the file (for MediaWiki 1.21 that is require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");) I used Notepad++ for this because I read that Windows Notepad can introduce errors. Save the file and reupload it with Filezilla. Finally you can now SSH into your 1and1 account. I use PuTTY. Now run the update.php command but 1and1 uses php 4.X as the default in SSH so the correct command is "php6 maintenance/update.php" (remove quotes). The two things that took me the longest to figure out 1) Rename the ConfirmAccount directory 2) In SSH use the command PHP6 (instead of PHP) to force PHP 5.4. Hope this helps somebody else.Rsoandrew (talk) 11:31, 28 July 2013 (UTC)

May not be the exact correct place but I wanted to update one issue. The email system can use standard PHP mail or PEAR:mail. For 1and1 the standard PHP mail works fine with this extension. Do not populate $wgSMTP and the mail confirm feature works out of the box.Rsoandrew (talk) 07:45, 4 August 2013 (UTC)

Error sending mail

Error sending mail:
Failed to connect to mailserver at "localhost" port 25, verify your "SMTP" and "smtp_port" setting in php.ini or use ini_set()

I recently installed this extension.
What i did was set up the tables in wiki DB using the ConfirmAccount.sql file.
I placed the ConfirmAccount folder in extensions and added following line in LocalSettings.php

require_once("$IP/extensions/ConfirmAccount/ConfirmAccount.php");

When I tried to send an account request I recieved above error message.
$wgEnableEmail is set to true in LocalSettings.php.

I don´t know how to proceed with TS, any ideas?

---

Is there a way to use this Extension without the send email function if you don´t have the possibillity to have SMTP Server installed? I was thinking about something like, new user requests an account and administrator will notice this in Confirm account requests. He then approves it and it should be working directly. In case he needs to send an email an external email service is used, in other words no email function used in the Wiki. MWMP (talk) 07:13, 18 March 2013 (UTC)

I think you can disable email by just setting $wgEnableEmail to false in LocalSettings. If you want to send email, the server needs to have a mailserver installed. I used postfix (Ubuntu server), or I think the php Mail extension should work too. --Quantum7 (talk) 21:25, 1 May 2013 (UTC)

Nevermind, ConfirmAccount requires email access. Otherwise users can't get their passwords. MWMP's suggestion of preparing an email for the administrator to send manually sounds like a very ugly work-around. At that point, the administrator might as well just create all accounts themself.

^Not true. What if you're part of a small organization that doesn't allow access to their externally hosted email server (thus, you have to have $wgEnableEmail = false;), but you have a fairly high turnover of new employees. As the Wiki admin, I would like to be able to check the Special:ConfirmAccounts. This extension should prompt a new user for a password and put them in an approval queue and if they're approved, their Username and Password are already present.

CV visible for everyone?!?

When using the extension the user can upload a CV file in the section 'Other information' below the information: 'The following information is kept private and will only be used for this request.'

Unfortunately the information are not private because everyone can see the files. Example: http://colab.mpdl.mpg.de/mediawiki/images/accountcreds/d/df/dfa/dfaabfad3d925f19bae0c8501da815e448c31a6e.pdf

What server are you using? You need to make sure the files are pointing to a private directory, either one outside of the document root or one inside of it with a "deny all" .htaccess file. Since the files use long hashes as names, as long as directory listing are not allowed, it would also be hard to find the files (though it's hacky to rely on that). Aaron (talk) 21:07, 25 March 2013 (UTC)

Request Account Config Problems

I'm having a problem with changing the config on the Request Account page. I've set UserName, AreasOfInterest, CV, Notes, Links and TermsOfService to false in my localsettings.php, but for some reason only the UserName, AreasOfInterest and Notes are registering that they're false. The 50 word limit that I've change to 20 is still asking for 50 words. Everything else works fine from what I can tell.

http://www.nzparkour.co.nz/wiki/index.php?title=Special:RequestAccount

I changed the text in the biography field by editing the special messages. Would this have anything to do with my problem?

I'm using MW 1.19 and corresponding ConfirmAccount.

--122.58.77.199 21:27, 26 March 2013 (UTC)

I still haven't been able to resolve this. Any ideas?--122.58.77.199 22:41, 7 May 2013 (UTC)

Preapprove email addresses

My wiki's set up to only allow registered users to edit, and to require approval for new account creations. This works well for keeping spam down but introduces an unnecessary delay in cases where I invite a particular user to contribute. Is there any way to pre-approve certain email addresses for account creation, so that they can immediately begin editing after confirming their email? I'm looking for something like a whitelist for certain email addresses. Even better would be if the whitelist allowed globs or regular expressions, so that whole domains could be whitelisted at once.

Is this functionality available in ConfirmAccount or some other plugin? --Quantum7 (talk) 21:48, 1 May 2013 (UTC)

There is no such feature, though a setting with a list of regexes should not be that hard to code. The confirmation code will have to be changed to also check the address and auto-approve the user (with the user as the approver). A patch to Gerrit would be welcomed. Aaron (talk) 01:52, 9 May 2013 (UTC)

Ok, good to know. Hopefully I'll have time to implement this myself. --Quantum7 (talk) 23:35, 14 May 2013 (UTC)

Error when trying accept new user

Hi, I'm getting this error when I try to accept new user:

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 "AccountConfirmSubmission::acceptRequest". Database returned error "1146: Table 'escforum_mw363.y5m_account_credentials' doesn't exist (localhost)".

Can't find any solution for that. Santos1988 (talk) 00:16, 13 May 2013 (CET)

Did you remember to run update.php?--Jasper Deng (talk) 23:23, 12 May 2013 (UTC)

Yes but I'm getting this:

1. 4 /home/escforum/public_html/includes/installer/DatabaseUpdater.php(435): DatabaseUpdater->applyPatch('/home/escforum/...', true)
2. 5 [internal function]: DatabaseUpdater->addTable('account_credent...', '/home/escforum/...', true)
3. 6 /home/escforum/public_html/includes/installer/DatabaseUpdater.php(281): call_user_func_array(Array, Array)
4. 7 /home/escforum/public_html/includes/installer/DatabaseUpdater.php(248): DatabaseUpdater->runUpdates(Array, true)
5. 8 /home/escforum/public_html/includes/installer/DatabaseInstaller.php(259): DatabaseUpdater->doUpdates()
6. 9 /home/escforum/public_html/includes/installer/WebInstallerPage.php(526): DatabaseInstaller->doUpgrade()
7. 10 /home/escforum/public_html/includes/installer/WebInstaller.php(254): WebInstaller_Upgrade->execute()
8. 11 /home/escforum/public_html/mw-config/index.php(50): WebInstaller->execute(Array)
9. 12 /home/escforum/public_html/mw-config/index.php(18): wfInstallerMain()
10. 13 {main}

(talk) 03:09, 13 May 2013 (CET)

Can I please see the first three lines?--Jasper Deng (talk) 21:30, 13 May 2013 (UTC)

Thats the whole message, nothing more Santos1988 (talk) 18:56, 14 May 2013 (UTC)

I need to know what kind of error that is. There's multiple things that could've gone wrong.--Jasper Deng (talk) 19:12, 14 May 2013 (UTC)

here is full error

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: 
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 ('597','Kam','Olm@lp',NULL,'Oby to bylo by milo','','','83.4.56.17','','Opera/9.80 (Windows NT 6.1; WOW64) Presto/2.12.388 Version/12.15',NULL,NULL,'','20130513162153','20130514193936','2','',NULL)
from within function "AccountConfirmSubmission::acceptRequest". Database returned error "1146: Table 'escforum_mw363.y5m_account_credentials' doesn't exist (localhost)".

Email to Admins to approve contains a malformed link to approve

See some oddities since updating from 1.19 to 1.21. Email going to the admins contains escaped " instead of " character. Generally wouldn't be a problem:

"New User" has requested an account and is waiting for confirmation. 
The email address has been confirmed. You can confirm the request here
"http://ourdomain/wiki/Special:ConfirmAccounts".

The issue is the " on the end of the link

...wiki/Special:ConfirmAccounts".

As it is being included in the actual link to confirm account. It links as

...wiki/Special:ConfirmAccounts%22

which of course is an invalid link because it doesn't exist. Thanks Hutchy68 (talk) 23:16, 24 July 2013 (UTC)

I was about to mention this myself. My email was "&quot;http://domain.com/wiki/Special:ConfirmAccounts%22". Of course, same issue. 96.46.197.227 12:54, 29 September 2013 (UTC)

Any luck fixing this? --Joejoebob (talk) 22:46, 25 October 2013 (UTC)

I fixed this by editing line 73 of /ConfirmAccount/frontend/language/RequestAccountPage.i18n.php to read as follows:

The email address has been confirmed. You can confirm the request here: $2 .',

This should fix the issue, as there's no reason the link needs to be in quotations. Belthesar (talk) 19:19, 5 November 2013 (UTC)

I fixed this by editing line 372 of /ConfirmAccount/frontend/specialpages/actions/RequestAccount_body.php to read as follows:

 $title->getFullUrl() )->inContentLanguage();

Escaping the content turns the quotes into escaped hypertext. Ewetmill (talk) 19:21, 17 June 2014 (UTC)

Send carbon copy of responses to AccountContact

Maybe this is possible and I only haven't found a way to do this.

In the sources this variable is described:

# Send an email to this address when account requestors confirm their email.
# Set to false to skip this. It might be useful to point this to a mailing list.
$wgConfirmAccountContact = false;

Which makes perfect sense if more than one person can approve new users. What would be nice would be if the mail that is sent to the user that his request was Approved/Rejected/Held would be sent as a CC to that address too. That would help admins to maintain a consistent policy ("Why did Joey reject this guy?") and give them a "paper trail"

HELP!!

I found two errors. What do they mean?

The MediaWiki Shell Update Command gave me this error:

/opt/php53/bin/php maintenance/update.php

gives me this:

Going to run database updates for dlint01_mdwk2-mwiki_ Depending on the size of your database this may take a while! Abort with control-c in the next five seconds (skip this countdown with --quick) ... 5�4�3�2�1�0 Fatal error: Call to undefined method MysqlUpdater::dropExtensionIndex() in /home/dlint01/public_html/wiki/extensions/ConfirmAccount/backend/schema/ConfirmAccountUpdater.hooks.php on line 22

AND

when I tried to create a Test Account to test the Extentsion:ConfirmAccount, this error showed up:

from within function "UserAccountRequest::acquireUsername". Database returned error "1146: Table 'dlint01_mdwk2.mwiki_account_requests' doesn't exist (localhost)".

In Correct (talk) 10:43, 5 August 2013 (UTC)

had the same error with the confirmaccount ext.

additional info: MW 1.20 could not detect correctly my php 5.3 version, --Erkan Yilmaz (talk) 01:41, 4 September 2013 (UTC)

error when going to update.php

hi I am getting an error when using web base update.php the error says Fatal error: Class 'ConfirmAccountUISetup' not found in /home/wikisau/public_html/extensions/ConfirmAccount/ConfirmAccount.php on line 42 86.159.26.136 18:57, 8 August 2013 (UTC)

I got the same error when running the web updater and resorted to editing the ConfirmAccount.php file in xx/extensions/ConfirmAccount/ folder: It appeared the program had failed to initialize the 'confirmAccountUISetup' class prior to calling one of its functions. The initialization takes place in xx/frontend/ConfirmAccountUI.setup.php so I inserted the following line just before line 42, copying the format of the 'require' call on line 38:

require( dirname( __FILE__) . '/frontend/ConfirmAccountUI.setup.php');

lo and behold the extension loaded! The extension download I installed from was "wikimedia-mediawiki-extensions-ConfirmAccount-d8632fb.tar.gz" --Mwidmayer (talk) 21:39, 17 October 2013 (UTC)

it is now fixed by upgrading to mediawiki 1.23 or higher and installing extension:localisationupdate. the extension was updated and fixed the error. 86.173.52.65 14:18, 20 April 2014 (UTC)

update extension

hi please update the look of the extension because since mediawiki 1.20 was realse the layout of login and create account looks like this create account login account and in 1.19 it looks like log in/create account so please update extension 86.159.26.136 19:18, 8 August 2013 (UTC)

Tweaking the welcome message

How to include the user's name in the message, with something like "Hello {{NAMESPACE}}, thank you for joining the site." Also how to put the signature at the end of the message so it starts on a new line? --Rob Kam (talk) 21:40, 11 August 2013 (UTC)

How to simplify

Is it possible by only editing LocalSettings.php, to simplify the request a login page, as done at e.g. SDIY wiki. That is to only ask for a username, an email and some message? --Rob Kam (talk) 19:30, 14 August 2013 (UTC)

Yes. Read the page. 96.46.197.227 12:50, 29 September 2013 (UTC)

Fatal Errors after Update, missing Class info

After updating MediaWiki to 1.21.1, I tried updating this Extension as well. However, after doing so, when I click on 'request one' (to request an account from the Login/create account), I get the following error:

Fatal error: Class 'RequestAccountPage' not found in /home/kersare/public_html/horizonfleet/wiki2/mediawiki/includes/SpecialPageFactory.php on line 335

I get the same error if I try to go to Special Pages.

I've also been trying to find where I can edit the message shown when someone tries to request an account. I modified it on earlier versions of ConfirmAccount, but am having trouble finding it again.

Please let me know how to resolve this; thank you. -KailaniLivian 11:42 27 August 2013 (EDT)

UPDATE: I found that the 3 php files under ConfirmAccount/frontend/specialpages/actions were blank. Once I copied over the info from my previous installation, I no longer got the fatal error.

However, I'm still not finding the place where I can edit the text shown when someone tries to request an account. I have additional information I'd like to provide (and would like to allow someone to enter their Real Name as well as User Name), but have not been able to locate it.

Datbase error while upgrading to MediaWiki 1.21

Running the ../maintenance/update.php I got this error message: Database returned error "1170: BLOB/TEXT column 'acr_email' used in key specification without a key length (localhost). Downgrading to a previous version of Confirm User Accounts solved the problem. Silkwood (talk) 14:51, 30 August 2013 (UTC)

Manually Remove Rejected Accounts

Is there a method to manually trigger the removal of rejected accounts, I have it setup to purge after a week but this is not happening. I see there is a known issue relating to this and we fall into the category of not having many users viewing the confirm users page.

Fix search bug

Hi please could someone please fix a search bug in this extension because it now doesent let you use the search bar to search for something it doesent show drop down list you have to know what you want it doesent show suggestion please fix it. I am using Mediawiki 1.22 Wmf 20 90.199.55.106 15:27, 4 October 2013 (UTC)

Create account / login

Hi please update login and create account buttons because the layout and look of them was changed in 1.20 when the separated them into create account and then login so please update the looks and the create account could be redirect to special request account. I am running Mediawiki 1.22 Wmf 20 90.199.55.106 15:30, 4 October 2013 (UTC)

Database Error after Upgrading to 1.21.1

Hi,

since I updated my MediaWiki to 1.21.1 it's not possible to create a account in my wiki anymore with activated ConfirmAccount-extension. After filling the form following Database Error is shown:

" Es ist ein Datenbankfehler aufgetreten. Der Grund kann ein Programmierfehler sein. Die letzte Datenbankabfrage lautete: (Die SQL-Datenbankabfrage ist verborgen.) aus der Funktion „UserAccountRequest::insertOn“. Die Datenbank meldete den Fehler „1054: Unknown column 'acr_xff' in 'field list' (localhost)“. "

Translated by google translate:

" There was a database error. The reason may be a programming error. The last attempted database query was: (The SQL database query is hidden.) from within function "UserAccountRequest::insertOn". The Database returned error "1054: Unknown column 'acr_xff' in 'field list' (localhost)".

"

I run my MediaWiki on PHP 5.3.26 (cgi-fcgi)and MySQL 5.1.58-1~dotdeb.0. The ConfirmAccount Version is the latest available. Any ideas how to solve the problem?

thx

Special html characters mess things up

The e-mail that i receive when somebody requests an account looks like this:

"Nikosi" has requested an account and is waiting for confirmation.
The email address has been confirmed. You can confirm the request here "http://www.example.org/Special:ConfirmAccounts".

Sorry, i had to use source, because pre was still allowing for characters to be changed.

The &quot; characters break the Special:ConfirmAccount URL. 85.26.184.158 06:15, 27 October 2013 (UTC)

Yeah, this is a bit annoying. I have opended bug 64286 for this. --[[kgh]] (talk) 14:12, 23 April 2014 (UTC)

Create Account without email-Adress

Hello, is it possible that a user can request an account without an email adress and specify a password by himself?

Could not open lock file for...

• Most probably a problem of user restrictions.
• Enable debugging and look at error message
• Most probably, the image folder needs to allow a lockdir folder

add support for centralauth

this extension does not work with centralauth please fix the problem. 86.173.52.65 15:18, 20 April 2014 (UTC)