This is the documentation home for the WebLoginPE Add-On. It is an Evolution Extra and you should use Login instead for MODX Revolution.
How might you actually use WebLoginPE?
You can run WebLoginPE using the simplest function call:
You can do this to test whether the Snippet and its functions are working. Simply place that Snippet call on a page and preview the page; try logging in and updating your profile. It won't be pretty, but it should work. If you have trouble, have a look in the forums or check out the WebLoginPE Errors page.
The following wireframe outlines a site where you have a dedicated page with the login form. This example uses all of the default templates with all the default fields.
- You need to create a new Web User Group : go to Security?Web Permissions?Web User groups. In this example, I created a user group named "Logged In Users" -- you will reference this in the &groups parameter (I think the image references the wrong group name).
- You need to create a Document Group -- don't go anywhere! Still in the Web access permissions area of the manager, create a new document group, e.g. "Private Pages".
- Associate the User Group with the Document Group -- still in the web access permissions area, go to the User/Document group links and make sure the user group and the document group are associated.
- You need to create 7 pages:
1. The page containing the login form. It should contain a call to the WebLoginPE snippet (contained in one line):
2. The Welcome page. This is the page users see after logging in. It should belong to a special user group, e.g. "Private Pages" -- that way it is not publicly available. 3. Registration page. This should contain a call to the WebLoginPE snippet using the &type=`register` parameter:
4. Profile page. Belongs to the "Private Pages" group so it's not publicly accessible. The Snippet call looks like this:
5. Registration success page. This contains a message seen after a user registers. If you emailed the user a password, then the page should say that. It should also contain a link back to the login page. 6. Goodbye page. This is the page that users see after logging out. It can contain links back to the rest of the site. 7. You should also create a designated HTTP 500 page. This is the page that is shown if a public user tries to view a private page. Create the page, preferably with a link back to the login page, and be sure to denote it in the control panel under Tools?Configuration?Site under "Unauthorized page".
This setup is simple to understand (ha... relatively speaking), so it's easier to debug and it helps you get a feel for how these pieces work together. However, it has the following limitations:
- it uses only the default forms (none of the template chunks are used for customized forms)
- it doesn't use the more common layout where the login appears in a sidebar.
- The link to the login page will always say "login", even when the user is already logged in. No dynamic handling of this link is presented in this wireframe.
This list includes options you add to WebLoginPE's &type parameter.
This is the simplest to use, but as for understanding what's going on under the hood, this is the most complex option because all 4 functions (login, register, profile, logout) are encapsulated in a single page and are triggered by the value passed in the "service" variable (i.e. the value in $_POST['service']). Links between the different "pages" are automatically generated.
By default, the page shows a login form (or a welcome message if user is already logged in). It has links (buttons) to Login, Forgot Password, Register.
You first need a place where a visitor to your site can register to become a web user.
The registration page should contain a call to the Snippet:
Note that the form does not require a user to enter a name; only email and username are required by default. The fullname field can be blank. If you want to require the fullname field, use the ®Required parameter:
On your Home Page or Site Template, put the Snippet call like
where you would like the Login Box to appear.
Create a New Page called Registration, and put a Snippet call like
Create a New Page called Profile, and put a Snippet call like
You can customise each of these snippet calls, by adding parameters (see the Documentation in the download package), for example on your Registration Page, you could specify
to make new registrations be assigned to the Pending Users group, an email notification sent to email@example.com, user will be taken to success page (page ID is 74), and pause for 3 seconds.
But your form doesn't even HAVE a password? What's going on? This is a subtle problem that arises if you don't specify ®Type=`verify` when using a custom Chunk for the registerTpl. If you provide a custom chunk for the registration using the ®isterTpl parameter, the form needs to contain all required fields. The fields that are required are different for registration-type "register" than they are for registration-type "verify". The default action of the Snippet is to expect a full registration form including a password, so if your custom form doesn't contain a password field (or any other required field), it will fail validation. To rectify the situation, add ®Type=`verify` to your Snippet call. If you still have problems, copy the default Chunk into your database and verify that it is being referenced correctly.
See forum thread: http://modxcms.com/forums/index.php/topic,22083.0.html
There are various solutions there for various problems. In a nutshell, using type=`profile` may work when type=`simple` does not.
Make sure you have added the name of your form element to the customFields parameter AND that you have NO SPACES between multiple custom field, e.g. this Snippet call will fail:[||||\||]
Can you see the space after the comma immediately before "contact_time"? That little space causes the Snippet call to train-wreck. Also make sure you are using the correct
placeholder so WebLoginPE will know where to insert the form element.
Sometimes this comes up as a 404. Check the HTML of the page and verify that the action attribute is pointing where it should be pointing. The other thing that can trip you up, especially with friendly URLs enabled, is the absence of a base tag. Check out the forums and the wiki for more information, but essentially, you probably need to add a tag like the following to your template's head:
Yeah... this one sucks. If you're writing plugins, then hopefully you know what you're doing. Have a look in the Reports-->System Events for any log messages about how or why your plugin crashed.
Maybe you have your values/variables in backwards order? It should be:
Well, if your Snippet call (presumably the one where you login, often using &type=`simple`) uses the &liHomeId parameter to point to a special welcome page, that parameter can seem to override the &successTpl one because it forwards you to the new page before you ever get to see the successTpl chunk. If you navigate back to the login page after being redirected, you should see the contents of your successTpl chunk displayed for a logged in user.