Using custom views / templates
Every view that is presented to the user can be customized using MODx chunks.
The snippet changes between views based on a post-back system. It looks for the value of $_POST['service'] to determine which view to display. In the case of the default view for a logged in user, a form is presented with two submit buttons. The buttons each have the name attribute set to "service", but a different value
<button type="submit" id="wlpeProfileButton" name="service" value="profile">Profile</button>
If the "Log Out" button is pressed, the $_POST['service'] value is "logout" and WebLoginPE executes the code in the case 'logout': block.
The services in WebLoginPE are:
Simple | Register | Profile |
|
|
|
Manager | Users | Taconite |
|
|
|
&messageTpl
WebLoginPE will display many messages, either confirmations or errors. The message will be placed in a placeholder ([+wlpe.message+]) which you can put anywhere in your custom form or anywhere on the page.
When creating the chunk for &messageTpl you should place "[+wlpe.message.text+]" wherever you want the actual message to show up in the template.
Default:
<div class="wlpeMessage"><p class="wlpeMessageText">[+wlpe.message.text+]</p></div>&loginFormTpl
The view presented to the user asking for their "username" and "password". Required form field names are "username" and "password". Optional inputs are a checkbox named "rememberme" which sets a 5 year cookie, or a select named "stayloggedin" which sets a cookie for the number of seconds specified in each options value. The cookie name is "WebLoginPE" and the value is a MD5 hash of the username and password (usernames and passwords should never be set in the open because cookies are saved in plain text. That is why WebLoginPE converts them to a hash). When the user returns to your site, WebLoginPE grabs the cookie, uses an algorithm to decode the username and password, then automatically logs the user in.
&successTpl
The view presented to the user asking for their "username" and "password". Required form field names are "username" and "password". Optional inputs are a checkbox named "rememberme" which sets a 5 year cookie, or a select named "stayloggedin" which sets a cookie for the number of seconds specified in each options value. The cookie name is "WebLoginPE" and the value is a MD5 hash of the username and password (usernames and passwords should never be set in the open because cookies are saved in plain text. That is why WebLoginPE converts them to a hash). When the user returns to your site, WebLoginPE grabs the cookie, uses an algorythm to decode the username and password, then automatically logs the user in.
®isterTpl
The view presented to the user to register for a new account. You can have a form input for every field in the database table "web_user_attributes" and all the fields set in &customFields*. When setting up your form, the input name attribute should be the same as the field name in the table. For example, the form input asking for the users mobile phone number (table field "mobilephone") should be:
Placeholders for values in the $_POST array are available for use in your forms so that if there is an error, all the information that the user entered in your form is not lost. As you can see in the example for "mobilephone" above, the placeholder "[+post.inputname+]" is set for each input name attribute.
If you specified form fields in &inputHandler, you could also use the [+form.fieldname+] placeholder here.
*It is advised against providing inputs for id, internalKey, role, blocked, blockedunitl, blockedafter, failedlogincount, and sessionid as that can SERIOUSLY corrupt your entire MODx installation. Those fields should only be edited by the web master from the back end.
Default Instant:
See: defaultRegisterInstantFormTpl as HTMLSee: defaultRegisterInstantFormTpl as plain text.
Default Verify:
See: defaultRegisterVerifyFormTpl as HTMLSee: defaultRegisterVerifyFormTpl as plain text.
®isterSuccessTpl
The view presented to the user to after successfully registering for a new account. If you want this custom view to be displayed after registration, DO NOT put the ®SuccessId parameter in your call. The default is the whatever is specified in &loginFormTpl so the user can log in after registering.
&tosChunk
In your registration form, you may want your users to agree to your "Terms Of Service / Privacy Policy" before you accept their registration. You specify your terms of service chunk with this parameter, then in your registration form, use the placeholder [+tos+] (which is set by WebLoginPE to hold your tosChunk) where you want your Terms of Service to be displayed and put a checkbox with the name attribute set to "tos". You should also specify "tos" in the ®Required parameter to make sure that if they don't check it (signifying that they agree) they will not be allowed to register.
<div id="wlpeTermsOfService">[+tos+]</div>
<label for="wlpeTosCheckbox" id="wlpeTosCheckboxLabel"><span class="required">*</span>I accept the Terms of Service
<input type="checkbox" id="wlpeTosCheckbox" name="tos" />
</label>
The default terms of service were generated by Kinky Solution's Terms Of Service / Privacy Policy Document Generator.
&profileTpl
The form presented to the user which allows them to modify their attributes stored in the databse. Like ®isterTpl, this form can contain as many or as few of the table fields from web_user_attributes AND the extended user attributes table as you want. The difference in this form is that you can set the value of the form fields to one of the placeholders. For example the "Full Name" input would look like:
If you specified form fields in &inputHandler, you could also use the [+form.fieldname+] placeholder here and the users selections and checks would be remembered and pre-selected or pre-checked.
&userOuterTpl
The template that works as a "wrapper" for each of your lists in type=`users`.
&usersTpl
When you have called WebLoginPE with &type=`users`, each user in the databases is listed and (in the default template) their user image and username are links to a separate area that can list more details about the user and give other users a form to contact that user. Since this view may contain privileged data, you may want to use "Access Permissions" on this page. The &usersTpl paramter chunk should define the structure of the block for EACH user on this page. It will loop through each user, one at a time, exchange the placeholders for their info, add it to the que, then go to the next user. When it has finished looping over each user, it will return the entire que to the page. This view has access to the [+user.age+] placeholder that calculates the user's age based on their DOB.
If you specified form fields in &customFields parameter for register and profile, you should also specify them here to make sure placeholders are set for them.
&viewProfileTpl
When you have called WebLoginPE with &type=`users`, each user in the databases is listed and (in the default template) their user image and username are links to a separate area that can list more details about the user and give other users a form to contact that user. As with &usersTpl, this view may contain privileged data, you may want to use "Access Permissions" on the calling page. The &viewProfileTpl paramter chunk should define the structure of this separate area to view more details on an individual user. This view has access to the [+view.age+] placeholder that calculates the user's age based on their DOB.
If you specified form fields in &customFields parameter for register and profile, you should also specify them here to make sure placeholders are set for them.
&profileDeleteTpl
The form presented to the user to confirm that they actually want to delete their account. This is presented after the user has clicked the "Delete My Profile" button on the profile page. We want to make sure they didn't click it by accident!
&manageOuterTpl
The template that works as a "wrapper" for each of your lists in type=`manager`. The default is the same as the default &userOuterTpl.
&manageTpl
The template (chunk) that will be applied to each user in type=`manager`.
&manageProfileTpl
The Form (chunk) that will be displayed when editing a user's attributes in type=`manager`.
&manageDeleteTpl
The Form (chunk) that will be displayed asking for confirmation of intention to delete after clicking the "Delete Profile" button for a user in type=`manager`.
&resetTpl
The form presented when a user clicks the "Forgot Password" button. This form has only one input ("email"). They enter their email address, WebLoginPE sets a random password and key in the web_users table's cachepwd field and sends them a link to the URL of the page that this was called from with the string "?service=activate&userid=3&activationkey=kl3tW5rtDi where "3" would be the users internalKey and "kl3tW5rtDi" would be the randomly generated activation key which is a 10 character string.
&activateTpl
This form is presented when the user clicks the link in the email that was sent from the &resetTpl form. It is the view for service=activate. The user is asked for the temporary password that was emailed to them and they are given the option to set a new password. WebLoginPE then checks that the temporary password and the activationkey match what was stored in the cachepwd field for the internalKey in the web_users table. If everything checks out, the new password that the user entered is activated. The default form has three input fields with the name attributes "activationpassword", "newpassword", and "newpassword.confirm".
¬ifyTpl
This is not a view presented to the user, but a template format for the email message that will be sent to the addresses in ¬ify. It uses all the placeholders that are available in the Tools > Configuration > User > Web signup email template, with the addition of [+uem+] for the user's email address. The user's password will NOT be available in this template.
Default:
See: defaultNotifyTpl as plain text.¬ifySubject
This is also not a view presented to the user, but a definition of the subject line for the email message that will be sent to the addresses in ¬ify.