How do I prevent the zenid from being added to URLs on the initial vist (v1.3.7)?

The "/cache/" folder is often where session data is also stored. As such the usual recommendation is to make that folder writable with 777 permissions. Some hosting companies allow (some even require) that to be set to 755 and still work.

However, as mprough has indicated, the first visit to the site will almost always show the zenid in the URL ... but the very next click on that page will drop the zenid, and it will be gone again until it is needed (ie: login, etc), and then disappear again if possible.

It's basically the way PHP session handling works. There have been many attempts to alter that behavior, with varying degrees of success and failure. Not every server can do it right, and most of the cases I've seen trying to override the way it works end up complaining that their customers can't complete checkout or can't login ... and of course that results in lost sales.

So, should I keep it at 755 or change it to 777? I'm a little confused which is best.

Thanks Dr. Byte!

rebekah:

So, should I keep it at 755 or change it to 777? I'm a little confused which is best.

Thanks Dr. Byte!
If it is working at 755, keep it at is. If not, change to 777 :)

Anything wrong with this in application_top.php? Orders post successfully. Seems to work great.

if($_GET['zenid']){
    $qs=str_replace('&zenid='.$_GET['zenid'], '', $_SERVER['QUERY_STRING']);
    $qs=$qs?'?'.$qs:'';
    if($qs){
        header('location: '.$_SERVER['PHP_SELF'].$qs);
    }
}

rebekah:

So, should I keep it at 755 or change it to 777? I'm a little confused which is best.

with the security on the server you will NEVER set a folder to 777
its not needed outside global write access is never needed

if suPHP or similar is not installed on your server, you'll need to change the group to "nobody" and the permissions to "775". That's the only way to make it writable in this environment without setting it to 777.

In my Admin/Configuration/Sessions setting should '/home/www/cache' be entered with or without a trailing slash?

Without.

sitehatchery:

if suPHP or similar is not installed on your server, you'll need to change the group to "nobody" and the permissions to "775". That's the only way to make it writable in this environment without setting it to 777.
That is incorrect.

One would do the above if PHP is run under Apache and can only be done through SHELL; which most people do not have access to.

If PHP is run as CGI, using suPHP for example, then you need set dir. permissions to 755.

Thx WR !

Hi

Been looking into this problem... Can I just confirm the conclusion is there is no way to remove the zenid variable from the URL on the first visit to the site? The links in the categories do not look very good for a visitor. I have not seen this behaviour on other systems that use sessions so do not understand why it is needed for Zencart.

Thanks

while i dont know why it uses it (im not a coder) i have asked the same question in the past...

i believe you cannot remove it, but you can rename the ZENID to something else... if you really feel the need to.

I know it doesnt appear in other cart systems, so all i can say it.. each is designed and built different...

the only tim ei had google indexing the zenid was when i made a mistake in my configure.php file...

cant remember exactly now, as it was about 1 yr ago but i had the SSL part or my site with 'www.' and the none SSL part of the site without... if that's reason why i dont know but the zenid stopped getting indexed about a month after the change

Hi,

infocom:

Been looking into this problem... Can I just confirm the conclusion is there is no way to remove the zenid variable from the URL on the first visit to the site? The links in the categories do not look very good for a visitor.

In Admin click on the Configuration menu then select Sessions. From there set 'Force Cookie Use' to 'True'. You should then not see zenid on any links at any time. The downside is that your site won't work for people who have cookies disabled.

infocom:

I have not seen this behaviour on other systems that use sessions so do not understand why it is needed for Zencart.
Zen Cart uses the zenid in the URL so that sessions will work for people who do not accept cookies. Once Zen Cart detects that the visitor has cookies enabled it switches to using a cookie for session tracking and stops using the zenid in the URL. It takes a couple of page views to do this check.

Regards,
Christian.

That is interesting and was not explained to me before when i asked about the zenid bit.

I am not a programmer but would it therefore be possible for the OP to change the code a little bit to make his ZC store use cookies first, avoiding the appearance of the 'zenid' and if no cookies are detected then revert using the zenid session thing?

Or is this not easily done within the ZC structure, hence it has not been done before or a mod available to do this???

It is complicated to do on a 1.3.x site. Many folks have posted their different twists and ideas on this, and have met with mediocre results depending on various hosting configurations, etc. Some have unfortunately broken their site when doing it, and lost business.

However, we're hoping to include working code in v2.0 so that zenid's will not show in URLs unless there's no other way. It's looking promising thus far.

Okay, I need some clarity here. Are all the comments posted here only applicable to 1.3.7 or do they also apply to 1.3.8 and 9?

Normally the zenid doesn't show - my understanding is that's it's not supposed to.

But I'm working on a cart now that was upgraded to 1.3.9 on a godaddy server (I know - told them to move it) and those pesky zenid's are showing everywhere. I also moved the site from a subfolder to the root. I've done this many times before and am looking at an entirely new situation for some reason.

I know godaddy requires weird permission sets but nothing I've tried has worked.

It's possible that I have a setting wrong somewhere but when you try to access the account page or shopping cart, it all dies.

The error message is:

[21-Aug-2010 06:05:20] PHP Warning: session_start() [<a href='function.session-start'>function.session-start</a>]: Cannot send session cookie - headers already sent by (output started at /home/content/n/l/e/nleig2/html/includes/configure.php:137) in /home/content/n/l/e/nleig2/html/includes/functions/sessions.php on line 114

So is it settings in configure.php or in admin (sessions configs are all still default settings) or cache permissions? Or something else at work.

Have you tried fix cache key? http://www.zen-cart.com/index.php?main_page=product_contrib_info&products_id=82

zenids will show up when the browser prevents the store from setting a recognizable session cookie, or if the server has session problems, either due to misconfiguration, unwritable folders, domain configuration errors, etc.

Plus, you reported a "headers already sent" error message occurring on line 137 of your configure.php file. It's the most popular FAQ entry: https://www.zen-cart.com/tutorials/index.php?article=87

Also, after upgrading, and especially after moving between servers or relocating to different folders on the same server, you should always flush your browser's cache and cookies.

Yep, did all that - what I hadn't done was delete the folder that had the old site in it. I am using the same database for both. Then I ran the fix cache key again (said no change) and now the site is working.

I still have the zenid showing but at least I know it's not my site changes that is causing it. Godaddy and permissions again, I'm pretty sure at this point. Site owner is young and stubborn. The site actually went down for hours Friday and he still doesn't see the need to move it to new hosting.

Thanks so much for your help, Dr.Byte, once again!

well, the problem reappeared immediately. No one else even witnessed that it worked.

I uploaded the database and theme files to my hosting instead and the issue doesn't exist there. No zenid's attached to start with to any links.

Also, if the shopping cart is empty, it displays. It's only when you try to add to the cart, the problem appears.

It's been obvious to me all along that it was a server related issue - and probably has to do with permissions.

However, this was installed thru Godaddy's application program so I would have thought the permissions would be okay. I never am sure what permissions are supposed to be with them - seems to change from client to client.

All I did with the configure file was to change the paths for the cart since I moved it from a subdirectory to the root.