Extension talk:ConfirmAccount/LQT Archive 1


 * Archive 1
 * Archive 2

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)

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 have a line of cod to configure the group bureaucrats. In file: $wgGroupPermissions['bureaucrat']['confirmaccount'] = true;
 * 1) Grant account queue rights

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

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

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

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

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

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

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

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

Hope this helps someone else down the road.

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

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

Anyone got experience using it with SQLite?

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

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

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

'acr_deleted' => 0,

I haven't tested everything, but the basic functionality seems to be working now.

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

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

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

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

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

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

Thanks in advance,

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


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


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


 * $wgAccountRequestTypes[0] = 'reader';


 * $wgAccountRequestTypes[1] = 'reviewer';


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

Aaron 20:35, 14 January 2010 (UTC)


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


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

Aaron 21:29, 14 January 2010 (UTC)

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

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

Any ideas?

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


 * I've heard Zend Optimizer has 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)