next »

[Dr. Scotty Delicious]

This is an auto-generated support/comment thread for WebLoginPE.

WebLoginPE Demo Site: Check it out!

Change Log:
Online Documentation.

09/13/2007 v. 1.3.0
   1. New Parameter: &disableServices which will accept a comma separated list of services to disable. You can disable individual services like "deleteprofile" and "viewprofile" as well as entire types like "register" and "users".
   2. New Parameter: &prefixTable If your custom table does not use the MODx table prefix, you can use &prefixTable=`0` (default is 1).
   3. New Parameter: &usersList lets you specify multiple lists of users and a format for each list on &type=`users` and &type=`manager`.
   4. New Parameter: &tableCheck When you run WebLoginPE, it checks for the existence of the extra user attributes table and creates it if it does not exist. In 1.3.0 it also creates some new Web Access Service Events for plugins if they do not already exist. By setting &tableCheck to 0 (default is 1) you can skip these checks for a little speed bump.
   5. New Type: &type=`manager` displays a list of web users with links to edit their profile or delete their profile. Definitely use Access Permissions on this page!
   6. Added MODx System Events for most services. See the API documentation for full details.
   7. Print CSS by Dimitri Hilverda (Dimmy) added to documentation

09/02/2007 v. 1.2.0
   1. WebLoginPE will now function under PHP4. No functions or services were lost.
   2. Case insensitive login.
   3. Added &type=`users` to view all web users and individual user profiles.
   4. Added form input confirmation by with the use of name="inputname.confirm".
   5. WebLoginPE messages/errors are now templateable and set in a placeholder so you can display them anywhere on your page or in your forms.
   6. email address are verified against a simple regular expression to see if they match a standard email address format.
   7. New parameter &inputHandler for super-fine control of your form's <select>, <select multiple>, <input type="radio" /> and <input type="checkbox" /> form elements.

08/23/2007 v. 1.1.1
No new features added in this point release, but many changes to accommodate the atrocity that is Internet Explorer have been made. I have tested this release extensively on IE 5, 5.5, and 6 (using IEs4Linux on Ubuntu Feisty) and found it to be fully functional on all major browsers.

08/23/2007 v. 1.1
   1. Added parameter &pruneDays to specify number of days to wait before deleting non-activated user accounts (users who have registered but never logged in).
   2. Modified &regRequired to eliminate the need for the &captcha parameter.
   3. &captcha is now depreciated.
   4. Added extended user profile fields with the parameter &customFields.
   5. Extended profile table defaults to `web_user_attributes_extended`, but can be overridden with the &customTable parameter.
   6. Added parameter &regSuccessId to redirect after successful registration.
   7. Added parameter &regSuccessPause to specify a delay (in seconds) before redirecting. Defaults to 5 seconds to give the user time to read the confirmation message.
   8. Added parameter &registerSuccessTpl to display a custom chunk instead of redirecting. (only works if &regSuccessId is not set).
   9. Added new service "viewprofile" for &type=`profile` to allow users to view the profile of other users.
      (?service=viewprofile&username=Scotty%20Delicious)
  10. Added parameter &viewProfileTpl to specify a template for the new "viewprofile" service.
  11. Added a simple JavaScript file to force IE compliance with HTML element <button>
  12. I think there is more that I am forgetting.


08/20/2007 v. 1.0.2
   1. Added parameter &notify to specify email addresses to be notified of new user registrations.
   2. Added parameter &notifyTpl to specify notification email message body.
   3. Added parameter &notifySubject to specify notification email subject line.
   4. Converted all PHP mail() function calls to use the PHPMailer class included with MODx.
   5. Added "Terms of Service" agreement and checkbox to the default instant registration template.
   6. Fixed placeholders [+user.dob+] and [+user.lastlogin+]. If they are empty or "0", the placeholder is set to "Unknown".
   7. Fixed the Instant Login Form so that if there is an error, the fields are filled with the $_POST values so the user doesn't have to fill in all the fields again.


08/19/2007 v. 1.0.1
   1. Added parameter &regRequired to specify required input fields by name attribute.
   2. Added sanity checks for chunk templates.
   3. Added file_exists check for language file. Falls back to English (default) if language file is not found.
   4. Added a cookie for persistent login. can be a checkbox named "rememberme" or a select named "stayloggedin".

08/14/2007 v. 1.0
   1. Initial Public Release.

Use this forum to post any comments about this addition or any questions you have regarding its use.

Brief Description:
A progressively enhanced, AJAX capable, complete web user management snippet for MODx. Based on the brilliant work of Raymond Irving (xwisdom). This snippet manages web user login, logout, registration, profile editing, profile deleting, password recovery, and user activation. It can also perform these tasks asynchronously with javascript.

