Register Action

Last edited by JavaWoman:
Replaces old-style internal links with new pipe-split links.
Fri, 20 May 2016 07:38 UTC [diff]

See also:
This is the development page for the Register action.

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:

[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

To do:

The code

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

  1. <?php
  2. /**
  3.  * Display a form for user registration.
  4.  *
  5.  * This action allows new users to register an account, if user registration is enabled.
  6.  * All the required fields are validated before the new user is created.
  7.  *
  8.  * @package     Actions
  9.  * @name        Register
  10.  *
  11.  * @author      {@link Dario Taraborelli}
  12.  * @version     0.3
  13.  * @since       Wikka 1.1.X.X
  14.  * @output      form for user registration
  15.  *
  16.  * @todo
  17.  *          - CSS to style form;
  18.  *          - (optionally) drop WikiName restriction on usernames;
  19.  *          - use core functions to validate fields;
  20.  *          - use central error handler for printing error messages;
  21.  *          - decide best strategy to link hardcoded login/logout page;
  22.  *          - define welcome page where new users must be redirected;
  23.  *          - (optionally) add option for email-confirmation of registered users.
  24.  */
  26. // constants
  27. define('MIN_PASSW_LENGTH', '5');
  28. define('DEFAULT_REDIRECT_TO', 'WelcomeUser');
  30. print $this->Format('===== Registration page =====');
  32. if ($this->GetConfigValue('allow_new_users') == '0')
  33. {
  34.     // user registration is disabled
  35.     print $this->Format('//User registration is disabled on this wiki//');
  36. } else
  37. {
  38.     if ($user = $this->GetUser())
  39.     {
  41.         // user is logged in
  43.         // initializing variables
  44.         $name = '';
  45.         $email = '';
  46.         $password = '';
  47.         $confpassword = '';
  48.         $error = '';
  50.         // is this the first time the user logs in?
  51.         if ((isset($_GET['reg'])) && ($_GET['reg'] == '1'))
  52.         {
  54.             switch ($this->GetConfigValue('allow_new_users'))
  55.             {
  56.                 default:
  57.                 case 0:
  58.                 // print first login welcome screen
  59.                 print $this->Format('--- **Registration successful!** --- --- You are currently logged in as '.$this->GetUserName());
  60.                 break;
  62.                 case 1:
  63.                 // redirect to welcome page
  64.                 $this->Redirect($this->href('', DEFAULT_REDIRECT_TO));
  65.                 break;
  67.                 case 2:
  68.                 // redirect to referrer page
  69.                 $this->Redirect($this->href('', DEFAULT_REDIRECT_TO));
  70.                 break;
  71.             }
  73.         } else
  74.         {
  75.             // user is already logged in: print user information
  76.             print $this->Format('--- You are currently logged in as '.$this->GetUserName());
  77.         }
  79.     } else
  80.     {
  82.         // user is not logged in
  84.         // is user trying to register?
  85.         if ($_POST)
  86.         {
  89.             // get POST values
  90.             if (isset($_POST['name'])) $name = trim($_POST['name']);
  91.             if (isset($_POST['email'])) $email = trim($_POST['email']);
  92.             if (isset($_POST['password'])) $password = $_POST['password'];
  93.             if (isset($_POST['confpassword'])) $confpassword = $_POST['confpassword'];
  95.             // validate fields
  96.             // note: all these validation checks should use core functions to preserve consistency
  98.             if ($this->LoadUser($name))
  99.             {
  100.                 $error = 'Sorry, this username already exists. Please choose a different name.';
  101.                 $validname = $this->Action('failed');
  102.             } elseif ($this->ExistsPage($name))
  103.             {
  104.                 $error = 'Sorry, this username is reserved for a page. Please choose a different name.';
  105.                 $validname = $this->Action('failed');
  106.             } elseif (!$this->IsWikiName($name))
  107.             {
  108.                 $error = 'Please fill in a valid username (formatted as a ##""WikiName""##).';
  109.                 $validname = $this->Action('failed');
  110.             } elseif (!$email)  
  111.             {
  112.                 $error = 'Please specify an email address.';
  113.                 $validname = $this->Action('done');
  114.                 $validemail = $this->Action('failed');
  115.             } elseif (!preg_match("/^.+?\@.+?\..+$/", $email))
  116.             {
  117.                 $error = 'That does not quite look like an email address.';
  118.                 $validname = $this->Action('done');
  119.                 $validemail = $this->Action('failed');
  120.             } elseif (!$password)
  121.             {
  122.                 $error = 'Please choose your password.';
  123.                 $validname = $this->Action('done');
  124.                 $validemail = $this->Action('done');
  125.                 $validpassword = $this->Action('failed');
  126.             } elseif (strlen($password) < MIN_PASSW_LENGTH)
  127.             {
  128.                 $error = 'Sorry, password too short (min. '.MIN_PASSW_LENGTH.' chars).';
  129.                 $validname = $this->Action('done');
  130.                 $validemail = $this->Action('done');
  131.                 $validpassword = $this->Action('failed');
  132.             } elseif (preg_match("/ /", $password)) {
  133.                 $error = 'Sorry, spaces are not allowed in passwords.';
  134.                 $validname = $this->Action('done');
  135.                 $validemail = $this->Action('done');
  136.                 $validpassword = $this->Action('failed');
  137.             } elseif (!$confpassword)
  138.             {
  139.                 $error = 'You need to confirm your password.';
  140.                 $validname = $this->Action('done');
  141.                 $validemail = $this->Action('done');
  142.                 $validpassword = $this->Action('failed');
  143.                 $validconfpassword = $this->Action('failed');
  144.             } elseif ($confpassword != $password)
  145.             {
  146.                 $error = 'Sorry, passwords do not match.';
  147.                 $validname = $this->Action('done');
  148.                 $validemail = $this->Action('done');
  149.                 $validpassword = $this->Action('failed');
  150.                 $validconfpassword = $this->Action('failed');
  151.             } else
  152.             {
  153.                 // all required fields are valid and non-empty
  155.                 // create user
  156.                 $this->Query("insert into ".$this->config["table_prefix"]."users set ".
  157.                     "signuptime = now(), ".
  158.                     "name = '".mysql_real_escape_string($name)."', ".
  159.                     "email = '".mysql_real_escape_string($email)."', ".
  160.                     "password = md5('".mysql_real_escape_string($password)."')");
  162.                 // log in
  163.                 $this->SetUser($this->LoadUser($name));
  165.                 // forward
  166.                 $this->Redirect($this->href('','','reg=1'));
  167.             }
  168.         }
  172.         $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:
  173. ~-your **username** (it must be formatted like a ##""WikiName""##, for example: ##""JuliusCaesar""##);
  174. ~-a **valid email address** (this will only be used to retrieve your password in case you lose it);
  175. ~-a **valid password** (min. '.MIN_PASSW_LENGTH.' characters, no space allowed).
  176. --- ---');
  178.         // build registration form
  179.         $form  = $this->FormOpen();
  180.         $form .= '  <table summary="Form to provide registration data: username, email and password">';
  181.         $form .= '  <caption>Registration form</caption>';
  182.         $form .= '  <tbody>';
  184.         if (isset($error))
  185.         {
  186.             $form .= '<tr><td colspan="3" align="center"><span class="error">'.$this->Format($error).'</span></td></tr>';
  187.         }
  188.         $form .= '      <tr>';
  189.         $form .= '          <th align="right" scope="row"><label for="name">Your username:</label></th>';
  190.         $form .= '          <td><input name="name" id="name" size="40" value="'.$name.'" title="Choose a valid username (formatted as a WikiName)" /></td>';
  191.         $form .= '          <td>'.$validname.'</td>';
  192.         $form .= '      </tr>';
  193.         $form .= '      <tr>';
  194.         $form .= '          <th align="right" scope="row"><label for="email">Your email address:</label></th>';
  195.         $form .= '          <td><input name="email" id="email" size="40" value="'.$email.'" title="Fill in a valid email address"/></td>';
  196.         $form .= '          <td align="left">'.$validemail.'</td>';
  197.         $form .= '      </tr>';
  198.         $form .= '      <tr>';
  199.         $form .= '          <th align="right" scope="row"><label for="password">Your password:</label></th>';
  200.         $form .= '          <td><input type="password" name="password" id="password" size="40" title="Choose a valid password (min. '.MIN_PASSW_LENGTH.' chars, no space)" /></td>';
  201.         $form .= '          <td align="left">'.$validpassword.'</td>';
  202.         $form .= '      </tr>';
  203.         $form .= '      <tr>';
  204.         $form .= '          <th align="right" scope="row"><label for="confpassword">Confirm password:</label></th>';
  205.         $form .= '          <td><input type="password" name="confpassword" id="confpassword" size="40" title="Type again your password for confirmation" /></td>';  
  206.         $form .= '          <td align="left">'.$validconfpassword.'</td>';
  207.         $form .= '      </tr>';
  208.         $form .= '      <tr>';
  209.         $form .= '          <td></td>';
  210.         $form .= '          <td><input type="submit" value="Register" title="Register" /></td>';  
  211.         $form .= '      </tr>';
  212.         $form .= '  </tbody>';
  213.         $form .= '  </table>';
  214.         $form .= $this->FormClose();
  216.         // output intro and form
  217.         print $intro.$form;
  218.     }
  219. }
  220. ?>

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


  • 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):
    1.         // build registration form
    2.         $form  = $this->FormOpen();
    3.         $form .= '  <table summary="form to provide registration data: username, email and password">';
    4.         $form .= '  <caption>Registration form</caption>';
    5.         $form .= '  <tbody>';
    7.         if (isset($error)) {
    8.             $form .= '<tr><td></td><td><span class="error">'.$this->Format($error).'</span></td></tr>';
    9.         }
    10.         $form .= '      <tr>';
    11.         $form .= '          <th align="right" scope="row"><label for="name">Your username:</label></th>';
    12.         $form .= '          <td><input name="name" id="name" size="40" value="'.$name.'" title="Choose a valid username (formatted as a WikiName)" /></td>';
    13.         $form .= '      </tr>';
    14.         $form .= '      <tr>';
    15.         $form .= '          <th align="right" scope="row"><label for="email">Your email address:</label></th>';
    16.         $form .= '          <td><input name="email" id="email" size="40" value="'.$email.'" title="Fill in a valid email address"/></td>';
    17.         $form .= '      </tr>';
    18.         $form .= '      <tr>';
    19.         $form .= '          <th align="right" scope="row"><label for="password">Your password:</label></th>';
    20.         $form .= '          <td><input type="password" name="password" id="password" size="40" title="Choose a valid password (min. 5 chars, no space)" /></td>';
    21.         $form .= '      </tr>';
    22.         $form .= '      <tr>';
    23.         $form .= '          <th align="right" scope="row"><label for="confpassword">Confirm password:</label></th>';
    24.         $form .= '          <td><input type="password" name="confpassword" id="confpassword" size="40" title="Type again your password for confirmation" /></td>';
    25.         $form .= '      </tr>';
    26.         $form .= '      <tr>';
    27.         $form .= '          <td></td>';
    28.         $form .= '          <td><input type="submit" value="Register" size="40" title="Register" /></td>';
    29.         $form .= '      </tr>';
    30.         $form .= '  </tbody>';
    31.         $form .= '  </table>';
    32.         $form .= $this->FormClose();
  • 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 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!
          • 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 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" 
      • and
        (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;
  2. 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...
  3. 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.

There are 4 comments on this page. [Show comments]
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki