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

[JeffD]

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

[mycolumbus]

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.

[mycolumbus]

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.

[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

[mycolumbus]

You misread my post. I have:

Recreate Session set to False.

My settings are exactly the same as yours. Cheers!

[stargre]

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!

[JeffD]

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

[s_mack]

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

[s_mack]

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

[JeffD]

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