How to return to product page after login?

I found it hard to believe this wasn't a default setting in ZenCart. It doesn't even seem to be an option in ZenCart. When a customer is viewing a product, and they click login so they can buy the product, I want them to be redirected back to the product page.

I have set up the site for my client to only show prices to logged-in, authorised, customers. This is because it is being used as a secure online ordering system for approved account customers only. Just giving his detail in case it affects the behaviour seen.

This is driving me crazy. I have done lots of searching, and found a handful of other people asking the same question, and found one or two posts saying, "You can do it, but it'll be hard..." but nothing that tells me HOW! Someone, please help me... this is getting urgent.

In the admin, what do you have under customer details in the configuration menu for customer shop status and customer approval status.

If you are not letting just anyone who has logged in shop, the system is not set to return them as they are not authorized.

If the settigs are, for example, 2 and 0 respecitively, the system should return them to the item. If they are waiting for authorization ( settings 2, 2), the system will not return them as they are not authorized to buy until someone authorizes them.

Not sure you'll be able to automate the process to the point of allowing the CORRECT customer to get to the prices without allowing just anyone who logs in to also get to pricing and shop.

If a customer is in checkout flow and needs to login, it does redirect them back to where they came from.
For non-checkout pages, it does not.

Are you concerned only about product pages at this point?
Which product-types are you using in your store?

dbabbage:

I have set up the site for my client to only show prices to logged-in, authorised, customers. This is because it is being used as a secure online ordering system for approved account customers only. Just giving his detail in case it affects the behaviour seen.

Is the customer sent to the site to be authorized or discovers the site and wants to be authorized? Not having prices shown would not generally be conducive to getting me in a buying mode.

If you create an account in advance for the customer, they will, as Dr Byte says, be able to do what you wish BUT (in my experience) they will still need to login before it happens due to the setup you've chosen.

The site is live. Feel free to visit at http://www.blick.co.nz

DrByte:

If a customer is in checkout flow and needs to login, it does redirect them back to where they came from.
For non-checkout pages, it does not.

Are you concerned only about product pages at this point?
Which product-types are you using in your store?
OK, this has clarified what is going on. On a development install I tried changing the store to displaying prices all the time so I could see how it would work in that scenario. Having done some testing, I now understand why there isn't the public outcry that I'd have expected there to be. If your store displays prices even when someone isn't logged in, and you can "Add to Cart", then people usually will do that. When they go into the checkout process, they are then seamlessly returned to where they'd expect to be.

My client's store is not an usual e-commerce site. Rather, it is an online ordering system for their approved account customers. For reasons based on a clear business rationale, they do not want to display prices on the site to non-approved customers. Currently, I have the site set up to just say "Login for price" next to the products themselves. The customer uses the "Log In" link on the navigation bar, as I've removed other Log In links from the page... there were just too many. (Perhaps this is where I went wrong.)

This might indicate a solution. If there was a "Buy Now" button next to a product, even without it displaying prices, could this somehow put them into the checkout flow and thus at least return them to a vaguely sensible location?

But what I really want, is that when someone clicks that "Log In" link on the navigation bar they are returned after log in to whatever page they clicked it from... whether it be a category listing, or an individual product page, or a EZ Page, or whatever. To me, this is the obvious and expected behaviour that a site user would expect... Can it be done?

dbltoe:

Is the customer sent to the site to be authorized or discovers the site and wants to be authorized? Not having prices shown would not generally be conducive to getting me in a buying mode.

If you create an account in advance for the customer, they will, as Dr Byte says, be able to do what you wish BUT (in my experience) they will still need to login before it happens due to the setup you've chosen.
As above, the client has a clear rationale and business plan about how they want to use the site. It is not intended to drive casual sales, but rather to support orders from account customers and to encourage new account customers. And I am talking about people who are already authorised customers who are returning to the store but who start browsing before they think to log in. We just don't want to annoy them every time they use the site. (It annoys us, so it will definitely annoy the customers.

DrByte:

Which product-types are you using in your store?
Sorry, forgot to answer this. The only product type is Product - General.

dbabbage:

But what I really want, is that when someone clicks that "Log In" link on the navigation bar they are returned after log in to whatever page they clicked it from... whether it be a category listing, or an individual product page, or a EZ Page, or whatever. To me, this is the obvious and expected behaviour that a site user would expect... Can it be done?

There are a number of places to make changes if you want it to happen "everywhere". I'm not so sure it's necessary to do it "everywhere", but the following will do it for your Product-General products. If you want to experiment with adding it elsewhere too, that's fine. However, the only place requiring login would be the product/category pages, the My Account areas, and the normal checkout flow. The My Account and Checkout and tell-a-friend and write-a-review already take care of it. A variation of this will be implemented in a future release. A number of authentication issues come to play in this with the many possible configurable modes in which Zen Cart can run. Consider this a fairly solid bandage:

