WebLoginPE 1.3.0 Bug Reports

28 Posts

elander Reply #111, 18 years, 9 months ago

I can’t login with FireFox 2.0.0.11.

I checked to see if the $_POST array got there OK, as someone earlier mentioned it didn’t, but it does. The user name and the password get to the server and they are in the right places in the array. But I’m not getting logged in.

It works like a charm in Safari, but nothing happens in FF.

In Safari I notice that when the form has been submitted and the page reappears, it immediately reloads at least once, maybe even twice, before I get logged in, and after the last reload the $_POST is empty again.

In FF, when the form is submitted, the page doesn’t reload, it just sits there with a populated $_POST.

Could that be it? That FF doesn’t reload correctly?

EDIT: I checked to see if disabling the ieButton.js would work, and it does. Seems to be something wrong with the JS, I’ll look into it later, but I’m good for now; my client doesn’t use Windows, only Mac OS X (thank God!).

/elander
http://scribus.se

114 Posts

enidan Reply #112, 18 years, 9 months ago

Quote from: elander at Jan 14, 2008, 12:22 PM

EDIT: I checked to see if disabling the ieButton.js would work, and it does. Seems to be something wrong with the JS, I’ll look into it later, but I’m good for now; my client doesn’t use Windows, only Mac OS X (thank God!).

