I moved my website from Bluehost to Linode, and everything's working well... well, almost.

I must shamefacedly confess to bad programming practice, as I have one page write a cookie and the form handler (a separate PHP file) then reads that cookie. Don't ask me why I am doing this (well, you really should, to expose me for the hack that I am... maybe I will learn something here.

Finally, I narrowed it down in the debugger to when I set the document.cookie object using JavaScript. On the working site (Bluehost), document.cookie gets set to the cookie value. On my Linode environment, using the LAMP stack, it does not. Aargh. FWIW, here's the code:

function formSetCookie(c_name,value,expiredays)
{
var exdate=new Date();
//var sNewVal = value.replace(/ /g,"+");

exdate.setDate(exdate.getDate()+expiredays);
document.cookie=c_name+ "=" +escape(value)+
((expiredays==null) ? "" : "; expires="+exdate.toGMTString()) +
"; path=/; domain=worldbento.com";
}

Should path be "/" or something else?

Any ideas appreciated, folks. I am real excited about Linode, but just want my site to migrate seamlessly.

Vik

You've specified the domain in your cookie as "worldbento.com", which means that if the URL you're on doesn't begin with http://worldbento.com/, the cookie can't be read. Unless you require it to be on a specific domain, you don't need to set the domain for a cookie, which means that it will be set to whichever domain you're already on (ie. based on the current web page URL).

That's a reasonable suggestion. However, the domain is "worldbento.com", and the cookie is not being written in the first place. Is there a configuration setting for Apache that controls whether cookies can be written or not (I checked my php.ini file to check all the cookie settings). Thank you for your reply.

Since you're setting the cookie through JavaScript, neither the Apache configuration or php.ini have anything to do with this issue.

Checking the page source directly, I find this snippet here: http://worldbento.com/common/javascript/form.js. In here, it references the "gk_DOMAIN" variable for the domain part of the cookie (line 37). On the next line, it says that this variable is set in the tracking.js file. Thing is, it's hard to tell whether the variable comes from tracking.js or _tracking.js, where the gk_DOMAIN variables are set to two different values. In any case, when I have loaded the worldbento.com website, and enter the URL "javascript:alert(gk_DOMAIN)" (making JavaScript pop up an alert box showing me the value of that variable in this context), the pop-up box tells me it's set to "indianbento.com".

Basically, it's setting the cookie's domain to "indianbento.com", rather than "worldbento.com". I tried this in Opera, but I'd assume this happens in other browsers as well.

This is why I was asking why you couldn't just remove the domain parameter for the cookie, allowing the browser to handle this part by itself (not setting the domain would just make it valid for the current domain of the web page's URL).

Thank you for checking it out NeonNero, I will try that and see if it fixes the problem. If you are seeing the domain as being "indianbento.com" (different from the one that the code is running on - worldbento.com), then that could definitely be the problem. Appreciate it!

Hail to NeonNero!

That definitely was the problem. I'm just beginning to learn how to use the Chrome JavaScript debugger better, and didn't even realize that I could put a watch on the variable. It turned out that I had not updated my minified JS file _tracking.js, and so it was using the old domain.

Thank you very much!
Vik