/includes/modules/pages/product_info/header_php.php
Below this line:require(DIR_WS_MODULES . zen_get_module_directory('require_languages.php'));... add the following lines:```
if (!$_SESSION['customer_id']) {
$_SESSION['navigation']->set_snapshot();
}

The passion with which I now hold you in high regard is such that, on first reading this post, my mind briefly wandered to the possibility of bearing your children. :hug: Admittedly, I am male, and it is possible you are too, so this may not be physiologically possible. Perhaps we can settle for me saying THANK YOU THANK YOU THANK YOU. :clap: How could it be so simple and so fast? Works flawlessly... you've eliminated a huge headache :frusty: for me. Excellent. :smile:

Time to buy the Dr a cup of coffee. That's the best way to keep things going'.

http://www.zen-cart.com/index.php?main_page=infopages&pages_id=14

Hmm, something odd going on here. This works flawlessly on my offline install of Zen Cart, accessed with both Firefox and Safari. In the actual online store, now I've installed the files, it seems to work just fine in Firefox, but only works intermittently in Safari. I thought it worked once in Safari, but if you logged out and in again it then stopped working. However, quitting and restarting Safari doesn't always get it working again.

It seems like the code is searching for info attached to the Session ID. Presumably this problem might be about session IDs persisting after log out? Not sure why this would be different in my local and web installs—the Session ID settings in Admin are the same. Any clues, anyone?

The navigation system does in fact store its history in the active PHP session. If your live site is having session problems, you have more to worry about than merely navigation.

Is this only a problem with safari ? How about Opera or IE ?

It is working fine at all times in Firefox for Mac, Firefox for Windows, Internet Explorer 6 for Windows, and Internet Explorer 7 for Windows. It even works in Internet Explorer 5.2 for Mac (the final version before they discontinued it) although my stylesheet graphics don't load!

Offline, it works absolutely fine in Safari 2.0.4 for Macintosh, the current version. (There is a 3.0.x beta, but I'm not trying to get it to work on a beta...) Yet for some reason, on my live site it is only working very occasionally in Safari. Very odd...

ETA: I don't have Opera installed on my machine at present to test it there.

Ah, I should add, in case it was me that has broken something, that I added your code in four places in order to get the effects I wanted: into the header_php.php for product_info (for actual products), page (for ezpages), advanced_search_result (obviously, for search results) and index (seemed to be the one that made it work when you were mid-category hierarchy... so that if you were viewing a category that listed the products in the category that you were interested in, you could log in there).

That seemed to work fine, offline and in all those other browsers. But if it's me that's broken it... sorry! :blush:

dbabbage:

Offline, it works absolutely fine in Safari 2.0.4 for Macintosh, the current version. ... Yet for some reason, on my live site it is only working very occasionally in Safari. Very odd...Yes, very odd.
It's not a cache/cookie thing is it ? Does clearing all cookie/cache/history make any difference?

DrByte:

Yes, very odd.
It's not a cache/cookie thing is it ? Does clearing all cookie/cache/history make any difference?
Unfortunately no. I had tried this but double checked again to be sure and it has not fixed the problem.

I'm not sure if it is of any significance, but originally it was working intermittently for me. Of late, it has never worked in the online site in any of my tests. Not enough tests to be 100% sure this was a change—probably only logged in and out 15-20 times, but could be of significance?

Are you having problems with customers getting logged out or carts getting emptied while using safari?

I think it's down to an issue with server configuration ... perhaps PHP versions, PHP configurations, domain names, etc.

DrByte:

Are you having problems with customers getting logged out or carts getting emptied while using safari?

I think it's down to an issue with server configuration ... perhaps PHP versions, PHP configurations, domain names, etc.
The site has only recently been launched so we have limited information to go on. However, Safari was the primary browser used in all site testing, except for that specifically focussed on cross-browser compatibility issues. In that time we did not experience a single lost login, cart getting emptied, or order that could not be completed. This was also nearly all on the "live" server that is now causing this problem, since it was on a new domain and hidden behind a splash screen. The offline install was only established when the main site was officially launched.

Anyway, it's clear what we've identified is an interaction between Safari and some particular aspect of the install on that site. On my local install I am running PHP v4.4.6, on the live server it is PHP v4.4.7. (There is an option for PHP 5 but I have not enabled this.) Will see if can upgrade local install to v4.4.7 and whether that makes a difference.

Further testing: I made a complete backup of the live site MySQL database and the live Zen Cart installation. I recreated my local install, and performed the usual steps to move a Zen Cart installation to another server. I also imported the MySQL database content. This means my local install now contains exactly the content of the live site, in terms of admin settings, and modifications to Zen Cart files, and so on.

The redirect still works fine in Safari on the local server. This categorically demonstrates that it is a Safari-live server setup interaction, and has nothing specifically to do with the Zen Cart installation itself or any of my settings in admin. Hmm. So now to figure out what to do about this, given I have zero control over the version of PHP etc on the live server...

Next step, try different version of PHP locally, and see if that makes a difference.

Could it make any difference if sessions were being stored in the database locally, but in files on the live server? (How would I tell which option I selected for storing sessions on the live server?)

dbabbage:

Could it make any difference if sessions were being stored in the database locally, but in files on the live server? (How would I tell which option I selected for storing sessions on the live server?)

I doubt it's related to that.
Nevertheless, those settings are in your configure.php files.