Tutorial: Using user/register

Documentation for versions 3.1 to 3.4

Sites requiring a user to login must have the facility to register the user first. This requires using the ez publish user module with the register view. This is simply done by appending user/register to the root of your website. For example:
http://my-web-site.com/user/register
With the default settings of the ez publish installation this will display a registration screen for users but the format of the display may not be to your liking.

Overriding the display of default user class

The standard user class in ez publish has the minimum number of fields to make it useful for users. It contains two text fields and a ‚user account‘ datatype. If you want to change the display of user objects you need to override two files: Note: The following template files are found within the folder: design/standard/templates/
  • user/register.tpl
  • content/datatype/edit/ezuser.tpl
The second override is for the datatype. Generally it is better to copy the current files required and only change what is needed to be changed, leaving in place the input tags required to submit the form. However, sometimes even the design of the input tags need to be changed. The following two sections list the fields that must be present in order to perform a successful user register. Once this is known and understand applying a design is straightforward. Note: it is highly recommended you examine the original template files within the standard directory for contextual reference. An example override file (thanks James!) for user/register is:
[register_user]

Source=user/register.tpl

MatchFile=user/register.tpl

Subdir=templates

Match[class_identifier]=user
With version 3.3 and 3.4 I’ve noticed that if your override file is structured in the same way as the original there is no need to put in an explicit override. If your structure changes then you do. For example, user/register is located within design/standard/templates/. If your override file is located at design/user/override/templates/user/register.tpl, where user is your design, there is no need to enter the override. This applies to all overrides.

Input tags for register.tpl

The standard register template uses a pre-defined variable called {$content_attributes}. This is an array containing all of the attributes of your user class. The simple way to use this for editing is to loop through the array and use {attribute_edit_gui} to display the correct edit boxes. If you have modified your user class you may need to break out of this. If a simple loop cannot work for you then refer to the attributes directly like this:
{let my_name=$content_attributes[0]

     my_user_account=$content_attributes[1]

     my_address=$content_attributes[2]

}

{$my_name.contentclass_attribute.name} {attribute_edit_gui attribute=$my_name}

{$my_user_account.contentclass_attribute.name} {attribute_edit_gui attribute=$my_user_account}

<i>My address</i> {attribute_edit_gui=$my_address}

{/let}
Here you must make sure that you index the array in the correct order otherwise you will not have the correct attribute when you expect it. This is a simple example which allows you to add design to it as you need. To submit the form you must specify the content object id of each attribute. If you use the loop method then you can set the id at the same time as performing the loop. Examine the original template to see this in action. If you used the break out method above enter code like this:
<input type="hidden" name="ContentObjectAttribute_id[]" value="{$content_attributes[0].id}" />

<input type="hidden" name="ContentObjectAttribute_id[]" value="{$content_attributes[1].id}" />

<input type="hidden" name="ContentObjectAttribute_id[]" value="{$content_attributes[2].id}" />
The name ContentObjectAttribute_id[] will map to an array in the php so each id will be an element in that array. Make sure you have an id for each attribute you have. To finish the template off you need a submit button, and the complimentary cancel button. Again the key item to note here is the name used to identify the submit button. You can apply different design here if you wish, make it an image submit button or whatever, but keep the name the same.
<input type="submit" name="PublishButton" value="submit">

<input type="button" name="CancelButton" value="cancel register">

Input tags for ezuser.tpl

Normally you use an {attribute_edit_gui} to display such details but since we are overriding an attributes display we need to have direct calls. For a ezuser datatype there are four variables that must be set with a specific name. In this case the variable {$attribute} is pre-defined in the namespace of the template. The names are:
  • ContentObjectAttribute_data_user_login_{$attribute.id}
  • ContentObjectAttribute_data_user_email_{$attribute.id}
  • ContentObjectAttribute_data_user_password_{$attribute.id}
  • ContentObjectAttribute_data_user_password_confirm_{$attribute.id}
Each name must used within an input tag, for example:
<input type="text" name="ContentObjectAttribute_data_user_login_{$attribute.id}" size="11" value="" />

Creating a new user

Often the default user class needs to be extended or changed to hold additional information, such as address information, for example. If the default user class is extended then only the override template user/register.tpl needs to be altered to account for the changes. Should a new class be created then a configuration file needs to be adjusted. Generally the configuration file site.ini will contain this information, but it may be set within your site.ini for your site access or in your overrides directory. Modifications are made within this group:
[UserSettings]
Groups are indicated by the use of the square bracket. After creating your new user class make sure this setting has the correct user class id
UserClassID=NEW_CLASS_ID
If your new user class was not created within the Users class group then alter this value to the group it was created within.
UserClassGroupID=2
If you create a new user group for your new user class you should change this setting to the correct node id:
DefaultUserPlacement=NEW_NODE_ID
This will place user objects within the node specified. If you wish your new user to be assigned a specific section alter this value but this is generally not changed.
DefaultSectionID=1
An example of this all together is:
[UserSettings]

DefaultUserPlacement=12

DefaultSectionID=1

UserClassID=4

UserClassGroupID=2
which is the default for ez publish.

Making sure registered users are valid

Be default ez publish sends an email to a recently registered user. Within this email is a link with a security code that, when clicked, informs ez that the email recipient is indeed the user who registered and that they want to continue. Within the above UserSettings group make sure the setting
VerifyUserEmail=enabled
is set to enabled or disabled, depending on what you need.

User roles

If you have created a new user class and group you will need to make sure that your location for users has the correct role permissions set. This should apply to the group and will ensure created users within that group receive the same permissions.

Kommentar hinterlassen