Wiki source for RegisterAction


Show raw source

=====Register Action=====
{{lastedit}}

>>**See also:**
~-UserAccountModules
~-Documentation: ""RegisterActionInfo""
~-Test: RegisterActionTest
~-Related: Nils' UserRegistration.
>>This is the development page for the Register action.::c::

I've started working on a new version of an action for user registration. The motivation behind this is to replace the current ##usersetting## action with three distinct actions:

~-##register## action - handling operations related to user registration and first login;
~-##login## action - handling operations related to login/logout and password retrieval of registered users;
~-##usersettings## action - handling user preferences (See UserSettingsPanel for more info).

''[2005-02-25] action uploaded on this site as a beta feature: RegisterActionTest (you'll need to logout to test it)''

=== The action ===
Current version: 0.3

Done:
~-Added labels and semantic markup for registration table as per JavaWoman's and IanAndolina's suggestion;
~-Removed useless hidden fields (inherited from ##usersettings##);
~-Expanded ##elseif## validations to allow further actions;
~-Added redirect to WelcomeUser for first login (in the future redirect page will be configurable - see RedirectOnLogin);
~-Added done/failed icons (using menulets currently installed as beta features on this server);
~-Variable initialization and constants section;

To do:
~-CSS to style form;
~- (optionally) drop WikiName restriction on usernames;
~- use core functions to validate fields;
~- use central error handler for printing error messages;
~- decide best strategy to link hardcoded login/logout page;
~- define welcome page where new users must be redirected;
~- (optionally) add option for email-confirmation of registered users.

=== The code ===

Save the following as ##./actions/register.php## and use it as ##""{{register}}""##.

%%(php;1)
<?php
/**
* Display a form for user registration.
*
* This action allows new users to register an account, if user registration is enabled.
* All the required fields are validated before the new user is created.
*
* @package Actions
* @name Register
*
* @author {@link http://wikka.jsnx.com/DarTar Dario Taraborelli}
* @version 0.3
* @since Wikka 1.1.X.X
* @output form for user registration
*
* @todo
* - CSS to style form;
* - (optionally) drop WikiName restriction on usernames;
* - use core functions to validate fields;
* - use central error handler for printing error messages;
* - decide best strategy to link hardcoded login/logout page;
* - define welcome page where new users must be redirected;
* - (optionally) add option for email-confirmation of registered users.
*/

// constants
define('MIN_PASSW_LENGTH', '5');
define('DEFAULT_REDIRECT_TO', 'WelcomeUser');

print $this->Format('===== Registration page =====');

if ($this->GetConfigValue('allow_new_users') == '0')
{
// user registration is disabled
print $this->Format('//User registration is disabled on this wiki//');
} else
{
if ($user = $this->GetUser())
{

// user is logged in

// initializing variables
$name = '';
$email = '';
$password = '';
$confpassword = '';
$error = '';

// is this the first time the user logs in?
if ((isset($_GET['reg'])) && ($_GET['reg'] == '1'))
{

switch ($this->GetConfigValue('allow_new_users'))
{
default:
case 0:
// print first login welcome screen
print $this->Format('--- **Registration successful!** --- --- You are currently logged in as '.$this->GetUserName());
break;

case 1:
// redirect to welcome page
$this->Redirect($this->href('', DEFAULT_REDIRECT_TO));
break;

case 2:
// redirect to referrer page
$this->Redirect($this->href('', DEFAULT_REDIRECT_TO));
break;
}

} else
{
// user is already logged in: print user information
print $this->Format('--- You are currently logged in as '.$this->GetUserName());
}

} else
{

// user is not logged in

// is user trying to register?
if ($_POST)
{


// get POST values
if (isset($_POST['name'])) $name = trim($_POST['name']);
if (isset($_POST['email'])) $email = trim($_POST['email']);
if (isset($_POST['password'])) $password = $_POST['password'];
if (isset($_POST['confpassword'])) $confpassword = $_POST['confpassword'];

// validate fields
// note: all these validation checks should use core functions to preserve consistency

if ($this->LoadUser($name))
{
$error = 'Sorry, this username already exists. Please choose a different name.';
$validname = $this->Action('failed');
} elseif ($this->ExistsPage($name))
{
$error = 'Sorry, this username is reserved for a page. Please choose a different name.';
$validname = $this->Action('failed');
} elseif (!$this->IsWikiName($name))
{
$error = 'Please fill in a valid username (formatted as a ##""WikiName""##).';
$validname = $this->Action('failed');
} elseif (!$email)
{
$error = 'Please specify an email address.';
$validname = $this->Action('done');
$validemail = $this->Action('failed');
} elseif (!preg_match("/^.+?\@.+?\..+$/", $email))
{
$error = 'That does not quite look like an email address.';
$validname = $this->Action('done');
$validemail = $this->Action('failed');
} elseif (!$password)
{
$error = 'Please choose your password.';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
} elseif (strlen($password) < MIN_PASSW_LENGTH)
{
$error = 'Sorry, password too short (min. '.MIN_PASSW_LENGTH.' chars).';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
} elseif (preg_match("/ /", $password)) {
$error = 'Sorry, spaces are not allowed in passwords.';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
} elseif (!$confpassword)
{
$error = 'You need to confirm your password.';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
$validconfpassword = $this->Action('failed');
} elseif ($confpassword != $password)
{
$error = 'Sorry, passwords do not match.';
$validname = $this->Action('done');
$validemail = $this->Action('done');
$validpassword = $this->Action('failed');
$validconfpassword = $this->Action('failed');
} else
{
// all required fields are valid and non-empty

// create user
$this->Query("insert into ".$this->config["table_prefix"]."users set ".
"signuptime = now(), ".
"name = '".mysql_real_escape_string($name)."', ".
"email = '".mysql_real_escape_string($email)."', ".
"password = md5('".mysql_real_escape_string($password)."')");

// log in
$this->SetUser($this->LoadUser($name));

// forward
$this->Redirect($this->href('','','reg=1'));
}
}



$intro = $this->Format(' --- If you are a **new user** you can register an account using this form (if you already have an account, please go to the [[UserSettings | login page]]). --- --- To register, the following fields are required:
~-your **username** (it must be formatted like a ##""WikiName""##, for example: ##""JuliusCaesar""##);
~-a **valid email address** (this will only be used to retrieve your password in case you lose it);
~-a **valid password** (min. '.MIN_PASSW_LENGTH.' characters, no space allowed).
--- ---');

// build registration form
$form = $this->FormOpen();
$form .= ' <table summary="Form to provide registration data: username, email and password">';
$form .= ' <caption>Registration form</caption>';
$form .= ' <tbody>';

if (isset($error))
{
$form .= '<tr><td colspan="3" align="center"><span class="error">'.$this->Format($error).'</span></td></tr>';
}
$form .= ' <tr>';
$form .= ' <th align="right" scope="row"><label for="name">Your username:</label></th>';
$form .= ' <td><input name="name" id="name" size="40" value="'.$name.'" title="Choose a valid username (formatted as a WikiName)" /></td>';
$form .= ' <td>'.$validname.'</td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <th align="right" scope="row"><label for="email">Your email address:</label></th>';
$form .= ' <td><input name="email" id="email" size="40" value="'.$email.'" title="Fill in a valid email address"/></td>';
$form .= ' <td align="left">'.$validemail.'</td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <th align="right" scope="row"><label for="password">Your password:</label></th>';
$form .= ' <td><input type="password" name="password" id="password" size="40" title="Choose a valid password (min. '.MIN_PASSW_LENGTH.' chars, no space)" /></td>';
$form .= ' <td align="left">'.$validpassword.'</td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <th align="right" scope="row"><label for="confpassword">Confirm password:</label></th>';
$form .= ' <td><input type="password" name="confpassword" id="confpassword" size="40" title="Type again your password for confirmation" /></td>';
$form .= ' <td align="left">'.$validconfpassword.'</td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <td></td>';
$form .= ' <td><input type="submit" value="Register" title="Register" /></td>';
$form .= ' </tr>';
$form .= ' </tbody>';
$form .= ' </table>';
$form .= $this->FormClose();

// output intro and form
print $intro.$form;
}
}
?>
%%

''See RegisterUserIpAddress for a small (security-related) modification. --JavaWoman''


----
=== Discussion ===

~& Try to use SemanticMarkup if this is going to be rewritten anyway, instead of:
~& %%(php)
$form .= '<tr>';
$form .= ' <td align="right">Confirm password:</td>';
$form .= ' <td><input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></td>';
$form .= '</tr>';
%%
~&use:
~&%%(php)
$form .= '<label>Confirm password:<input type="password" name="confpassword" size="40" title="Type again your password for confirmation" /></label>';%%::c::
~&It is more elegant, semantically clean and frees some bytes to run free in forests! --IanAndolina
~
~~&While I agree that ##label## should always be used for form control prompts, I **don't** agree with dropping the table. A form as a series of label-data constructs (i.e., name-value pairs) is semantically also a **data** table, especially since a form can be used not only to //enter// data but also to //(re)view// and //modify// it.
~~&But when a table is a **data** table, it should be marked up as a **data** table, with proper header cells related to the data cells, a caption, and a summary.
~~&The hidden "register" field is also superfluous, since the submit button can take care of that.
~~
~~&We'd end up with something like this (this serves just as an example, not meant as the "final" code):
~~& %%(php;127)
// build registration form
$form = $this->FormOpen();
$form .= ' <table summary="form to provide registration data: username, email and password">';
$form .= ' <caption>Registration form</caption>';
$form .= ' <tbody>';

if (isset($error)) {
$form .= '<tr><td></td><td><span class="error">'.$this->Format($error).'</span></td></tr>';
}
$form .= ' <tr>';
$form .= ' <th align="right" scope="row"><label for="name">Your username:</label></th>';
$form .= ' <td><input name="name" id="name" size="40" value="'.$name.'" title="Choose a valid username (formatted as a WikiName)" /></td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <th align="right" scope="row"><label for="email">Your email address:</label></th>';
$form .= ' <td><input name="email" id="email" size="40" value="'.$email.'" title="Fill in a valid email address"/></td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <th align="right" scope="row"><label for="password">Your password:</label></th>';
$form .= ' <td><input type="password" name="password" id="password" size="40" title="Choose a valid password (min. 5 chars, no space)" /></td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <th align="right" scope="row"><label for="confpassword">Confirm password:</label></th>';
$form .= ' <td><input type="password" name="confpassword" id="confpassword" size="40" title="Type again your password for confirmation" /></td>';
$form .= ' </tr>';
$form .= ' <tr>';
$form .= ' <td></td>';
$form .= ' <td><input type="submit" value="Register" size="40" title="Register" /></td>';
$form .= ' </tr>';
$form .= ' </tbody>';
$form .= ' </table>';
$form .= $this->FormClose();
%%::c::
~~& Note that I've also removed the if clauses for $name and $email - the fields should simply be initialized and can then directly be used in the form (moving towards a templating mindset :)).
~~& Preferably the ##align="right"## on the header cells (and maybe other styling) should be taken care of by some special "form table" rules in the stylesheet (contextual rules will be all that's necessary, no need for extra classes or id - and this will enhance a consistent layout of forms). Both right-aligning labels and a consistent layout for all forms will be helpful for usability.
~~& --JavaWoman
~~~&I think you are (respectfully) wrong. That you may intepret a submit button as "data" is stretching the //very notion of data in my opinion//! ;) In this particular case the table is not providing **any** semantic information that could not be more elegantly be provided by removing the redundant table tags. It is being used as a presentational aid and that is wrong: "Tables should not be used purely as a means to layout document content" (W3 HTML 4 documentation). To provide semantic "sections" within forms, there is <fieldset/> expressedly for that purpose, along with <legend/> for titling. --IanAndolina
~~~~&Using a **data** table to **structure data** (inside or outside of a form) is not using it as a representational aid, but using it exactly for what data table markup is intended for. Marking up form content (a form with more than a single field at least) this way is also helpful for people using screen readers, precisely because it //is// a //data// table (and not a //layout// table): they can choose to browse the content in table mode (representing the data structure, to get an overview of the content) as well as in form mode (to enter or modify the data). I know there are such things as field sets, etc. - but they can't do what the data table is doing here: presenting the **data structure**. Arranging a data structure in rows and columns (and more complicated variants of that) is precisely what data tables are for - and precisely for that reason the markup I've used is **not** a that of a layout table (which uses //nothing but// ##table##, ##tr## and ##td## elements) but that of a data table (with a ##summary##, a ##caption##, and table header cells (##th##) associated with their corresponding data cells (##td##) - none of which are even allowed in a layout table). If you would merely **present** these data, you //would// use a data table. Making those same data editable by means of a form does not suddenly rob it of its data structure: so the data table markup is equally applicably to data that is merely presented and to data that is editable: it is the same data structure after all, with an extra facility (editablility) added to it! --- I know there are "schools" trying to get rid of //all// tables - but that is (respectfully) the wrong approach. Data tables provide a rich markup to present data structures which is not preempted by using a form but can work in conjunction with it. The result provides both visually explicit structure (for those who can see it) as well as a markup structure for those who use assistive technology and like to explore the data structure before (possibly) entering or modifying data. It gives people using assistive technology a choice (corresponding to "scanning" the rows and columns of a form by those who can see) that would simply be missing if data table markup weren't used. While this isn't required by accessibility standards, it definitely isn't wrong either; in fact it's appreciated by most, and it doesn't get in the way for those who want to use only "form mode". --- When you say that a submit button is not data, you are right, of course. :) A refinement of my code (I did say it was not in a final form...) would be to take the submit button outside of the form, leaving the data table to only structure the //data// in the form (and not the form itself). --- If you browse this site, you'll see I always advocate not using tables for layout (that's why the still somewhat experimental new [[WikkaBetaFeatures | category action]] is no longer using a table!) but vice versa I also advocate using **data** table markup - instead of **layout** table markup - when presenting an actual data structure (see JwCalendar, for instance). --- The markup presented here conforms not only to the XHTML (1.0, and even 1.1) standard, but to WCAG as well. You may not like it - but it's not wrong. --JavaWoman---
~~~~~&--- ---I have //no// problem with tables being used for __**##tabular##**__ data (and I've seen your many positive contributions in regards to semantic markup here)! The issue here is that you stretch your definition of a select box for example to be data which is not ##**tabular**## at all. A table by definition (derived from the latin for board, //tabula//) is composed of rows and columns; where does the 3rd dimension of a select box come into such a 2-dimensional structure, or the variable state switching of radio selects? The answer is they don't fit cleanly into a clearly defined understanding of what tabular data marked up in rows and columns is. And if you can say a select box is data, then Mr. Frontpage Designer can retort so is his 10px mauve spacing graphic; it is visual data that fits more cleanly into the rows and columns of tabular data than radio selects ever will…--- --- Let me put it another way, I suggested we use fieldsets, which are standard HTML //designed for forms// and markup your form elements using clearly defined labels wrapping form element (or using the for attribute as you have done). The semantics of such a form is clear, well-defined and I simply don't understand //why// you need to try to impose tabular constraints on such a thing; it is superfluous.--- --- "Everything should be made as simple as possible, but not one bit simpler." — Albert Einstein --- --- I am curious to know what is the table bringing us that a well built-form isn't? For assistive technologies, the semantics of <fieldset><lable><element/></label></fieldset> are clear. For the next generation of CSS powered small-screened devices, tables are treated differently to form markup, and thus rendered differently (thus tables should stick to tabular data at all times). There is no need for the table; all information that is needed about relationships in the form for assistive technologies are inherent to its design already. As the table is adding a lot more underlying mark-up and weight, **it is for the table to prove its worth in this situation not the other way round! ;)** --- --- As a final point, why are you using **align="right"** in the table, //that is presentational!// This brings me to my final point, that both forms and tables should be styled using CSS **always**. Using your table as table OR table as form data organiser you need to include extra classes to give your CSS traction and thus litter your mark-up with the oft seen CSS disease of //classitis//! :) Using forms for forms and tables for tables simplifies the task of styling using CSS, as well as simplifing the underlying markup; it makes things easier!--- --IanAndolina---
~~~~~~&Well, I think we have to agree to disagree on the usefulness of using a data table both for presenting data and for editing the same data... :) BTW, you must have missed my remark that the code was not finished, and that the alignment of the prompts would better be handled with a stylesheet. That said, alignment attributes in a **data table** are //not// presentational (or they would be deprecated - which they are not, while they are almost everywhere else. If you think about it, I'm sure you can understand there's a reason for that. ;-)) Still, if you style the form and its enclosed table for the data structure, **no** extra classes are needed at all; contextual rules can do all you need. --JavaWoman ---
~~~~~~& OK, agreeing to disagree a done deal! ;) I apologise for not picking up on your earlier mentioning of align="right" going into CSS. But you will find that align probably **will** be deprecated in [[http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-tables.html#s_tablesmodule | XHTML 2]], so it is still deemed a presentational throwback that they weren't brave enough to expunge in 1.1! If you have any links to articles defending the use of tables in forms, I'd be interested, leave them on my page here. Thank you for the interesting discussion, even if you are wrong :p (that is the stick-out tongue smiley just in case!), take care, --IanAndolina
~~~& Thanks for your feedback, guys! I'll patch the action with your suggestions asap. I was thinking that maybe we might want to add more options related to user registration in ##wikka.config.php##.
~~~& E.g.:
~~~& %% "allow_new_users" => "0",%% Disables new users registration
~~~& %% "allow_new_users" => "1",%% Enables new users registration
~~~& %% "allow_new_users" => "2",%% Enables new users registration with confirmation procedure
~~~&I'd also like to have Nils' opinion about this, since he had been working on an improved action for user registration with a confirmation code.
~~~& -- DarTar
~~~~& After ActiveDirectory, were we have "user_identification" => "wikka/activedirectory", i thought about a slightly different structure, which would allow to usse another programm for registration:
~~~~& %% "user_registration" => "wikka/(other program)/off" %%::c::
~~~~& and %% "registration_requirements" %%::c:: (anybody with a better name?) %% => "none[this is the normal registration], "no double account" [only one account per e-mail], "registercode" [which requieres another entry]. %%
~~~~& --NilsLindenberg (nice work, btw :)

Much better... a few more comments:
~1)The variables are still not being initialized. If a user does not provide a value when submitting the form, the variable won't be set - and then you're trying to use the unset variable(s) as parameters to functions and values for form fields. Try **not** excluding E_NOTICE in php's error reporting and submit an empty form - and see what you get...
~~& Humm, ok, I'll try to fix this;
~1)What's the mysterious JavaScript for? Do we even need it?
~~& No idea, inherited from ##usersettings##: I left it because I didn't know what it was needed for, I guess we can drop it...
~1)I don't think the submit button can do anything with a size attribute (missed that the first time) ---
~~& Oops, another thing inherited from ##usersettings## - will fix it.
--JavaWoman

----
CategoryDevelopmentActions
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki