wilt:

k, could you also try this as a potential fix

in the extra_configures directory,
create a file called override_cookie_path.php
that contains

numinix:

Are others who are experiencing this problem also using Simple SEO URLs or some other SEO URLs script? Does disabling the script help?

Hi, I use CEON's URL add-on, on a 1.3.9d site.. so far no one has reported issues like the one you are experiencing nor can i seem to be able to recreate the problem... (thankfully)

I expect if you had old cookies that it may interfere with the fix.

Note. I've only been able to reproduce this using Safari 5 on mac. I cannot reproduce the problem on my normal linux/firefox setup.

So the problem appears to be browser based, and not necessarily tied to SSU.

wilt:

I expect if you had old cookies that it may interfere with the fix.

Note. I've only been able to reproduce this using Safari 5 on mac. I cannot reproduce the problem on my normal linux/firefox setup.

So the problem appears to be browser based, and not necessarily tied to SSU.
For me it happened with Firefox on PC. With others it was Google Chrome on PC. It doesn't seem to be consistent.

k,

A little more digging suggests this may be a mod_rewrite problem.

Would u be willing to share that rule you are using to remove the index.php from the URI.

(By PM if you want.)

wilt:

k,

A little more digging suggests this may be a mod_rewrite problem.

Would u be willing to share that rule you are using to remove the index.php from the URI.

(By PM if you want.)
I can show you the htaccess file here:

BOF SSU

#Options +FollowSymLinks
RewriteEngine On

Change "/zencart/ to the correct setting

if your site is located at root folder, then you should have RewriteBase /

Go to your include/configure.php, this value should be the same with the value of DIR_WS_CATALOG

RewriteBase /store/

Deny access from .htaccess

RewriteRule ^.htaccess$ - [F]

RewriteCond %{SCRIPT_FILENAME} -f [OR]
RewriteCond %{SCRIPT_FILENAME} -d
RewriteRule .* - [L]

RewriteRule ^(.+) index.php/$1 [E=VAR1:$1,QSA,L]

EOF SSU

k,

Can you try changing

RewriteRule ^(.+) index.php/$1 [E=VAR1:$1,QSA,L]

to

RewriteRule ^(.+) index.php/$1 [E=VAR1:$1,QSA,L,PT]

Note. to test this you will also have to remove the
fix I gave earlier.

I resorted to the paypal button because the zen button wasn't appearing.. how do I delete the paypal button and get the zen button to work? because the zen button never worked..

I think this conversation has gone way off the original topic of problems getting products to get into the shopping cart when clicking the add-to-cart button.

wilt:

k,

Can you try changing

RewriteRule ^(.+) index.php/$1 [E=VAR1:$1,QSA,L]

> 
> ```php
RewriteRule ^(.+) index.php/$1 [E=VAR1:$1,QSA,L,PT]
```Note. to test this you will also have to remove the 
> fix I gave earlier.
Wilt, I haven't tried this because the issue is no longer being reported by customers.

Here is a recap of everything I have done.  I can't say which individual thing could be the SOLUTION:


1. applied the cache fix (did nothing since the cache path was already correct and we use the database method in configure.php).
2. Upgraded Simple SEO URLs (made sure to clear the SSU cache AFTER upgrading)
3. Fixed a bug in /includes/init_includes/init_sessions.php
4. Uploaded a file called override_cookie_path.php with the cookie path definition.
5. cleared the browser's cache and cookies created in the last day.
Remember, a combination of these solutions was used and not until all of them were implemented was the solution resolved.

Hi,

I quite understand that now you have things working that you don't want to mess around too much with a live store.

recap from my point of view.

The bug seems to be caused by $_SERVER['SCRIPT_NAME'] being set incorrectly based on some URLS generated by SSU.

The $_SERVER['SCRIPT_NAME'] is used to set the cookie path, so if it is set incorrectly, then it will generate multiple cookies and cause Zen Cart to lose session.

