Cookieless setting for non-www domain

How are you making WP be cookie less right now?

Most people redirect www to non-www (or vice versa) which means you only have to handle it once.

Current I add this code to the code to wp-config.php: define('COOKIE_DOMAIN', 'www.yoursite.com');

But if your site is a non-www, this wouldn’t allow you to log in to your admin panel if your browser cookie expires. Then you have to again FTP the wp-config.php file without this line and log in to your admin panel. After logging in, again FTP the wp-config.php file with this code included. It’s a headache. Just putting yoursite.com or .yoursite.com in the code will not do the trick as it will again create cookies in any subdomain.

Why are you defining it at all?

The ultimate aim of a cookieless subdomain is to ramp up speed according to Google/Yslow Page Speed requirements. One of the requirements of Page Speed is to serve static contents like images and stylesheets from a cookieless domain/subdomain. After meeting all the requirements including serving images from a cookieless domain and solving all the errors pointed out by Google Page Speed, I was able to bring down the page speeds from 12 seconds to 1+ seconds for my site MT Herald. Currently its Page Speed score is 100/100 and YSlow grade is A. WordPress by default sets up cookies in all subdomains in its neighborhood even if you serve static contains from subdomains like images.yoursite.com. However, WordPress has this option to define a cookie domain so that it would leave other subdomains intact without cookies.

But again, in my case moving to www URLs would solve the purpose. However, my prime aim of speed will get affected with every URL on the web pointing to my site getting redirected with a 302.

Hence at present the only viable solution that I could find is to define a cookie domain as accepted by WordPress as mentioned above and to set the expiry date of the cookies for an admin by a year so that it would allow to log in to the admin dashboard. So the purpose is solved; WordPress won’t create cookies at the user end browser for the contents from the cookieless subdomain and the administrator will be able to log in to the dashboard.

If you are still blank about what I said in detail here, I urge you to again read this page which I mentioned right at the beginning.

Hope some hard core, knowledgable WordPress coder sees this discussion and comes up with a permanent solution.

I read it, but I think you’re doing it wrong. (And thank you so very much for the implication that I’m not knowledgeable. That really makes my morning.)

WordPress needs cookies so that you can retain login info, as you well know. Unless you’re the EU having a snit fit, cookies are good in this case. Users are remembered by their browser, everyone’s happy. This is true, by the way, of all web apps, like WordPress, Drupal, Joomla, ZenPhoto, etc etc.

One of the requirements of Page Speed is to serve static contents like images and stylesheets from a cookieless domain/subdomain.

Not a requirement, but a SUGGESTION, just be be clear on that one.

https://code.google.com/speed/page-speed/docs/request.html#ServeFromCookielessDomain

Even there, however, they suggest a separate domain, not a subdomain. That’s why places like Amazon CDN and others use a separate domain named something OTHER than amazon.com – Full separation. For one reason, it prevents the cookie issue you’re seeing, but for another, it separates the content clearly.

If you want to host your own CDN, you should get another domain (like yoursitecdn.com) and put the data there. It won’t incur that much extra cost in the long run, and solves your issue by following the recommended practice.

Wanna have fun? Go look at how Amazon puts cookies down on your desktop. .amazon.com That would cover all their subdomains too.

What you’re doing has a point, but you’re running into a flaw not with WordPress, but with the basic expectation of how webservers in general run, and how web browsers talk to them. Since that’s going to be a loosing battle, do best practice and get a CDN on it’s own domain. After all, WordPress uses https://s2.wp.com for a reason.

I appreciate your suggestion of a CDN or separate domain for just a few bucks.

But how about a very small site that has excessive bandwidth? That same link you have referred says

(For pages that serve fewer resources than this, it’s not worth the cost of setting up an extra domain.)

And sorry for that “knowledgable” tease. Just read your profile which says

Pestering me just sets things to prolapse

and hence had to!

Meanwhile I have come up with a post on How to optimize a WordPress blog for better Page Speed. I welcome your thoughts.

The prolapse is cause I like Spider Jerusalem and Transmetropolitan (which if you’ve not read, it’s awesome).

But how about a very small site that has excessive bandwidth?

I would pay for an external CDN like Amazon, or MaxCDN. Or if possible, optimize the hell out of my server, install caching, and let it run and get 90 on my pagespeed until I can afford/justify paying more.

Doesn’t matter how big or small the site is, what matters is the traffic. If you’re gonna get hit, you have to step up and pay to keep it up, or … y’know, suffer.

I also don’t think that pagespeed is the be-all and end-all of a measure of how ‘good’ a site is. There’s 100/100 and there’s fast enough.

WordPress caching has less significance on a LiteSpeed server.

Instead of going for a CDN, I employed all those tricks including “cookieless” subdomain to reach that 100. However, the interesting part is that even after defining a www cookie domain, WordPress still makes cookies on the first view for the contents from the subdomain. Only from the second view onwards, it becomes cookieless.

Okay, let me drive home the point clear again. If anybody can help me in “defining a cookieless domain” rather than defining a cookie domain, I will be very much grateful.

It’s not a WordPress problem, which was my point. It’s how domains and cookies work.

https://www.phpied.com/www-vs-no-www-and-cookies/

You have to use www

What you’re trying to do is not actually possible. You can’t set cookies for the “root” domain and not have them go to subdomains as well. This isn’t a WP issue at all, it’s simply how cookies work.

If you want to use a subdomain for static caching (and I have seen this done many times), then you should define the “main site” on a subdomain too.

In other words, you have to have the www for such a case. Set the cookie domain to the www domain and it’ll only set cookies for that. Not for the root domain.

Okay. Now it’s clear. The only permanent solution left back is to convert the domain into www.

Thanks Ipstenu and Otto for making that crystal clear.

Oddly enough, this sort of behavior is a quirk. The final definitive specification of cookies *does* offer a way to do this sort of thing, but no user-agent implements it this way.

Mainly because this final spec only came out this April.

In that spec, you’ll find this:

If the server omits the Domain attribute, the user agent will return the cookie only to the origin server.

WARNING: Some existing user agents treat an absent Domain attribute as if the Domain attribute were present and contained the current host name. For example, if example.com returns a Set-Cookie header without a Domain attribute, these user agents will erroneously send the cookie to https://www.example.com as well.

In other words, if you omit the domain, a browser should allow it to be sent to only the main domain and not subdomains. No existing browser behaves this way.

Okay, I cannot benefit even if I define an empty domain like this with the current browsers: define('COOKIE_DOMAIN', '');

The other doubt that I have now is “Can I define the cookie domain like the ones below which will allow me to log in to the admin panel?” Of course, the WordPress files have to be in the “blog” folder in the root domain.

1.) define('COOKIE_DOMAIN', '.yoursite.com/blog');

2.) define('COOKIE_DOMAIN', 'yoursite.com/blog');

3.) define('COOKIE_DOMAIN', '.blog.yoursite.com');

4.) define('COOKIE_DOMAIN', 'blog.yoursite.com');

I welcome your thoughts in this regard.

You can’t have the path in your COOKIE_DOMAIN. But for the original question if you

define('COOKIE_DOMAIN','yoursite.com');

browsers will not use the cookie for the subdomains (not even the www).

But how to log in to admin dashboard then? It needs cookies to log in to admin panel.