How to Avoid Login Issues
Table of Contents
- Understanding Member Login Differences
- How to Avoid WordPress Member Login Issues
Understanding Member Login Differences
Some site owners don't realize that all browsers consider variations in your domain as different. That is, every browser sees each of these four URLs (below) as slightly different destinations. Therefore, logging into your account on one of these, and then being redirected to a slightly different variation, may result in the user not being logged-in as you might expect; i.e., cookies may not exist.
1. http://example.com/ :: http scheme, no sub-domain. 2. https://example.com :: https scheme, different protocol. 3. http://www.example.com/ :: different sub-domain; i.e. www 4. https://www.example.com/ :: different sub-domain and protocol.
If I visit
http://example.com/ and I enter my username/password, I'm logged-in at
www); and over the
http:// protocol. However, if you post links that point to
www.example.com (with the
www), the user may not be logged-in there.
www vs. without
Your domain name has a root. It's the domain without anything in front of it; e.g.,
example.com. While most people tend to think of
www.example.com as the same, they are in fact not the same. The
www. prefix is not a magic mirror, it's just another sub-domain.
www. prefix indicates a sub-domain like any other; e.g.
www.example.com. All of these are sub-domains; i.e. not quite the same as your root, which is:
example.com. When it comes to WordPress and the way WordPress sets login cookies, these are all completely different, because WordPress sets a logged-in cookie for the current domain. If the current domain (in the address bar of your browser) is a sub-domain, your logged-in cookie is valid for the sub-domain only; i.e., not functional at
Therefore, if a user logs into your site at
www.example.com, but you allow your site to be accessed with or without the
www. prefix, this can lead to many issues. Most site owners that understand this will work to adjust their server configuration so it forces one variation to be used across the entire site. See: http://davidwalsh.name/no-www for some quick examples of this.
HTTPS vs. HTTP (Subtle Differences)
In browsers like Google Chrome, Safari, Firefox, Opera, and another I dare not mention; it is possible for WordPress to set a cookie that is only available over the
https:// protocol (i.e., a secure "https only" cookie). See: http://en.wikipedia.org/wiki/HTTP_cookie#Secure_cookie
In WordPress, if a user logs into the site over
https://, WordPress will generally set the cookie as "https only". This is done as an added layer of security. WordPress assumes this is what you'd want whenever you ask users to log into the site over
What impact does this have on my site?
It means that a user logging into the site over
http://, will be able to access the site over
https://also. There's no issue with this, because WordPress only makes the cookie "https only" if the login occurred over
https://to begin with. A cookie that is not "https only" can be read from either protocol without issue.
Important: ... if a user logs into the site over
https://, where the form action is something like
https://example.com/wp-login.php, there is a good chance they will not be thought of as logged-in on the
http://protocol. Their logged-in cookie is only good over SSL in this case.
http://example.com/after logging in from
https://example.com/will lead to confusion. This is because WordPress sets the cookie in such a way that it is only accessible over SSL; i.e., on the original protocol they logged into the site with:
How to Avoid WordPress Member Login Issues
Decide on a Domain Variation for WordPress
Decide early-on which domain variation you're going to use, and make sure that your installation of WordPress® is configured to match what you intend to use. See: WordPress Dashboard → Settings → General. All of the URLs configured in that panel need to match what you intend to use.
Remain Consistent when Building WordPress Links
Be consistent in the way you link to pages on your site. Please do not create links on your site that use different variations of your domain. That could result in a visitor logging in on one variation, but clicking links on your site that land them on another variation (where they may not be recognized as a logged-in member). If you've already done some of this in error, you can mass update Posts/Pages using a tool like Search Regex for WordPress.
Avoiding Sub-Domain Cookie Conflicts
By default, WordPress will set all cookies for the current domain. If the current domain is
www.example.com, the cookie will not work on
example.com or at
sub.example.com. However, you can tell WordPress to use a specific root domain instead, so that when WordPress sets a cookie, it will be valid for the current domain, and also for any/all sub-domains that you might be using.
/wp-config.php file, you can add the following. See also: this article @ WordPress.
If you have WordPress installed in a sub-directory, you might also want to consider changing the
COOKIEPATH to the root of your site. By default, WordPress will set cookies where they are only valid under the current WordPress installation path. So for instance, if you have WordPress installed at:
example.com/wordpress/, a user visiting
example.com/page/ will not be logged into the site, because the cookie is not valid under this path.
To change the default WP behavior, so that a cookie is valid across all paths in the domain, you can add the following line to your