WebLoginPE (1.3.0): Advanced WebUser Management and Extended Profiling.

160 Posts

ConseilsWeb Reply #31, 16 years, 8 months ago

Good work on the snippet, Doc.

French language file
I translated the language file in french for those interested. I did my best to check for spellings, but something might have escaped me, feel free to change it.

Olivier Deland
Montreal, Canada - Web Developer

1,193 Posts

ScottyDelicious Reply #32, 16 years, 8 months ago

Quote from: ConseilsWeb at Aug 21, 2007, 08:37 PM

Good work on the snippet, Doc.

French language file
I translated the language file in french for those interested. I did my best to check for spellings, but something might have escaped me, feel free to change it.

Thanks ConseilsWeb, I have a new version that I am planning to post tonight. I will include your translation with it.

The new version will include these changes: Added parameter &pruneDays to specify number of days to wait before deleting non-activated user accounts (users who have registered but never logged in). Modified &regRequired to eliminate the need for the &captcha parameter. &captcha is now depreciated.

Here is a selection from the documentation on the new &pruneDays parameter
Quote from: WebLoginPE’s

The number of days after which non-activated user accounts will be deleted. When a new user registers, a time stamp for the current date/time is placed in the `cachepwd` column of the `web_users` table. When they log in, the timestamp is deleted. If a user passes a false email address, or they register and never log in, the account is stale, useless, and takes up space in your database.

Example: &pruneDays=`30` will check the database for all accounts that have a time stamp in the cachepwd column, then check those accounts to see if the time stamp in cachepwd is older than the number of days we set in the &pruneDays parameter (in this case, 30 days). If it IS older, the account is deleted and a notification is sent to the address of [(emailsender)].

If this parameter is not set in your snippet call, no user pruning action will ever be taken

This version 1.0.3 is done, I am just waiting on any further suggestions or contributions, so I will post it in the Repository later tonight ( it is 3:55PM for me right now).

-sD-
Dr. Scotty Delicious, Scientist DFPA.

Husband, Father, Brother, Son, Programmer, Atheist, Nurse, Friend, Lover, Fighter.
All of the above... in no specific order.

I send pointless little messages

☆ A M B ☆
1,056 Posts

pixelchutes Reply #33, 16 years, 8 months ago

How about extended profile options (external table joined on internalKey) cool

Mike Reid - www.pixelchutes.com
MODx Ambassador / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.

1,193 Posts

ScottyDelicious Reply #34, 16 years, 8 months ago

Quote from: pixelchutes at Aug 21, 2007, 10:11 PM

How about extended profile options (external table joined on internalKey)

That is in the works tonight!
I may put off releasing 1.0.3 tonight just to implement &regCutstomFields to extend web_user_attributes.
The call would look something like this

[!WebLoginPE? &regCustomFields=`website,aim,address1,address2,member_rank`!]

I haven’t decide if I am going to add columns to web_user_attributes (because that is what these would be!) or, as you said, have a new table ("web_user_attributes_extended" for example) joined on internalKey.

It doesn’t seem like adding a column or two to the web_user_attributes table would affect the manager in anyway, but I will let Jason or one of the other core team chime in before I do it.

-sD-
Dr. Scotty Delicious, Scientist DFPA.

Husband, Father, Brother, Son, Programmer, Atheist, Nurse, Friend, Lover, Fighter.
All of the above... in no specific order.

I send pointless little messages

13 Posts

Glendolah Reply #35, 16 years, 8 months ago

Hi, this snippet is very good.
Another suggestion is to be able to choose what chunk is displayed when the user has successfully registered. I think at the moment you can choose the tpl for a successful login, or sending a user to a certain page depending on the web user group they were added to. Perhaps there could be a similar situation with the registration form?

1,193 Posts

ScottyDelicious Reply #36, 16 years, 8 months ago

Quote from: Glendolah at Aug 22, 2007, 05:57 AM

Hi, this snippet is very good.
Another suggestion is to be able to choose what chunk is displayed when the user has successfully registered. I think at the moment you can choose the tpl for a successful login, or sending a user to a certain page depending on the web user group they were added to. Perhaps there could be a similar situation with the registration form?

so, like liHomeId and loHomeId, add a parameter like &regSuccessHomeId and &regSuccessTpl?
How does that sound? It would give the user an choice to redirect to a page on successful registration, OR they could have a template displayed, like a notice that they have been successfully registered, welcome them to your members group, and maybe display a login form for them to use?

-sD-
Dr. Scotty Delicious, Scientist DFPA.