A bug fix has been proposed in this post (http://modxcms.com/forums/index.php/topic,19428.msg120969.html#msg120969) to load the JS stuff only if browser is IE:

function isIE() {
  return /msie/i.test(navigator.userAgent) && !/opera/i.test(navigator.userAgent);
}
if (isIE()) {
 /* Put current "ieButton.js" file contents here*/
}

Site web: http://www.nlkdev.com
Addons MODx: SWFObject - Update de ManagerLogin

28 Posts

elander Reply #113, 18 years, 9 months ago

Bug in the sorting algorithm!

if you’ve disabled registering, which I had to since my client wants to add members manually, you have to add new members throught the regular manager.

If you use extended attributes, they can’t be edited or added in the manager, so you need to do that through WebLoginPE’s manager function. But that won’t work if you sort the list of users using some of the extended attributes, because the sorting doesn’t degrade gracefully, it just halts everything and you can’t see anything on you manager page.

The only solution is to remove the sorting on your manager page and that is a pain in the butt, since it makes editing old entries a lot more work than should be necessary.

You could of course use two manager pages: one unsorted for new members (they always float to the top), and one sorted for the old ones. As long as you remember to add the extended attributes everytime you add members, especially if you show a sorted list to other non-administrators...

/elander
http://scribus.se

7 Posts

daystarjustice Reply #114, 18 years, 8 months ago

Quote from: Dr. at Nov 10, 2007, 07:22 PM

Did you add your name to the credits?
If not, just post them here and I will get your zip up as 1.3.1

Thanks for putting that together. My free time has been non-existent lately.

-sD-
Dr. Scotty Delicious, DFPA.

Any word on posting a WebloginPE 1.3.1 with the current fixes? A couple of you were talking about possibly putting that together. Is somebody planning on doing that?? It will save many of us countless more hours of debugging little things one bug at a time by searching the forums.

Amazing work I would like to add. It would take me years to learn to hand code a snippet like this. That’s what Modx is all about!!

925 Posts

Soshite Reply #115, 18 years, 8 months ago

I think I might have noticed a HUGE bug in the Registration area of WLPE.

In my install (which worked perfectly before), it’s now giving a "____ already exists!" when a user tries to register, even is said field doesn’t match anything. And the usergroup setting isn’t being made, either.

Only thing I can imagine is that 0.9.6.1 or 0.9.6.2 borked something inside WLPE. I’m gonna install a "fresh" copy of the files, just in case one of the bugfixes I made manually caused this issue.

EDIT: Just uploaded fresh versions of the script. Both issues persisted with the default 1.3.0 files (only changed a few lines unrelated to those issues --- had to w/ how WLPE loaded the language files).

EDIT2: Seems new users are having their last login set to 31-12-69 19:00:00...

My Snippets
-> PopUpChunk v1.0

11 Posts

gaffinet Reply #116, 18 years, 8 months ago

I don’t know if this bug is already reported, I didn’t found something the the forum:

When sending notification mail to the administrator, the [+post.####+] weren’t replace properly! You find the code at about line 700

Orginial Code

...
$notification = str_replace('[+uem+]', $email, $notification);
foreach ($_POST as $name => $value)
{
	$toReplace = '[+post.'.$name.'+]';
	$message = str_replace($toReplace, $value, $notification);
}
...

Solution

...
$notification = str_replace('[+uem+]', $email, $notification);
foreach ($_POST as $name => $value)
{
	$toReplace = '[+post.'.$name.'+]';
	$notification = str_replace($toReplace, $value, $notification);
}
...

the result of str_replace were stored in the wrong variable. I simply changes the $message to $notification.

Yves

925 Posts

Soshite Reply #117, 18 years, 8 months ago

How odd...that bug I talked about in my last post is a weird one --- let’s say I remove the username checking code in the class file. Then it jumps to saying the e-mail is already in use (even when putting in crap that’s not an e-mail address).

Now, when I remove both the username and e-mail address checking, it gives this parse error...any idea what it means?

« MODx Parse Error »MODx encountered the following error while attempting to parse the requested resource:
« Execution of a query to the database failed - Duplicate entry ’Wilhelm’ for key 2 »
SQL: INSERT INTO `symphon_cms`.`modx_web_users` (`username`, `password`, `cachepwd`) VALUES (’Wilhelm’, ’XXX’, ’XXX’)
[Copy SQL to ClipBoard]

Parser timing
MySQL: 0.0168 s (18 Requests)
PHP: 0.5884 s
Total: 0.6052 s

Obviously, two of those fields were remove for security purposes.

In any case, this is a bad bug, since it’s getting errors, but data is still being created (instead of being destroyed when it encounters a bug). Something’s acting up before WLPE can apply the usergroup setting, so that at least centers the search for the "bad code" to a few areas.

EDIT: After testing, applying the usergroup has the account work as expected. So the issue lies in the new user registration solely...

EDIT 2: Hmm...I just noticed that that WLPE "stops" when it reaches the attributes_extended table, aka the special table that Scotty uses for custom fields. I wonder if there’s an issue if WLPE encounters a custom variable that isn’t checed (such as emailprivate) --- so it doesn’t know what to do when it reaches the "create data for custom fields" part of the code...

My Snippets
-> PopUpChunk v1.0

5,888 Posts

Bruno17 Reply #118, 18 years, 8 months ago

I’m not sure if this is me or WeboginPE...my guess is me.

If you login as a manager and from the managerList of people you edit someone else’s profile, the inputHandlers generated by WebLoginPE set their values according to the user viewing as opposed to the user whose profile I am editing. Making any changes to these fields populates the database correctly however.

Is there something I am doing wrong?

Thanks for any pointers!

Taff

in the snippet webloginPE change all

$wlpe->ViewUserProfile($_REQUEST['username']);

to:

$wlpe->ViewUserProfile($_REQUEST['username'],$inputHandler);

in webloginpe.class.php change

function ViewUserProfile($username)

to

function ViewUserProfile($username,$inputHandler)

and it works for me.

-------------------------------

you can buy me a beer, if you like MIGX

http://webcmsolutions.de/migx.html

Thanks!

7 Posts

menyx Reply #119, 18 years, 7 months ago

Some flaws I have found :

■ in defaultProfileTpl :
<input id="wlpeUserProfilePasswordConfirm" type="password" name="password.confirm" value="" />
SHOULD BE
<input id="wlpeUserProfilePasswordConfirm" type="password" name="passwordconfirm" value="" />

■ in defaultActivationTpl :
<input type="password" id="wlpeNewPasswordConfirm" name="newpassword.confirm" />
SHOULD BE
<input type="password" id="wlpeNewPasswordConfirm" name="newpasswordconfirm" />

■ in the Documentation/Parameters :
&loginHomeId SHOUD BE &liHomeId
&logoutHomeId SHOUD BE &loHomeId

■ Despite the fact that it’s told in the documentation, I think it would be a good idea to include
some [+wlpe.message+] in the example templates (Register, Profile, ...)

■ Some inputs in the default templates miss the value="[+post.something+]" (for value remembering on form error)

■ The new-password activation form is a bit buggy : if submitted informations are wrong it still redirects the user on the loginTpl page. A modification suggestion :

			case 'activated':
				$activated = $wlpe->ActivateUser();
				
				if ($activated == 'success')
				{
					return $displayLoginFormTpl;
				}
				else
				{
				  return $displayActivateTpl;  
				}
				break;

■ I had problems with accents in notification emails. I modified webloginpe.class.php :

$Register->FromName = utf8_decode( $fullname );
$Register->Subject = utf8_decode( $emailSubject );
$Register->Body = utf8_decode( $message );

... and for other emails sent.

Best regards.

55 Posts

jdelight Reply #120, 18 years, 7 months ago

As there’s no way of knowing if a message is positive or negative (error message) I added some html to the text in the lang file

<div class="error-msg">Your password is incorrect...</div>

The only problem with this is pixelchutes fix (see page 1 of this thread) for if the user enters a bad activation code or password error which now needs a strip_tags() around the message so it doesn’t think "/d" is a modifier. This threw up a horrible modx error based on the document parser trying to eval() the snippet!
Here’s the code I’ve used.

			
case 'activated':
                if (in_array('activated', $disableServices)){return;}
                $wlpe->ActivateUser();
                // pixelchutes 1:57 AM 9/19/2007
                // Here we check for an error, then reload the activation template if necessary
                // Do NOT reload if wlpe->Report indicates success
                // jdelight 5:18 AM 6/03/2008
                // Added strip_tags() around string which means an error is not thrown regarding a modifier from closing
                // html tag e.g. if $wlpe_lang[104] contains "</div>" this will fail as "/d" treated as modifier
                 if ( isset( $wlpe->Report ) && !preg_match( "/".strip_tags($wlpe_lang[104])."/i", $wlpe->Report ) )
                {
                    return $displayActivateTpl;
                }                
                return $displayLoginFormTpl;
                break;