[Done v1.3.7] account creation bug when displaying create-account-success page

mycolumbus:

Yours is a different problem so my fix will not correct the issue you are reporting.

You need to remove the array initialization code you've added since this is not a fix and concentrate on figuring out why the array is empty in the first place. It stands to reason that either the address book record is not being created as it should be or a session problem is causing the query to fail, for example if $_SESSION['customer_id'] is empty.

Since you are redirecting to the login page that would indicate the latter (no valid session) but I have no idea why.

Is this a fresh install? Have you changed or added any contribs?

Let me know and I will try to help.

Jeff

Thanks for your reply JeffD. Yes, this is a fresh install. You're right, it's a problem with the session because I can't even login as a user that's been created and exists in the database.

Time to go on the search again for my answer.

Thanks.

Fixed!

Sessions > Recreate Session set to false instead of true.

Great. Now I can get on with my job of customizing the store. Thanks everyone for your support.

That is very strange because it should work using the default setting for Recreate Session which is false.

Here are the session setting we are using:

Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session False
IP to Host Conversion Status true

I'm glad now it is working for you but you might want to look a bit further as to why you must have Recreate Session True as I don't really feel that should have fixed the problem.

Jeff

You misread my post. I have:

Recreate Session set to False.

My settings are exactly the same as yours. Cheers!

JeffD:

That is very strange because it should work using the default setting for Recreate Session which is false.

Here are the session setting we are using:

Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session False
IP to Host Conversion Status true

I'm glad now it is working for you but you might want to look a bit further as to why you must have Recreate Session True as I don't really feel that should have fixed the problem.

Jeff

It seems it did fix this problem. However, my default setting for Recreate Session was True.

Is that possible that this was changed to True when installing some contributions? I am worrying if this would deactivate some modules. Sorry if this is totally irrelavant. I know little about zenning!

I have the following modules installed: EP, google sitemapadmin, SEO, image handler2

Thanks!

mycolumbus:

Sorry, must not have had enough coffee that morning!

stargre:

We have updated our database many times over the years from version 1.14 and now up to the current version. We've never changed Recreate Session AFAIK so I think the default is false, however maybe one of the Dev team can comment on exactly what the current default configuration is for Recreate Session?

I'm not aware of any contribs that would change Recreate Session...

Glad it is working now for you both!

Jeff

Confirmed... I too am redirected poorly after creating an account during the checkout process. Seems like a perfect fit for my sessionWatcher contrib though... so I'll see if I can integrate that into it. Of course, its better if it just works properly fresh.

• Steven

Done! Contrib is now updated for this problem. I should clarify that it was actually introducing this issue independently as well, so thanks for helping me fix a bug I didn't know about. It now properly handles the situation where a customer creates an account during checkout.

• Steven

Steven:

Thanks for updating sessionWatcher to correct this issue! I have applied your latest changes since we use your contrib on our sites.

I want to clarify something however...

Everyone running 1.3.6 has this problem... yet they are likely unaware that it exists unless they happen to read this thread.

If someone applies the patch I posted earlier to overcome the checkout/create account redirect problem, will this affect sessionWatcher behavior in any way? In short, have you tested sessionWatcher in an installation using the previously proposed patch? and if so, are there any ramifications? Also, if they are using the latest version of sessionWatcher, do they also have to apply the previous patch?

I believe I know these answers but would appreciate your clarification!

Thanks,
Jeff

Okay, after some testing I will answer my own post...

To clarify this problem:

There is an issue with 1.3.6 whereby after new account creation during checkout, the customer is always redirected back to the create_account page rather than to the checkout_shipping page where they should go to complete the order process.

A quick fix for this issue was posted last Thursday here.

If you install the latest version of Steven's sessionWatcher contrib., he has modified it to do the same thing as the patch, so you don't have to apply the patch.

If you have already applied the patch it's okay as it will have no effect.

So to summarize, either install the sessionWatcher contrib. (this gets my my vote), or the patch or both to correct this issue.