Husband, Father, Brother, Son, Programmer, Atheist, Nurse, Friend, Lover, Fighter.
All of the above... in no specific order.

I send pointless little messages

☆ A M B ☆
1,056 Posts

pixelchutes Reply #37, 16 years, 8 months ago

Sounds good to me. Options are always nice!!!

As for the "extended" table thoughts, wouldn’t it be cool if you could define/map your extra reg fields to a given table name, and if not defined it would assume default attributes table?

I could see how the SQL if/else logic could get a bit clouded, but being able to choose one way or the other would be nice.

One plus of having a separate table (joined on internalKey) is the ability to "Opt Out" when performing a Backup. This way, you can optionally backup the default/dependent tables, and have a choice to backup the "extended" or not...plus, this way you know it shouldn’t interfere w/ core code/3rd party add-ons.

Mike Reid - www.pixelchutes.com
MODx Ambassador / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.

1,193 Posts

ScottyDelicious Reply #38, 16 years, 8 months ago

Quote from: pixelchutes at Aug 22, 2007, 06:12 AM

Sounds good to me. Options are always nice!!!

As for the "extended" table thoughts, wouldn’t it be cool if you could define/map your extra reg fields to a given table name, and if not defined it would assume default attributes table?

I could see how the SQL if/else logic could get a bit clouded, but being able to choose one way or the other would be nice.

One plus of having a separate table (joined on internalKey) is the ability to "Opt Out" when performing a Backup. This way, you can optionally backup the default/dependent tables, and have a choice to backup the "extended" or not...plus, this way you know it shouldn’t interfere w/ core code/3rd party add-ons.

I discussed this with Jason (OpenGeek) earlier tonight, and he suggested using an alternate table joined on internalKey (as you suggested... kudos!).

This is how I am planning to have it work out.
A user can put &regCustomFields in their WebLoginPE call with a comma separated list of custom table columns they want inserted into "web_user_attributes_extended". If WebLoginPE sees that &regCustomFields is specified, it will check for the "web_user_attributes_extended" and create it if it is not there, then it will explode the comma separated list into an array, foreach over it to see if those columns exist in the "web_user_attributes_extended" table and create them only if they are not already there. Then it will do the normal registration stuff, putting the data into the standard tables and the extra stuff into the "web_user_attributes_extended" table. This table will also be queried on login. I am refactoring the placeholder function in WebLoginPE to take account for the custom fields, so if you have a custom field called "website", the placeholder [+user.website+] will automatically be set.

*** edit ***
If you notice in the WebLoginPE registration and profile forms, the name attributes on the form fields are exactly the column names in the database. for custom fields, the name attribute on your custom forms should match exactly the column name you specified in &regCustomFields.

-sD-
Dr. Scotty Delicious, Scientist DFPA.

Husband, Father, Brother, Son, Programmer, Atheist, Nurse, Friend, Lover, Fighter.
All of the above... in no specific order.

I send pointless little messages

☆ A M B ☆
1,056 Posts

pixelchutes Reply #39, 16 years, 8 months ago

Yes, great practice! I am very fond of mapping my input names directly to their corresponding DB columns!

If at all possible, can you make the table name for "web_user_attributes_extended" also be a parameter? (Default can remain "_extended")...this way, if I want to call it "web_user_attributes_xxyyzz" I still could...

I wrote a plugin that hijacks the Web User form in MODx Manager and allows updating of custom fields to a "_extended" table directly from within the manager

Of course, the implementation was a bit "hard coded". Doing something similar (using WebLoginPE) could prove to be a little tricky given the dynamic nature of your custom reg. field handling... Hmmm...

Mike Reid - www.pixelchutes.com
MODx Ambassador / Contributor
[Module] MultiMedia Manager / [Module] SiteSearch / [Snippet] DocPassword / [Plugin] EditArea / We support FoxyCart
________________________________
Where every pixel matters.

1,193 Posts

ScottyDelicious Reply #40, 16 years, 8 months ago

Quote from: pixelchutes at Aug 22, 2007, 06:35 AM

Yes, great practice! I am very fond of mapping my input names directly to their corresponding DB columns!

If at all possible, can you make the table name for "web_user_attributes_extended" also be a parameter? (Default can remain "_extended")...this way, if I want to call it "web_user_attributes_xxyyzz" I still could...

I think that is going to make things really complicated, but I will see what I can do. I like the idea, so I will do my best to make it work

-sD-
Dr. Scotty Delicious, Scientist DFPA.

Husband, Father, Brother, Son, Programmer, Atheist, Nurse, Friend, Lover, Fighter.
All of the above... in no specific order.

I send pointless little messages