Back Button Returning to Top of Product Listing Page, Not Previous Position!

I did some searches, came up empty. Forgive me if this was posted already!

So, when I click from the middle of the product listing page for a certain category into one of the products and click the 'Back' button (Firefox), I am always placed at the top of the product listing page instead of my previous position on the page.

At first, I thought this was an issue with the browser and nothing could be done to resolve it, but I noticed that whenever I hit "back" with Google search results, I return to the previous position on the results page.

Is there a way for me to return to the middle of the page with Zen Cart?

Thanks for your replies!:clap:

I suspect that Google is planting an anchor on every entry and then using that to link back to. Zen Cart doesn't have these embedded and indeed it would be more difficult to do so, since Google's pages are all basically of one type, whereas Zen Cart has many types and every page template would need to be edited to accommodate it.

I would like to figure out what would need to be changed in the ZC code (or if it is even anything to do with the code) to get Firefox to correctly Cache the Product Listing page. Problem is when using Firefox and you are viewing a product info page, then using the browser's back button, it always brings you to the top of the product listing page. This is not good if it is a long list. With IE it works fine and goes back to the scroll position of the list. So it looks like Firefox is always reloading the page and IE is pulling it from a Cache.

I know there is a bug with Firefox and has something to do with how the pages are being Cached. But there are many other eCommerce sites out there that do not have this problem with Firefox so they must have something set differently than ZC (Zen Cart).

Any ideas anybody?

I am using ZC 1.3.8a. Tested on both php4 & php5.

I'm not programmer enough to know if this is helpful, but it might give someone a clue:

http ://drupal.org/node/109941

Yes, same with me. But have done quite a bit of searching on this subject and it comes down to ZC sending the Browser a "cache control: no-cache" in a header "somewhere". There should be a way to change this but I have no idea where. If anybody would know, it would be DrByte since he coded most of the headers in the system that I have reviewed. If I use the Developer's Tool kit in the ZC admin and search for no-cache, it only shows:

/includes/modules/pages/download/header_php.php:
Line #118 : header("Cache-Control: no-cache, must-revalidate");
Line #119 : header("Pragma: no-cache");

admin/backup_mysql.php:
Line #198 : header("Pragma: no-cache");

admin/includes/classes/phplot.php:
Line #482 : header('Cache-Control: no-cache, must-revalidate');
Line #483 : header('Pragma: no-cache');

None of those three really look like they would have anything to do with the header.php that loads when a page that is on the "website" (store side) loads.

If I take a URL address of one of my product listing pages and run it in web-sniffer.net to view the header info, I get:

HTTP Request Header
Connect to 216.55.180.250 on port 80 ... ok

