Disappearing $_COOKIE question

Has anyone experienced changing or disappearing cookies?

I’ve come across an odd situation which has to do with cookies or the way different browser handles them. I am not sure.

1. If a user goes to the modx site http://www.medicinegarden.com.au/modx

2. then clicks any catalogue category and adds a product to the cart

3. then clicks "shipping & returns" -> the cart summary at the top of the page shows correctly

4. then clicks "about medicine garden" -> the cart summary shows no info, $_COOKIE is empty,

5. then if page is reloaded the cart summary shows up again.

I can replicate it many times in Opera by deleting cookies for the site, only once in firefox even if I delete the cookies for site. I am not sure how to delete cookies for a particular site in IE, so testing has been least with that browser.

All pages apart from "send message" all use the same template in MODx. It seems to affect new users to the site.

I can not seem to isolate where this might be occurring. There are other errors and I am thinking they also might be linked to the same problem as they seem to only affect the MODx version of the site, or where a user changes between the MODx area and the Catalogue/Shop area.

As mentioned in another post I have been setting the cartID cookie through a snippet, where as the catalogue/shop part of the site is not a part of MODx and sets/checks the cookie in exactly the same way just not through the MODx snippet .

One thing to consider with cookies is that they are only set on leaving the page and are read on entering the page. May not be related but this had me boggled a while back when I was messing with cookies.

I will keep your suggestion in mind. It may have something to do with the matter.

It does not explain the way it is affecting Opera compared with Firefox. Opera appears as though it is picking up a session that is either old or not the current session used by MODx.

The Opera experience appears to only be affected by the "About Medicine Garden" page. As I can go back and forth between the other pages and they show the correct cart summary. There are other problems once you click on the summary and try to go back to previous page using the "Continue Shopping" button, I am trying to solve one thing at a time.

The size of $_SESSION or $_COOKIE is also different between browsers. I have had someone else check with Firefox on a different system and they had the same problem only on the first entry to the site. After that details showed correctly inspite of the other bugs.

This may be obvious, but are you making sure to maintain the domain precisely? i.e. www.domain.tld vs. domain.tld ?

Another issue may be due to your hosting. If you’re hosted on load-balancing cluster servers, you may or may not get the same server on any given page request; if you happen to get a different server then the session file won’t be available, since it was saved on a different machine.

I’ve also found that cookies behave oddly if you’re in the Manager and switching back and forth between the Manager and the live site; I think it has to do with the page being loaded in the preview, then when you go to the front-end the cookies are duplicated, and I’m not sure how browsers handle that. I fixed that issue on one site by making sure my cookies had their path set to / and the domain set to ".domain.com" as well. Notice the . in front, that will take care of domain.com and www.domain.com.

I’ve had similar shopping cart weirdness on a server that was running the Apache mod_expires module. Adding "ExpiresActive Off" to my .htaccess file corrected the issue. Basically Apache was adding its own headers to all pages telling the browser not to request it again for five minutes, although the behavior wasn’t consistent enough to tip me off to this possibility at first.

The symptoms of mod_expires problems are somewhat distinctive in that a force refresh (F5) does update the page, but a regular page load often does not. So try that and see if the pages consistently update when you force refresh. Plus you can look at the headers and see the ones that Apache is adding, which would have an expiration date of 300 seconds or so.

If it’s not mod_expires it sounds like it could be some other cache-related issue, so see if you’re not doing something different vis-a-vis caching on that page.

I appreciate all the input. It gives me some direction. I will try all suggestions over the next few hours.

I didn’t spot the changes occurring in the URL. I will give an example.

If I type in [ http://www.medicine-garden.com.au/modx/ ] it becomes [ http://medicine-garden.com.au/modx/ ]. This is only if I try to access the modx folder. The changes also occur when some links are followed. In some cases it changes [ http://www.medicine-garden.com.au/modx/ ] to [ http://www.medicinegarden.com.au/modx/ ].

[www.medicinegarden.com.au] is the parked domain. I don’t know why it is switching domains.

Also now that I am looking at the urls/links the "About Medicine Garden" link does not point to [ index.php?id=2 ] it points to [ http://www.medicine-garden.com.au/modx/ ] . Which is strange because the "Latest News" link was the last page I added and I had to move the index on all the others. So maybe Wayfinder issue exists. I realize that in a previous version of Wayfinder it didn’t point to the home page like that it used to always use the index.php?id=## format.

I also notice that the SN********** number gets changed once throughout the original process I outlined and then when "About Medicine Garden" is clicked it is removed completely, almost like a new session. So why is this link causing such an issue with Wayfinder. The new way it works being a common element in this situation I am in.

I could be dealing with more than one issue, I may have misunderstood the situation. With your given advice I will go back to trying out some solutions.

The www and non-www urls are different sessions in your cookies, as MODx marks it’s session cookies with the absolute domain being accessed. Otherwise, it would have to create a session valid for any subdomain.

I suggest implementing a redirect (see the default .htaccess for an example) for any requests that do not have www to the www url, or just the opposite. Then you will be sure you are always accessing the same session, and also avoid having duplicate content indexed by the search engines.

Thanks for the suggestion. I will try to attempt that before anything else.

I should mention though that the issues I am getting on [medicinegarden.com.au] also apply on my development server which is plain localhost:8080.

Quote from: Tybek at Feb 26, 2008, 02:37 AM

Thanks for the suggestion. I will try to attempt that before anything else.

That should resolve this for you. A session set at www.yourdomain.com is not available at yourdomain.com. Just use .htaccess to force one or the other for every request.