Internet Explorer redirects back to registration page when told to go elsewhere

First it creates the user, populates the fields in the tables, and goes to a "default" login template. After a few seconds it just falls out to the registration page they just left, instead of going to the page 63. Firefox does not have this issue.

The pertinent snippet call is:

I removed the custom table and required fields for brevity and security
The buttons on the template are:

<fieldset id="wlpeUserRegisterButtons">
<button type="submit" id="wlpeSaveRegisterButton" name="service" value="register">Register</button>
<button type="submit" id="wlpeCancelRegisterButton" name="service" value="cancel">Cancel</button>
</fieldset>


I dropped the fixed javascript over the old one located at /var/www/html/assets/snippets/webloginpe/js
I went as far as hard coding the js into the template used for the join page.

Still does not forward to the pages in the call.

I really hate IE.

After way to many hours I still have not come up with a fix. At this point it would be smarter for me not to not use Webloginpe for registrations. I could have made my own page, without any issue and feed both databases in thirty minutes, but I am to hard headed to quit.

I would much rather have used webloginpe to do this.

I renamed the webloginpe directory, uploaded a default bugged and unpatched 1.30 version, copied over the update Ie fix js and still I have the issue.

I also tried turning off mod secure. This had no affect. Turned mod secure back on.

No matter what I have tried the default wlpeLoginForm is loaded after the registration, and after the 3 second pause I get returned back to the registration page.

The issue seems to be that I end up at the wlpeLoginForm at all. The double redirect seems to be the problem. the snippet call asks for id 63 after success and I end up on 57, no matter what. My thinking would be that I should go directly to the redirect page once the information is saved to the databases, and the email is sent.

I even tried taking the content from the redirect page I need the page to go to and placing it there. No go on that also. I never even saw my page. It just loads the wlpeLoginForm.

I also see another thing wierd. The wlpeLoginForm has the action set to * (self) in the template but it is actually pulling the id (name) of the previous page (the registration form) and putting it in. Explorer sits at the load sequence for the three seconds and then I am back to the registration page with the account created.

I got it fixed: I got rid of the default templates, and replaced them with chucks.

The advantage of this is that when a chunk is called for the success the same page is going to be reloaded anyway. If you get bounced back (or purposely sent) to a given page then the chunk shows instead of the form which sent you.

Call:



Apparently, I had forgotten than even in my own database calls I typically send them back to the same page.

The actually code in the background causing a double redirect with my previous call has not been looked at.

Shawn,

I came up the same solution to my problem (to use chunks instead of the default forms); it was annoying as heck, but the registerSuccessTpl is not my problem anymore, its getting bounced BACK to the original registration form that is the problem. (IE never goes to my regSucessID!)

So basically, after clicking on register, the unavoidable registerSucessTpl screen comes up, I set the delay for 3 seconds, then it bounces back to the registration form with the account created. Any advice on how to get IE (the most annoying browser on earth) to redirect me to ANY OTHER PAGE than back to the registration form?

Suddenly, I find myself having the same problem. I fill out the registration form, the account gets registered, but I’m bounced back to a blank registration form instead of the page I specified in the call. Again, this is IE 6 only. I haven’t tried IE7 (and I don’t mess with IE5 anymore).

I believe that there was some discussion of the type of redirect WebLoginPE uses; there’s a couple of places in the code where the type was changed but I don’t remember exactly what, or it that was for this particular problem. Search for REDIRECT_REFRESH and you should find something.

Quote from: sottwell at Feb 12, 2008, 10:47 AM

I believe that there was some discussion of the type of redirect WebLoginPE uses; there’s a couple of places in the code where the type was changed but I don’t remember exactly what, or it that was for this particular problem. Search for REDIRECT_REFRESH and you should find something.

Susan, thanks for the response; I know exactly what you are referring to; changing the Redirect_Refresh to Redirect_Header at certain places in the snippet; but I tried actually changing all the Redirect_Refresh’s to Redirect_header’s and the problem still persists. (Or maybe I missed something?) This problem is rather annoying....anyone have any insights on this? Is it DEFINITELY a redirect_header vs. Redirect_refresh issue?

I actually converted all such instances of REDIRECT_REFRESH to REDIRECT_HEADER (<a href="http://modxcms.com/forums/index.php/topic,19462.msg137307.html#msg137307">see this post</a> for how to do it in the class file and the snippet). That definitely fixed the ’flashing content’ problem when logging in. However, this new problem exists on the registration page, and changing the redirects hasn’t seemed to help.

Quote from: willc at Feb 12, 2008, 01:34 PM

I actually converted all such instances of REDIRECT_REFRESH to REDIRECT_HEADER (<a href="http://modxcms.com/forums/index.php/topic,19462.msg137307.html#msg137307">see this post</a> for how to do it in the class file and the snippet). That definitely fixed the ’flashing content’ problem when logging in. However, this new problem exists on the registration page, and changing the redirects hasn’t seemed to help.

Right, exactly. I’m surprised more users have not been affected by this problem; there’s an odd silence on this issue, I guess because people have found their own hacks or the Redirect_header did the trick for them; in which case, I don’t see why it’s not working for us also.