I have some examples up at my demo site.
A standard user login in the sidebar: http://demo.scottydelicious.com
An example of `instant` vs. `verify` user registrations: http://demo.scottydelicious.com/register.html
An example of asynchronous (AJAX) login: http://demo.scottydelicious.com/ajax-login.html

-sD-
Dr. Scotty Delicious, Scientist DFPA

[Calamarain]

I can't access the links. It says the page does not exist. The main domain gives a page telling the  domain exired August 10th.

[Dr. Scotty Delicious]

Ha!
Sorry about that... it was working when I posted the links!

The email address my registrar had was an old one, so I didn't get the renewal notification.
The links should be back up in just a little bit.

-sD-
Dr. Scotty Delicious, Scientist DFPA.

[Konsum]

Seems to be a very nice addition. Will this work with the SMF Bridge?

[Dr. Scotty Delicious]

Seems to be a very nice addition. Will this work with the SMF Bridge?

I am not positive, but I can't think of any reason that it shouldn't.
I took care to implement all the features of the original weblogin snippet, but try it out and see if it works with SMF bridge. You do not need to uninstall the old weblogin snippet to use WebLoginPE. Technically the *could be on the same page together, although it would be redundant.

-sD-
Dr. Scotty Delicious, Scientist DFPA

[Calamarain]

This might be a noob question
Can this snippet remember users with cookies for long, like the login on this forum permits (cookies with durations of multiple years), so users only have to log in once?

I have tried to use the standard Weblogin snippet like that, but all I managed is to create temporary php sessions. Perhaps I messed up with the 'remember me' tick box.

[Dr. Scotty Delicious]

This might be a noob question
Can this snippet remember users with cookies for long, like the login on this forum permits (cookies with durations of multiple years), so users only have to log in once?

I have tried to use the standard Weblogin snippet like that, but all I managed is to create temporary php sessions. Perhaps I messed up with the 'remember me' tick box.

No, you didn't mess it up. That is all that the weblogin snipped did was set a session.  Right now WebLoginPE uses the same format, but I need to fix that so that a real cookie can be set if desired. Thanks for the suggestion. I will try to work in a user selectable cookie expiration like on this forum.

BTW, I finally got a look at the demo site in IE6 and the CSS looks terrible and the AJAX javascript doesn't work! For now, try it in ANYTHING BUT IE! and I will get the style and JS worked out.

-sD-
Dr. Scotty Delicious, Scientist DFPA

[Calamarain]

That is all that the weblogin snipped did was set a session.  Right now WebLoginPE uses the same format, but I need to fix that so that a real cookie can be set if desired. Thanks for the suggestion. I will try to work in a user selectable cookie expiration like on this forum.

That's great, thanks

[Dr. Scotty Delicious]

one more correction I made at http://demo.scottydelicious.com/ajax-login.html . The Jot form had a CLASS of "jotForm" instead of an ID of "jotForm", so it was getting hijacked by the javascript and posts were not working. It is fixed now.

-sD-
Dr. Scotty Delicious, Scientist.

[pixelchutes]

Cool stuff, Scotty!

BTW, when I tried to register from the AJAX demo page, I clicked register and it appeared as if nothing happened at all. (I was watching where the other messages were appearing...)

After waiting a little bit, I clicked register again, but didn't see any type of "Loading..." message or anything to indicate action was occurring on the back end.

I checked my email during the interim, and when I got back to the page it said something along the lines of "Sorry, this username is already in use."

So, between my first click registering me and my 2nd click (preventing duplicate registration) I was somewhat confused...However, I do realize this is just a demo site, and I'm sure a loading indicator or disabled/hidden submit buttons could be added with ease to help streamline the registration process.

I also like how initial registration is no more than name/email/username Is this portion customizable? (e.g. maybe gender and country are required @ registration?)

[Dr. Scotty Delicious]

Cool stuff, Scotty!

BTW, when I tried to register from the AJAX demo page, I clicked register and it appeared as if nothing happened at all. (I was watching where the other messages were appearing...)

After waiting a little bit, I clicked register again, but didn't see any type of "Loading..." message or anything to indicate action was occurring on the back end.

I checked my email during the interim, and when I got back to the page it said something along the lines of "Sorry, this username is already in use."

So, between my first click registering me and my 2nd click (preventing duplicate registration) I was somewhat confused...However, I do realize this is just a demo site, and I'm sure a loading indicator or disabled/hidden submit buttons could be added with ease to help streamline the registration process.

Thanks for the feedback. I have been putting about 98% of my spare time into this snippet over the last 2-3 weeks and I just wanted to get it out and share it so I didn't put a lot of effort in to the style and function of the demo site. It is just a basic example of how AJAX can be used in user management.

The custom javascript file I wrote to handle the form hijacking is only a few lines of code, but adding more handlers for events and another animation to show a loading image while it is processing would be very simple.

