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

[beretta627]

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!

[kuroi]

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.

[bigbadbob]

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.

[bigbadbob]

Anybody out there on this?

[stevesh]

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

http ://drupal.org/node/109941

[bigbadbob]

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: 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

[bigbadbob]

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.

[kuroi]

"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/Iss...e-private.html

[Kim]

Moderator's note: Threads on the same topic have been merged together.

[bigbadbob]

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.