Hope this helps!

Jeff

JeffD:

Okay, after some testing I will answer my own post...

To clarify this problem:

There is an issue with 1.3.6 whereby after new account creation during checkout, the customer is always redirected back to the create_account page rather than to the checkout_shipping page where they should go to complete the order process.

A quick fix for this issue was posted last Thursday here.

If you install the latest version of Steven's sessionWatcher contrib., he has modified it to do the same thing as the patch, so you don't have to apply the patch.

If you have already applied the patch it's okay as it will have no effect.

So to summarize, either install the sessionWatcher contrib. (this gets my my vote), or the patch or both to correct this issue.

Hope this helps!

Jeff

Hi! I may be missing something here. I didn't apply your patch, or the sessionwatch contribution. I just changed the value of recreatesessions to be false. It fixed the problem. So, maybe there will be some issue I didn't notice? Or do I still need to apply the contributions? Sorry, I am making myself seem even more ignorant.

First, this is a problem with 1.3.6 ONLY... If you have a previous version the problem does not apply!

If you wish to see this issue, follow these steps...

1. Visit your store as a new user.

2. Add something to the cart.

3. Checkout...

4. The cart will prompt you to login or create an account...

5. Choose create account, and submit your information.

6. You will be redirected to the account creation success page (assuming you entered vaild info)...

7. Click the continue button in the success page to witness the problem...

Instead of progressing to checkout_shipping you will be redirected back to the create_account page.

Hope this helps!

Jeff

Well now you have me doubting myself...

Are we SURE at this point, that this affects all 1.3.6 users, or is it my contrib that caused the problem in the first place?? I thought I tested on a fresh copy, but maybe I got mixed up... I didn't know you had SessionWatcher going too.

I don't want to install another fresh copy (too busy right now) so can someone WITHOUT sessionWatcher please follow Jeff's instructions and confirm the problem?

Thanks.

• Steven

Argh! I also had sessionWatcher running on our test site where I performed the testing when trying to help stargre and mycolumbus. Ajeh indicates that she cannot duplicate the problem on her test installation but is unsure that her code has not been modified beyond the as released 1.3.6.

Like you I really don't have time to do a clean install so I'm hoping someone (stargre?, mycolumbus?) with a clean install can confirm or deny this problem exists?

Thanks,
Jeff

hehe... that's funny :) So in other words, we managed to steer this thread completely off topic because the bug you and I are talking about may not have anything at all to do with the original problem. YOU STARTED IT!! :) It actually makes sense that sessionWatcher was the culprit. It creates a navigation history for any page that doesn't already have one. This particular case was caused because a navigation history is set on one page (by checkout) and forwarded to a new page (account creation)... but then instead of going directly back to checkout it goes to a THIRD page (account creation success) and sessionWatcher by that point was active again. I hadn't accounted for cases like this where there's a (useless?) intermediary step. Really though... what is the point of the success page? With or without my contrib, I would suggest that it would flow better if the customer was taken directly back to the checkout rather than having to hit "continue" to do so.

Sorry for inadvertently contributing to Jeff's inadvertent hijacking of this topic! You may now resume your normal bug.

• Steven

Really though... what is the point of the success page? With or without my contrib, I would suggest that it would flow better if the customer was taken directly back to the checkout rather than having to hit "continue" to do so.

Yes, and I believe that is the exact issue that put me off track since this is something newly added to Zencart. Originally after account creation older version of Zencart redirected back to checkout shipping page rather than having a continue button. I assumed (and probably incorrectly so now) that the culprit was in the addition of the success page and it's continue button.

Profusley apologizing now for that mistake! :lamo:

Jeff

What I saw with a clean install of 1.3.6 is that without changing the resetsessions value, this problem does happen every time. But after reset it, without applying either the patch mentioned earlier or the contribution, it worked fine. I am not good enough to make any conclusions. But that's what I can report.

The bypass of the create-account-success page has been built-in to v1.3.7.

Excellent!