I also like how initial registration is no more than name/email/username Is this portion customizable? (e.g. maybe gender and country are required @ registration?)

Yes, every possible view can be templated with chunks. If you download the WebLoginPE package from the MODx Repository, there is documentation on all the parameters, template parameters, and placeholders.  You can use as many or as few of the fields from web_user_attributes as you like.

The difference between an "instant" registration and a "verify" registration (the one you experienced was "verify") is that the "instant" registration lets the applicant choose their password, the "verify" registration randomly generates a password so the user is forced to give a real email address (if they want to log in to your site!  ).

-sD-
Dr. Scotty Delicious, Scientist DFPA.

[pixelchutes]

Is this portion customizable? (e.g. maybe gender and country are required @ registration?)

Yes, every possible view can be templated with chunks. If you download the WebLoginPE package from the MODx Repository, there is documentation on all the parameters, template parameters, and placeholders.  You can use as many or as few of the fields from web_user_attributes as you like.

So are you saying just by adding a field from web_user_attributes to the registration chunk that it automatically becomes required?

I am curious of your opinion in best handling required/non-required registration fields--outside of Name/E-mail/username--should it come up.

I have reviewed the docs and the code and it looks very good! Much more organized than the current weblogin snippets.

Shortly I will be implementing into a current instance that also leverages a custom "web_user_attributes_extra" table. I will post the code that allows for "eXtended profiles", as I call it.

[Dr. Scotty Delicious]

So are you saying just by adding a field from web_user_attributes to the registration chunk that it automatically becomes required?

I am curious of your opinion in best handling required/non-required registration fields--outside of Name/E-mail/username--should it come up.

I have reviewed the docs and the code and it looks very good! Much more organized than the current weblogin snippets.

Shortly I will be implementing into a current instance that also leverages a custom "web_user_attributes_extra" table. I will post the code that allows for "eXtended profiles", as I call it.

Not exactly. The documentation in the package has more details, but basically there are only 4 default required fields (email, fullname, username, and passwrord) or if register type is verify then password is not a required field, but if &capthca is true then formcode IS a required field.

What I was trying to explain in my last post is that with the templating system, if you want to do a "verify" registration, but you want additional fields, you must supply ALL the required fields (email, fullname, username) but you can also request any or all of the other fields as well. So in your custom form you might have email, fullname, username, dob, country, and comment.

-sD-
Dr. Scotty Delicious, Scientist DFPA.

[pixelchutes]

Good to know.

I guess my question really is, "Does it take modifying the Class directly (included .php file) to MAKE a registration field required?

In other words, say if I wanted Mobilephone to be a required registration field (verify or instant), I know I'd need to override the default chunk and add the form input manually to capture at point of registration. However, in doing just these steps, the Mobilephone field would not be required, client|server-side...

[Dr. Scotty Delicious]

Good to know.

I guess my question really is, "Does it take modifying the Class directly (included .php file) to MAKE a registration field required?

In other words, say if I wanted Mobilephone to be a required registration field (verify or instant), I know I'd need to override the default chunk and add the form input manually to capture at point of registration. However, in doing just these steps, the Mobilephone field would not be required, client|server-side...

Exactly right.
And you have sparked my imagination. In version 1.0.1(I will put it together tonight) I will add another parameter &regRequired=(email,username,mobilephone,dob), then In the class I will explode the var and do an isset or empty check in a for each block!  What do you think?

-sD-
Dr. Scotty Delicious, Scientist.

[pixelchutes]

Exactly right.
And you have sparked my imagination. In version 1.0.1(I will put it together tonight) I will add another parameter &regRequired=(email,username,mobilephone,dob), then In the class I will explode the var and do an isset or empty check in a for each block!  What do you think?

-sD-
Dr. Scotty Delicious, Scientist.

Beautiful! IMHO, a definable list of required fields (since no eForm integration) is a great way to go! Again, I personally enjoy the minimal sign up requirements, but I easily foresee some clients requiring more up front.

[Dr. Scotty Delicious]

Beautiful! IMHO, a definable list of required fields (since no eForm integration) is a great way to go! Again, I personally enjoy the minimal sign up requirements, but I easily foresee some clients requiring more up front.

Alright, I think I have the &regRequired parameter working with a foreach loop.  I will do some testing on it tonight and tomorrow and then commit it to version 1.0.1.

Any other suggestions from anyone?

-sD-
Dr. Scotty Delicious, Scientist.

[Konsum]

Any other suggestions from anyone?

The already mentioned cookie expiry option would be a really cool feature!

[Dr. Scotty Delicious]

Any other suggestions from anyone?

The already mentioned cookie expiry option would be a really cool feature!

I agree, and I think that is totally doable!

-sD-
Dr. Scotty Delicious, Scientist.

[Konsum]

What about adding a field to easily insert custom Terms of use? A user should need to accept the Terms upon registering.