I was using the setcookie command in the same way I’d done countless times before. I’d already taken into account that the cookie wouldn’t be available on the first page view. I couldn’t see anything wrong with the command I was using (in functions.php in the WordPress theme I was creating):

setcookie("sevisitor", 1, time()+3600);

This should have set a cookie with a name of sevisitor and a value of 1, that expires after one hour. However, no cookie was created.

After scouring the Internet in vain, I found a hint somewhere in the WordPress Support Forums (although I can’t find the page again now!). It suggested that the setcookie command’s domain parameter needed to be set.

I’d never used this parameter before and although I’ve seen explanations of what it does, I still can’t find a clear explanation of why you’d want to use it. Most descriptions of it mention that it’s optional, but don’t mention under what circumstances it would be necessary. Any PHP experts out there, please feel free to put me straight in the comments!

Anyway, after some experimentation, I got it working, by using the following command:

setcookie("sevisitor", 1, time()+3600, "/", ".scratch99.com");

Problem solved! As you can see I’ve done the following:

added the path parameter, setting it to “/”, which allows the cookie within the entire domain.

added the domain parameter, setting it to my top level domain (.scratch99.com). Note the preceding . apparently makes it compatible with more browsers.

Obviously, if you want to set a cookie in WordPress, you’ll have to replace .scratch99.com with the domain you are using.

Alternatively, you could let WordPress work out the domain for you, by using the following:

This uses the get_bloginfo('url')) command to get the site’s URL from WordPress, then strips the preceding http://www from it, leaving only the domain. Note, if you don’t use the www on your site, you’ll need to change:

str_replace('http://www'

to

str_replace('http://'

However, it’s really not worth doing things this way – your site will be slightly faster if you hard code your domain in.

The only time you’d want to use the above would be if you were putting this into a WordPress Theme that you were creating to be distributed. In that case, you’d probably want to make it a little cleverer, so that it works whether or not the www is present. But I’ll leave that to you to work out!

Anyway, the lesson I learned: If you want to set a cookie in WordPress, you must set the path and domain parameters.

52 responses on “Setting Cookies In WordPress – Trap For Beginners”

I’m not sure if this is any good to you but have you heard of Openx? It is an open source ad management program – I have been using it to geotarget adsense but it also has functions such as only showing ads after so many visits etc.

I’m surprised that wordpress doesn’t have a convenient API already set for cookies. I’m developing a plugin that will require a cookie, so found your blog this way. The closest thing I found in the true WordPress API was wp_setcookie(), which is for storing auth data only. I guess I’ll just do it the dirty way!

I haven’t tried OpenX yet. I’m using the “Who Sees Ads” plugin to limit AdSense being displayed to search visitors, although I could probably hard code the parameters into place. I’m lazy when it comes to coding, so I’ll probably leave it as is.

On using cookies to continue with search visitors… I’m not too keen on doing that. If someome moves from post to post, they’re obviously finding something they’re looking for and that completely defeats getting clicks. I suspect that the CTR would nearly drop to half of what it was before. Now, for non-AdSense pages, it’s probably a good idea — for any service that doesn’t do any kind of smart pricing.

On using cookies to continue with search visitors… I’m not too keen on doing that. If someome moves from post to post, they’re obviously finding something they’re looking for and that completely defeats getting clicks. I suspect that the CTR would nearly drop to half of what it was before

I suspect you’re right and it’s less likely they’ll click an add, but they are obviously looking for something and IF the link they clicked doesn’t give them the answer, there’s still a decent chance they’ll click on an ad before exiting.

It would reduce the CTR somewhat, but it would still be higher than normal users and I don’t believe CTR affects smart pricing. I know that’s what Court said, but I follow the Grizzly train of thought (that it’s really about targeted traffic for the advertisers and CTR is just bi-product of that).

So the real question is does Google count them as targeted traffic, because it remembers what they searched for? Or does it only recognise that they came from another page on your site?

I use “Who Sees Ads” plugin as well and it certainly helps. I am curious as to what kind of rules do you guys follow in the plugin. I have chosen to shows ads to search engine visitors or if the post is 7 days old. I see various options in there but curious if someone has fine tuned those further and your reasoning behind it.

I don’t use Who Sees Ads, but I just show Adsense to the search engine visitors, as a) they’re the ones who are really likely to click ads and b) other traffic can increase your chance of getting smart priced if they do click.

