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

Quote from: pixelchutes at Sep 06, 2007, 09:28 AM

FYI: I have mashed up SMF Connector and WLPE. By adding and mapping internalKey to SMF’s members table `smf_members` I can have custom control over Forum profiles, too (Namely things like e-mail and Display Name, attributes that aren’t able to be changed natively w/ SMF Connector...) It’s scary how easy you’ve made it. Event functions to run prior to or following the update/edit procedure would allow for dupe checking and extended validation in unique circumstances!

That sounds quite interesting. But to be honest, I don’t get what exactly you did to achieve this. Could you explain it bit more in detail? That could then be also added to the wiki, I suppose.

BTW: Scotty, this snippet is terrific!

Quote from: Soshite at Sep 06, 2007, 04:35 PM

pixelchutes, do you know if it would be possible to apply the SMF<->WLPE briding you’ve done to other forum software (like MyBB)? That would be pretty cool, IMO.

The only thing I had to do was modify the "smf_members" table, adding/mapping the `internalKey` column/values.

Provided MyBB will not BREAK as a result of said customization, I don’t see why not

@pixelchutes:
I think your event based function idea is golden!
I am 110% a fan of that.
Especially for events like `OnBeforeUpdateProfile` where you could manipulate the fields and send them back to WebLoginPE before they are stored in the DB. It is brilliant. I am not sure who came up with the concept in eForm (Raymond or JJ), but It bares repeating. It is brilliant.

-sD-
Dr. Scotty Delicious, Scientist DFPA.

Thanks for the GREAT Snippet!  I have uploaded the latest version 1.2.0.

I am having the following problems with the default install:

1) Any message to a member does not go thru to that member, yet when filling in the Subject and Message and Send button, it claims all went well? :

2) I get the following message when using this Register function:

"Could not instantiate mail function."

However the new user’s registration email does indeed go thru email, but the notify of the webmaster does not?

Both of these problems may be connected the email function?  Any ideas?
Thanks again for a great snippet.

UPDATED!!
I am now receiving all email messages mentioned above.  It seems my host has been doing some updates and placed all my messages in a que.  I have now received them 1 week later, lol!

One further note: When sending a message to a member thru the Contact box in the Profile Page:
1) The Subject and Message are not included in the email.
2) If not logged in, this script should include a FROM: email address?

Quote from: cobnet at Sep 06, 2007, 10:24 PM

Thanks for the GREAT Snippet! I have uploaded the latest version 1.2.0.

I am having the following problems with the default install:

1) Any message to a member does not go thru to that member, yet when filling in the Subject and Message and Send button, it claims all went well? :

Your message has been sent to "tester"

2) I get the following message when using this Register function:

[!WebLoginPE? &regType=`verify` &groups=`Registered Users` &notify=`[email protected]`!] 

"Could not instantiate mail function."

However the new user’s registration email does indeed go thru email, but the notify of the webmaster does not?

Both of these problems may be connected the email function? Any ideas?
Thanks again for a great snippet.

Hmmm. Interesting. Could be a SMTP issue on your server. I will look at the code for the sections you pointed out and see if I can figure out why they are behaving differently. Thank you for your review and the bug report. I appreciate the real-world tests.

-sD-
Dr. Scotty Delicious, Scientist DFPA.

Quote from: Dr. at Sep 06, 2007, 09:00 PM

@pixelchutes:
I think your event based function idea is golden!
I am 110% a fan of that.
Especially for events like `OnBeforeUpdateProfile` where you could manipulate the fields and send them back to WebLoginPE before they are stored in the DB. It is brilliant. I am not sure who came up with the concept in eForm (Raymond or JJ), but It bares repeating. It is brilliant.

Scratch that. I talked extensively with Jason on this subject tonight and he has me convinced that the best course of action is to invoke existing MODx system events wherever possible and create specific WLPE events as needed. Any custom code/function that you want to run on a particular event can be placed in a plugin bound to said event. I will most likely have an event for On and OnBefore each service that WLPE provides.

I know this might not be "exactly" what you were thinking, but it is the better, more compatible, more MODx option. I think you will find it so much more flexible than what we originally talked about (eForm style). you can have many, many plugins fire on the same event if you like. I will publish the public API for each system event. Non-standard MODx events will start at a number above 1100 and be automatically added if necessary (see the table `system_eventnames`).