GET /store/index.php?main_page=index&page=2&cPath=1_35&sort=1d&perPage=10 HTTP/1.1[CRLF]
Host: https://www.postville.com[CRLF]
Connection: close[CRLF]
User-Agent: Web-sniffer/1.0.29 (+http://web-sniffer.net/)[CRLF]
Accept-Encoding: gzip[CRLF]
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7[CRLF]
Cache-Control: no[CRLF]
Accept-Language: de,en;q=0.7,en-us;q=0.3[CRLF]
Referer: http://web-sniffer.net/[CRLF]

HTTP Response Header
Name Value Delim
HTTP Status Code: HTTP/1.1 200 OK
Date: Fri, 26 Jun 2009 14:14:03 GMT
Server: Apache/1.3.41 (Unix)
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Encoding: gzip
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Vary: Accept-Encoding
X-Powered-By: PHP/5.2.6
Set-Cookie: zenid=n1mb3t7dflgm4spfrekspdhf75; path=/; domain=www.postville.com
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

Look at the items in bold. Now, that explains WHY Firefox will always go to the top of the page with the browser back button. But I want to know how to change those settings. I am sure there are 1000's of ZC users that would like to solve this problem now that FF is a dominant web browser on the market.

Maybe it is preset code in the mySQL database. But where? and what header.php file is pulling the data and then giving the browser the no-cache line?

Any Ideas anybody? We need an experienced ZC coder with very good caching knowledge.

Thanks, Bob

I have been working heavy on trying to figure this out and it has absolutely NOTHING to do with Anchors. It has only to do with the no-cache being sent from ZC.

We are still waiting for an answer from somebody higher up in the ZC team that proably already know how to change the cache setting but no replies as of yet.

A great tool to see what the header info is on pages is web-sniffer.net. Now look at a ZC page, any ZC site you can think of, you get in the HTTP resonse header:

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Now go to a site that will go back to the scroll position (in FireFox, using the browser back button):

try cnn.com
Cache-Control: max-age=60, private, private

try Google.com
Cache-Control: private

try ebay.com
Cache-Control: private

So the PROBLEM is the no-cache in the Zen Cart headers. The SOLUTION would be to change them to "private".

Now if somebody can explain how to change that, I believe the problem would be solved. ANY, thousands of ZC users and page designers will be very happy. Like me.

"Cache-control: no-cache" is defined to mean exactly the same thing as "Cache-control: private", but with no exception for user-agent caches.Source: http://www.w3.org/Protocols/HTTP/Issues/cache-private.html

Thanks for the lesson on Private vs. no-cache but we still do not have an answer to the problem. I wasn't trying to say the private setting would fix it but it seems to work for CNN, eBay, & Google so it would be well worth the try. The no-cache it spits out is definitely not working.

As per php.net:

session_cache_limiter() returns the name of the current cache limiter.

The cache limiter defines which cache control HTTP headers are sent to the client. These headers determine the rules by which the page content may be cached by the client and intermediate proxies. Setting the cache limiter to nocache disallows any client/proxy caching. A value of public permits caching by proxies and the client, whereas private disallows caching by proxies and permits the client to cache the contents.

In private mode, the Expire header sent to the client may cause confusion for some browsers, including Mozilla. You can avoid this problem by using private_no_expire mode. The Expire header is never sent to the client in this mode. "

Fact is, I need to know how to edit the cache header setting in ZC. I will experiment with it from there and when I come up with the correct cache settings I will let the ZC world know so we can get rid of this FF problem once and for all.

SOLVED!

bigbadbob was really close.

I discovered that the php function, session_start() will cause the web server to send 4 extra headers (among other things, of course). These headers are Cache-Control, Pragma, Expires in 1981, and Set-Cookie. Presumably, Zen Cart needs to call session_start, so the trick is getting session_start to not behave in this way.

That is where session_cache_limiter() comes in. Before zen cart calls session_start(), it needs to call session_cache_limiter(), otherwise it will use the PHP setting session.cache_limiter (not likely changeable by webmaster) or the default nocache.

Probably the best place to put the session_cache_limiter() command is at the end of configure.php. I think "private_no_expire" is a good setting for most sites.

So, to solve this problem, at the end of /includes/configure.php and /admin/includes/configure.php, put this line:
session_cache_limiter("private_no_expire");

However, this causes it's own problems. By allowing the browser to cache zen cart pages, it will look to the user like the shopping cart is not being properly updated.

For example, view an item, add item to cart, then view the item again. Your shopping cart, if viewable on the side, will say there are no items in the cart. If you refresh the browser, though, they will appear. Now view another item, and add it to your cart. You will jump to the cart page, but it appears that the item you just added is not there. Refresh your browser, and it will appear.

I will look into this further to see if there is a half-way solution without side effects. The main reason that I want to allow caching for my site is because my zen cart is so painfully slow. Sometimes loading a page takes more than 10 seconds, even after a fresh install with no items. Caching would help this somewhat.

There is a way to solve the original problem posted by beretta627 without allowing the browser to cache pages. To recap, the problem is that Firefox and Mozilla will reload the page when pressing the back button, and will always warp the scrollbar to the top of the page.

The problem is the Cache-Control header sent by php when calling session_start() is unnecessarily strict. It doesn't let the browser do anything, even store pages temporarily for the back button. Add the following line to index.php, after "require('includes/application_top.php');":

header("Cache-Control: no-cache");

This replaces the Cache-Control header set by session_start() with a Cache-Control setting that we can control. It allows the browser to store pages for the back button, but does not allow it to cache pages. If you would prefer a line that more closely resembles the default PHP one:

header("Cache-Control: no-cache, must-revalidate, post-check=0, pre-check=0");

I do not know what those other Cache-Control settings do.

If you want to prevent the bogus Expires header, set the session_cache_limiter to private_no_expire, as explained in my previous post. The cache will not actually be private if you set Cache-Control manually in index.php.