In some cases posts older than 7 days will be mostly search engine traffic anyway, but occasionally I get a StumbleUpon run on old posts…

Hope it’s OK to digress slightly? Talking of geo-targetting, is there a way to geo-target affiliate links? For example with Amazon links, so that UK visitors see the link to Amazon.co.uk, USA visitors see the link to .com

Well, I don’t use affiliate links much and it will depend on the individual affiliate, but it should be possible to do something. In theory, you could check where someone’s from, then display a certain link. But doing it would be a little complicated.

I’ll think about this for a future post, but no promises on when I may get to it as I’m flat out right now..

The domain parameter is there so you can restrict the accessibility of the cookie to just the domain you specify. If you put a dot before the domain, that also makes it available to all the subdomains. I would advise to ALWAYS use it this parameters, or else other sites could potentially pick up the cookies that your site dropped.

In general, it’s probably better to go with the WordPress constants already defined for the cookie path and domain, as the processing work figuring out their values has already been done, and that way you’ll match the existing WordPress cookies:

Great tip! I didn’t know these constants existed. COOKIE_DOMAIN isn’t mentioned on the WordPress Codex at all, and COOKIEPATH only has a few obscure mentions. I guess the WordPress Codex needs a list of constants that are available. Thanks for pointing this out.

I just tried to understand(I get the .your domain.com idea, and I think I understand The 2nd part too, but I decided to bookmark the page so I can come back while I’m actually setting up the cookie for my blog.
I’m still in the stage where I’m crossing my fingers and hoping I don’t screw anything up. (i will be holding my breath while doing it). thanks for sharing the help.
Tom

hey man this is simply new to me that cookie can be set first time. ‘set cookie command’s domain parameter’ i did not even know that this command exist. thanks man for this great piece of information. i will try to gather more knowledge about this.

Thanks for this tip. I have an area of my home page dedicated to an animated carousel of video selections. Some users have said they’d like to hide it once and not see it again, even after leaving and returning, until they choose to unhide it. Most visitors are anonymous visitors.

I was wondering if you or any of your commenters has insight into how to modify this cookie setting code so that it will remember whether a person has, at any time, clicked a “show/hide” link and “remember” their preference on the client.

There could be other reasons, but the most common reason for that error is that there is a space before the opening ) in one of your files. That said, there can often be conflicts with other plugins… That’s probably not much help, but it’s somewhere to start.

hi,
I am setting cookie as setcookie(‘Test’, “displayName”, time() + 3600, get_bloginfo(‘url’)); in header.php in wordpress,and i am displaying trying to retrieve it in comments.php,but i am not able to retrive the cookie value in comments.php.
can any one help me .

Hi, there is a neat method to avoid using the str_replace command: There are two definitions inside WordPress, that can do the job for you:
1. COOKIEPATH: Stores the right path to your cookies
2. COOKIE_DOMAIN: Since WordPress 3.0 this definition isn’t set intially within the wp-config.php, so you will need to set this to what you want.

I have a question to something you wrote in the beginning, I tried searching for the answer but couldn’t find anything. You wrote “I’d already taken into account that the cookie wouldn’t be available on the first page view.” is that a WordPress thing? – and is there no workaround?

Although your code (to create a cookie) runs on the server side, the cookie’s not actually created until the browser renders the page. By that time the server side code is finished running.

If you check for the cookie’s existence on the server side, it won’t be there on the first page load, because it’s not actually created yet. After the first page load it will have been created and you can check for it’s existence.

There are ways around this – for example: a) using JavaScript on the client side to check for the cookie’s existence and send an Ajax request to the server side, or b) forcing the page to reload via JavaScript if the cookie doesn’t exist (be careful about getting into an endless loop though).