Of course, this means I have to add yet ANOTHER page to my documentation! Arrrgggghhhh.

On a side note. Anyone want to be hired as my personal documentation secretary?

-sD-
Dr. Scotty Delicious, Scientist DFPA.

Quote from: Dr. at Sep 06, 2007, 11:45 PM

Scratch that. I talked extensively with Jason on this subject tonight and he has me convinced that the best course of action is to invoke existing MODx system events wherever possible and create specific WLPE events as needed. Any custom code/function that you want to run on a particular event can be placed in a plugin bound to said event. I will most likely have an event for On and OnBefore each service that WLPE provides.

I know this might not be "exactly" what you were thinking, but it is the better, more compatible, more MODx option. I think you will find it so much more flexible than what we originally talked about (eForm style). you can have many, many plugins fire on the same event if you like. I will publish the public API for each system event. Non-standard MODx events will start at a number above 1100 and be automatically added if necessary (see the table `system_eventnames`).

I agree with your points, and that it does make sense to tie with the system events. I’m all for it! It will be exciting to see it in action and play with the events this way...

Possible Bug for php4?

I am finding with the default settings I am having trouble with changing a user’s password in the profile page. I changed the template variable for the confirm.password to confirmpassword and it does indeed work now.

Original coding in the webloginpe.templates.php file:


Changed coding:


It now matches the coding in the webloginpe.class.php file:



I tried first off to change the coding in the class file to match the original template coding as such:

However this still would not change the password. I am not sure if php4 is actually reading the value of the password.confirm box, but it is reading the value of the passwordconfirm box?

One other note, the following coding in the class file in the Register function:



does not seem to be used anywhere in the class scripting?

Anyways, this seems simply to be the difference in using confirm.password and confirmpassword.

Quote from: cobnet at Sep 07, 2007, 03:13 PM

Possible Bug for php4?

I am finding with the default settings I am having trouble with changing a user’s password in the profile page.  I changed the template variable for the confirm.password to confirmpassword and it does indeed work now.

Original coding in the webloginpe.templates.php file:

<input id="wlpeUserProfilePasswordConfirm" type="password" name="password.confirm" />

Changed coding:

<input id="wlpeUserProfilePasswordConfirm" type="password" name="passwordconfirm" />

It now matches the coding in the webloginpe.class.php file:

		if (!empty($_POST['password']) && isset($_POST['password']) && isset($_POST['passwordconfirm']))
		{
			if ($_POST['password'] === $_POST['passwordconfirm'])
			{

A bug indeed!
Kudos, and thank you for the time you spent searching for a solution!

Quote from: cobnet at Sep 07, 2007, 03:13 PM

I tried first off to change the coding in the class file to match the original template coding as such:

		if (!empty($_POST['password']) && isset($_POST['password']) && isset($_POST['password.confirm']))
		{
			if ($_POST['password'] === $_POST['password.confirm'])
			{

However this still would not change the password.  I am not sure if php4 is actually reading the value of the password.confirm box, but it is reading the value of the passwordconfirm box?

Indeed. $_POST variables do not have a value for "."
When it is passed in a name, for example "password.confirm", the POST key is "password_confirm".
It is simply a convenience to use a period/dot for readability.
I have changed it to $field.’_confirm’ in the class.
Thank you again!
Quote from: cobnet at Sep 07, 2007, 03:13 PM

One other note, the following coding in the class file in the Register function:

		$passwordConfirm = $modx->db->escape($modx->stripTags($_POST['passwordconfirm']));

does not seem to be used anywhere in the class scripting?

LOL. that is legacy code from before I added custom table support where the only fields available were those in the "web_user_attributes" table. I have completely redesigned the Register and SaveUserProfile methods to be more efficient and to not overwrite unposted data in a form where a form field for each column is not provided.

Quote from: cobnet at Sep 07, 2007, 03:13 PM

Anyways, this seems simply to be the difference in using confirm.password and confirmpassword.

It will be fixed in the next version. Thanks.

-sD-
Dr. Scotty Delicious, Scientist.

Here is the Persian language file for WebLoginPE... It is in UTF-8 format. Thanks