This addon has been superseded by extended users functionality.
viewtopic.php?f=5&t=8581
Hi everybody
The long awaited members module is finally here.
If you have been following Couch's development in recent times, you must have certainly realized that with the advent of features like 'relations' , 'front-end submissions' and 'custom admin screens', Couch is slowly getting to the point where we can use it to create pretty complex 'vertical' applications e.g. a full-fledged e-commerce solution or even forums.
However, the one missing feature that had always prevented this from happening was a proper user-login/registration module.
While this was always on the cards, @cheesypoof simply went ahead and created a full-blown module (http://www.couchcms.com/forum/viewtopic.php?f=8&t=7939), amazingly using Couch tags alone!
The beauty of this implementation was that it used a regular Couch template for creating user-accounts.
As each user-account is basically only a regular cloned-page, this approach places the full gamut of Couch's existing features at its disposal.
For example -
a. We can define any number/type of editable regions (i.e. custom fields) to hold user-data. So if your site decides to follow Facebook in allowing users to idenfify themselves using 51 gender types - no sweat
b. We can use the 'relationship' feature to relate 'users' with other cloned pages e.g. posts, likes, videos, etc.
c. We can use the full power of cms:pages tag to list users slicing and dicing through the custom fields.
The members module being released here is an adaptation of @cheesypoof's implementation. I've only abstracted away the complexities of the various functions by exposing them as regular Couch tags.
This should make it a breeze for anyone to implement a full-fledged user login/registration using their own designs.
Installation:
1. Download the attached zip and extract its contents.
Copy the 'couch/addons/member' folder to the corresponding location of your installation and
add the following line to 'couch/addons/kfunctions.php' file (you might have to rename kfunctions.example.php to kfunctions.php)
2. Place the 'members' folder in your site's root and register all the 5 templates within it (i.e. visit the templates using your browser while being logged-in as super-admin e.g. type http://www.yoursite.com/members/index.php in your browser's address bar to execute and thus register the 'members/index.php' template)
NOTE:
The templates found in the 'members' folder are only meant to show a sample implementation of all functions provided by this module. As such, they use only bare-essential markup. You are expected to use your own markup once you understand how things work.
The names and locations of these templates are configurable from the 'addons/member/config.php' file but while playing around with the module for the first time it is recommended you go with the current settings.
Usage:
The 'members/index.php' template is the core template (where every cloned page of this template will represent a user-account).
Please notice the cms:member_define_fields tag in it - it creates all the required fields.
Of course, you are free to add any number and types of editable regions to this template.
As mentioned, this module exposes all typical user-login/registration functions as regular Couch tags.
So what are these 'typical' functions?
Broadly speaking, there are six such functions that you are likely to find in any user-login implementation you'd find out there.
I like to group them in pairs, so we have -
Login/Logout
Forgot/Reset password
Register/Activate account
This addon exposes each of these functions as a separate tag -
Login - cms:member_process_login_form
Logout - cms:member_process_logout
ForgotPassword - cms:member_process_forgot_password_form
Reset password - cms:member_process_reset_password
Registration - cms:member_process_registration_form
Activate account - cms:member_process_activation
The tags, of course, are meant to be placed within Couch templates.
If one so wishes, all the six tags can be placed on a single template.
However, for sanity's sake, it is logical to delegate each of the three above-mentioned 'pairs' to a separate template each.
This is how we structured the sample implementation -
Login/Logout - members/login.php
ForgotPassword/Reset password - members/lost-password.php
Registration/Activate account - members/register.php
('Edit profile' function (members/profile.php) is not a login/registration related function, as far as we are concerned - we can code that us using front-end forms.)
Please take a look at the templates to see how the tags are used.
If you are conversant with how forms work in Couch, you'll find the code pretty straightforward.
Following are a few points that merit your attention, though -
1. In all the templates of your site that need access-protection, we place the following code at the
top of the template -
Depending on whether or not a user is logged-in, this tag sets some variables that can be used further down in the template e.g.
Essentially, except for 'members/index.php', ALL the other templates make use of <cms:member_check_login /> like ordinary templates of the site.
To add a 'logout' link for the logged-in user, use the following code
2. Of the six tags, the following three tags are supposed to be used only within a form's success condition (the rest use querystring parameter)-
cms:member_process_login_form
cms:member_process_forgot_password_form
cms:member_process_registration_form
3. Each of the three above-mentioned tags expect some input fields with well-defined names in the forms. I've documented those in the templates.
4. Some of the tags (e.g. cms:member_process_reset_password etc.), as part of their function, send emails to users.
The elements of the emails can be changed through the module's config file.
However, if you wish to prevent these tags from automatically sending the emails so that you could do it using your own code, set the 'send_mail' parameter to '0' (with cms:member_process_registration_form this parameter is '_send_mail' to avoid possible clash with custom fields). for example -
5. Finally, the cms:member_process_registration_form deserves sone extra attention -
a. As you know, all cloned pages expect the k_page_name field to have a unique value.
With member accounts, the email is also unique. So we basically end up with two unique ids.
This is usually redundant and we can make do with only the email (except perhaps in applications like 'forums' where the name also has to be uniquely identifiable).
The way this tag works, if we do not use an input field named 'member_name' in the registration form, cms:member_process_registration_form automatically creates a random k_page_name.
b. This tag works much like a databound-from (please see http://www.couchcms.com/docs/concepts/d ... forms.html) so it can accept explicit field_names as parameters.
So, for example, if the registration form has an input field named 'dob' that is to persisted in an editable region named 'dob' of the index template, the code would become
c. Using the registration form without spam protection is a sure way to invite a deluge of bogus user accounts. Please do make sure to use the protective measures discussed at http://www.couchcms.com/forum/viewtopic ... 047&p=9255
Hope this helps.
As always, your feedback is solicited
viewtopic.php?f=5&t=8581
Hi everybody

The long awaited members module is finally here.
If you have been following Couch's development in recent times, you must have certainly realized that with the advent of features like 'relations' , 'front-end submissions' and 'custom admin screens', Couch is slowly getting to the point where we can use it to create pretty complex 'vertical' applications e.g. a full-fledged e-commerce solution or even forums.
However, the one missing feature that had always prevented this from happening was a proper user-login/registration module.
While this was always on the cards, @cheesypoof simply went ahead and created a full-blown module (http://www.couchcms.com/forum/viewtopic.php?f=8&t=7939), amazingly using Couch tags alone!
The beauty of this implementation was that it used a regular Couch template for creating user-accounts.
As each user-account is basically only a regular cloned-page, this approach places the full gamut of Couch's existing features at its disposal.
For example -
a. We can define any number/type of editable regions (i.e. custom fields) to hold user-data. So if your site decides to follow Facebook in allowing users to idenfify themselves using 51 gender types - no sweat

b. We can use the 'relationship' feature to relate 'users' with other cloned pages e.g. posts, likes, videos, etc.
c. We can use the full power of cms:pages tag to list users slicing and dicing through the custom fields.
The members module being released here is an adaptation of @cheesypoof's implementation. I've only abstracted away the complexities of the various functions by exposing them as regular Couch tags.
This should make it a breeze for anyone to implement a full-fledged user login/registration using their own designs.
Installation:
1. Download the attached zip and extract its contents.
Copy the 'couch/addons/member' folder to the corresponding location of your installation and
add the following line to 'couch/addons/kfunctions.php' file (you might have to rename kfunctions.example.php to kfunctions.php)
- Code: Select all
require_once( K_COUCH_DIR.'addons/member/member.php' );
2. Place the 'members' folder in your site's root and register all the 5 templates within it (i.e. visit the templates using your browser while being logged-in as super-admin e.g. type http://www.yoursite.com/members/index.php in your browser's address bar to execute and thus register the 'members/index.php' template)
NOTE:
The templates found in the 'members' folder are only meant to show a sample implementation of all functions provided by this module. As such, they use only bare-essential markup. You are expected to use your own markup once you understand how things work.
The names and locations of these templates are configurable from the 'addons/member/config.php' file but while playing around with the module for the first time it is recommended you go with the current settings.
Usage:
The 'members/index.php' template is the core template (where every cloned page of this template will represent a user-account).
Please notice the cms:member_define_fields tag in it - it creates all the required fields.
Of course, you are free to add any number and types of editable regions to this template.
As mentioned, this module exposes all typical user-login/registration functions as regular Couch tags.
So what are these 'typical' functions?
Broadly speaking, there are six such functions that you are likely to find in any user-login implementation you'd find out there.
I like to group them in pairs, so we have -
Login/Logout
Forgot/Reset password
Register/Activate account
This addon exposes each of these functions as a separate tag -
Login - cms:member_process_login_form
Logout - cms:member_process_logout
ForgotPassword - cms:member_process_forgot_password_form
Reset password - cms:member_process_reset_password
Registration - cms:member_process_registration_form
Activate account - cms:member_process_activation
The tags, of course, are meant to be placed within Couch templates.
If one so wishes, all the six tags can be placed on a single template.
However, for sanity's sake, it is logical to delegate each of the three above-mentioned 'pairs' to a separate template each.
This is how we structured the sample implementation -
Login/Logout - members/login.php
ForgotPassword/Reset password - members/lost-password.php
Registration/Activate account - members/register.php
('Edit profile' function (members/profile.php) is not a login/registration related function, as far as we are concerned - we can code that us using front-end forms.)
Please take a look at the templates to see how the tags are used.
If you are conversant with how forms work in Couch, you'll find the code pretty straightforward.
Following are a few points that merit your attention, though -
1. In all the templates of your site that need access-protection, we place the following code at the
top of the template -
- Code: Select all
<cms:member_check_login />
Depending on whether or not a user is logged-in, this tag sets some variables that can be used further down in the template e.g.
- Code: Select all
<cms:if k_member_logged_out >
<cms:redirect "<cms:member_login_link />" />
</cms:if>
Essentially, except for 'members/index.php', ALL the other templates make use of <cms:member_check_login /> like ordinary templates of the site.
To add a 'logout' link for the logged-in user, use the following code
- Code: Select all
<a href="<cms:member_logout_link />">logout</a>
2. Of the six tags, the following three tags are supposed to be used only within a form's success condition (the rest use querystring parameter)-
cms:member_process_login_form
cms:member_process_forgot_password_form
cms:member_process_registration_form
3. Each of the three above-mentioned tags expect some input fields with well-defined names in the forms. I've documented those in the templates.
4. Some of the tags (e.g. cms:member_process_reset_password etc.), as part of their function, send emails to users.
The elements of the emails can be changed through the module's config file.
However, if you wish to prevent these tags from automatically sending the emails so that you could do it using your own code, set the 'send_mail' parameter to '0' (with cms:member_process_registration_form this parameter is '_send_mail' to avoid possible clash with custom fields). for example -
- Code: Select all
<cms:member_process_registration_form
_send_mail='0'
/>
<cms:if k_success >
<cms:send_mail ...
...
<cms:set_flash name='success_msg' value='1' />
<cms:redirect k_page_link />
</cms:if>
5. Finally, the cms:member_process_registration_form deserves sone extra attention -
a. As you know, all cloned pages expect the k_page_name field to have a unique value.
With member accounts, the email is also unique. So we basically end up with two unique ids.
This is usually redundant and we can make do with only the email (except perhaps in applications like 'forums' where the name also has to be uniquely identifiable).
The way this tag works, if we do not use an input field named 'member_name' in the registration form, cms:member_process_registration_form automatically creates a random k_page_name.
b. This tag works much like a databound-from (please see http://www.couchcms.com/docs/concepts/d ... forms.html) so it can accept explicit field_names as parameters.
So, for example, if the registration form has an input field named 'dob' that is to persisted in an editable region named 'dob' of the index template, the code would become
- Code: Select all
<cms:member_process_registration_form
dob=frm_dob
/>
c. Using the registration form without spam protection is a sure way to invite a deluge of bogus user accounts. Please do make sure to use the protective measures discussed at http://www.couchcms.com/forum/viewtopic ... 047&p=9255
Hope this helps.
As always, your feedback is solicited
