Here’s a highly modified version of WLPE 1.3.1. A quick overview before I go into detail about what I changed. There have been three different projects in the last few months that required some pretty heavy changes to WLPE.
The big one was that I needed a way to be able to register users but not activate them right away. Basically, they needed to be put in a "pending" state to where an administrator could login and approve the user. This meant adding support for setting specific groups as well as controlling how each user group is activated.
There are other smaller changes that I had to make as well. I needed a way to allow bypassing the activation process for select domains. I also needed pagination of user lists for the manager part of WLPE. I also fixed a few very annoying behaviors with WLPE along the way.
So, here’s a list of the changes. After that, I’ll go into more detail about additional snippet parameters and how they work.
- Fixed issue with wrong page showing briefly after registration success when regSuccessPause is set to 0.
- Fixed issue with PHP4 compatible constructor causing problems with PHP5 (still needs to be tested with PHP4)
- Added approveuser manager function type for facilitating the activation of pending users.
- Added ability to set a field to obtain group settings [groupsField]
- Added ability to approve certain domains [approvedDomains]
- Added ability to set what group is used for pending users[Pending Users]
- Added pagination (thanks to Taff)
So, let’s go over each function and see how each of them has changed.
First is pagination which allows for paginating any user list via the user and manager types. This is pretty much the same pagination hacks that Taff did (
http://modxcms.com/forums/index.php?topic=20396.0). The default is set at 3000 but you can override it with the paging parameter:
Next is the changes made to registration. I’ve added a regType called ’pending’, which you set like this:
[!WebLoginPE? &type=`register` ®Type=`pending`!]
This registration type is very similar to ’verify’ except that it doesn’t send the user information yet by email. Instead, it puts the account into a ’Pending Users’ group, provided you have a ’Pending Users’ webuser group setup that is. If you want to use a different group or set of groups other than ’Pending Users’, you can override this with the ’pendingGroups’ parameter. This parameter will accept a single group name or a comma separated list of group names should you need to add a new user to more than one group:
&pendingGroups=`Group 1,Group 2`
Another option added to the register type is ’approvedDomains’. All this really does is check to see if the user’s email domain matches the list. If it does then the registration type is switched to ’verify’ and the user is approved right away. Not only can you set what domains should be auto approved but you can also set what group(s) those domains should be added to.
Sets are based on the group the domains are added to. A typical set would include a comma-separated list of domains followed by a colon and then the groups these domains should be added to. Each set is then separated by a double-pipe. Here’s a simple example:
&approvedDomains=`aol.com,msn.com,yahoo.com:Public Users||mydomain.com,yourdomain.com:Private Users||nobody.com:Spam`
As with any other registration type, any administrators that are set to receive a notification will get one even with the pending registration type.
So, that covers the registration part, but what about activating the pending users? That’s where the new approveuser service type comes into play. This is very similar to the saveuserprofile service type. Service types come into play with the type of form you’re using. In this case, we’re talking about the form used to manage a user profile. If you take a look at the defaultManageProfileTpl template, you’ll notice at the bottom that the Save button has a name of ’service’ and a value of ’saveuserprofile’. This tell WLPE which service to use when submitting the form. Changing this Save button so that it has a value of ’approveuser’ will set it to the new service that approves and activates new users:
<button type="submit" id="wlpeSaveProfileButton" name="service" value="approveuser">Save</button>
This is just an example so your Save button can be whatever you want it to be so long as the name and value remain the same when the form is submitted.
Both the ’saveuserprofile’ and ’approveuser’ service types have a new option that allows you to set the groups for the user when saved. A parameter called ’groupsField’ allows you to set the name of the field you’re using to store the group names that will be saved with the user profile:
The field could be just a textbox with a comma-separated list of webuser groups, an array of checkboxes, or a list of radio buttons. How you implement this is up to you. Keep in mind that you won’t always use the groupsField setting for activation. More on that in a second.
The approveuser service has three different parameters that you can use to control how the activation process works. Two of these work in tandem with one another for controlling the way individual groups are handled.
The first option is the ’activateId’ parameter. This basically allows you to select a specific page ID that users will be directed to when they are sent an activation page via email. The page could be the login page or a dedicated activation page:
The next two options allow you to set what form field to use for different activation types, what webuser groups should apply to each activation type, the email message template to use, and the email subject line. It’s easier to explain with an example.
Let’s say you want to have two basic activation types: ’approved’ and ’denied’. First, you start off by creating a few radio buttons with the value of each set to ’approved’ and ’denied’. Next, we would set a WLPE option called ’activatePost’ that tells it what form input to use when determining the activation type. So a form input called ’approvaltype’ might look like this:
&activatePost=`approvaltype`
Next, we want to set the activation types with a parameter called ’activateConfig’. This allows you to set the configuration for one or more types based on the received input from the input set in the activatePost parameter. Since we have two types we’ll have two sets of config options. Each set consists of the name of the activation type, what group(s) to set for it, the name of the chunk for the email template to use, and the email subject line. Each value is separated by a colon with each set separated by a single pipe. Here’s how the activateConfig parameter is laid out followed by an example:
&activateConfig=`type1:group1:chunk1:subject1|type2:group1,group2:chunk2:subject2`
&activateConfig=`approved:Registered Users:userApprovedMsg:My Website Login Details|denied:Denied Users:userDeniedMsg:My Website Registration Denied`
And that’s basically it. I’ve used this on a few sites and so far it’s been working pretty darn good. I’m very interested in seeing how others could refactor what I’ve done or improve it to make it better. Figured others would appreciate this stuff so...might as well throw it out to the masses.
Since I’m sure the SVN at the Google Code site already has some changes made, if everyone is ok with what I have here I’ll be happy to merge it all into the SVN. Cool?
Jeff
☆ A M B ☆
MODX Staff