The temporary fix is to use a custom override to always set the cookie path to the root directory.

However, it is my belief that the real culprit here is a bug (reported on both PHP and apache forums) that stems from a mod_rewrite that causes some environment variables (such as SCRIPT_NAME to be incorrectly set.

The workaround suggested by apache/php is to set the pass-through flag on mod_rewrite.

As such this is NOT a Zen Cart bug.

although we are happy to help :D

wilt:

Hi,

I quite understand that now you have things working that you don't want to mess around too much with a live store.

recap from my point of view.

The bug seems to be caused by $_SERVER['SCRIPT_NAME'] being set incorrectly based on some URLS generated by SSU.

The $_SERVER['SCRIPT_NAME'] is used to set the cookie path, so if it is set incorrectly, then it will generate multiple cookies and cause Zen Cart to lose session.

The temporary fix is to use a custom override to always set the cookie path to the root directory.

However, it is my belief that the real culprit here is a bug (reported on both PHP and apache forums) that stems from a mod_rewrite that causes some environment variables (such as SCRIPT_NAME to be incorrectly set.

The workaround suggested by apache/php is to set the pass-through flag on mod_rewrite.

As such this is NOT a Zen Cart bug.

although we are happy to help :D
Can you provide a link to that workaround? Why was it not happening before we upgraded to 1.3.9d?

Hi,

The workaround was the change I suggested to the mod_rewrite rule

RewriteRule ^(.+) index.php/$1 [E=VAR1:$1,QSA,L,PT]  

The reason that the problem only started to appear in the later 1.3.9 branches is that previously Zen Cart always set the cookie path to the root folder.

This was changed to use $_SERVER['SCRIPT_NAME'] to determine the actual folder that cookies should be stored to.

The idea behind all of the changes to how cookies were stored was to be more compatible with cookie RFC's and increase cross browser compatibility.

I said earlier in this topic that I solved the problem temporarily by adding &zenid to my home links.

The problem is that Zen-Cart generates new session every time you go back to the home page, for example myshop.com. If link is something like myshop.com/index.php... everything works just fine with sessions and Zen-Cart won't generate new session. Site seems to generate automatically &zenid to the end of URL although it wouldn't need it.

I have my Zen-Cart installation in mydomain.com/myshop/ and I have modded .htaccess to redirect myshop.com to that folder so I have my shop at myshop.com. Here's my .htaccess:

RewriteEngine on
RewriteCond %{HTTP_HOST} myshop.com
RewriteCond %{REQUEST_URI} !^/myshop
RewriteRule ^(.*)$ myshop/$1 [L]

If I set HTTP_SERVER to 'mydomain.com' and DIR_WS_CATALOG to '/myshop/' it's working without loosing sessions. However, if I make redirect with .htaccess file and I set HTTP_SERVER to 'myshop.com' and DIR_WS_CATALOG to '/' it's loosing sessions. That's happening when link is pointing to HTTP_SERVER . DIR_WS_CATALOG.

I think this has something to do with this redirecting and the $_SERVER['SCRIPT_NAME'] bug wilt described above.

What do I have to do to make my site's sessions work?

Sorry for my English, I hope you understand what I mean :)

Can you try changing

RewriteRule ^(.*)$ myshop/$1 [L]

to

RewriteRule ^(.*)$ myshop/$1 [L,PT]

That didn't work but I solved my problem myself.

I have my installation at Apache server, Cpanel enabled. Myshop.com was installed as parked domain but I changed it to add-on domain. This solved my problem and Zen-Cart won't lose sessions anymore.

That explains it. A parked domain doesn't work the same as a live domain. The cookies it sets would be for the actual live domain in the account where it was parked. Thus no session operations would ever work. In short: don't do that :blush:

I thought something like this.

I noticed that when I took copy of my db and made fresh install to another subdirectory. I used that with and without mydomain2.com and noticed difference.

I spent hours and hours with this and fix took only two minutes :S