"Cookies are blocked or not supported" since update to 3.7.1

@scriptrunner Both sites behave exactly the same, I may add.

If php setcookie function returns false, that means (according to docs):

If output exists prior to calling this function, setcookie() will fail and return FALSE .

Setting WP_DEBUG to true should show you any errors, though I think you already did that and you probably should have seen an “headers already sent” error. Did you look in the apache error log itself?

Also, after setting WP_DEBUG to true, try changing the code I gave you to:

if (setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN)) {
	error_log("TEST_COOKIE/COOKIE_PATH - SET");
} else {
	error_log("TEST_COOKIE/COOKIE_PATH - NOT SET");
}

When you say both sites, do you mean with www and without, or do you have another site that’s working?

Setting WP_DEBUG to true should show you any errors, though I think you already did that and you probably should have seen an “headers already sent” error. Did you look in the apache error log itself?

I do not believe I have access to the Apache error log.

Also, after setting WP_DEBUG to true, try changing the code I gave you to:

Output: Notice: upgrade-functions.php is deprecated since version 2.5! Use wp-admin/includes/upgrade.php instead. in /usr/local/pem/vhosts/145416/webspace/httpdocs/wp-includes/functions.php on line 2966 Notice: Undefined index: ssdshortcode in /usr/local/pem/vhosts/145416/webspace/httpdocs/wp-content/plugins/ss-downloads/includes/functions.php on line 41 Warning: Cannot modify header information – headers already sent by (output started at /usr/local/pem/vhosts/145416/webspace/httpdocs/wp-includes/functions.php:2966) in /usr/local/pem/vhosts/145416/webspace/httpdocs/wp-login.php on line 409 Warning: Cannot modify header information – headers already sent by (output started at /usr/local/pem/vhosts/145416/webspace/httpdocs/wp-includes/functions.php:2966) in /usr/local/pem/vhosts/145416/webspace/httpdocs/wp-login.php on line 420 Warning: Cannot modify header information – headers already sent by (output started at /usr/local/pem/vhosts/145416/webspace/httpdocs/wp-includes/functions.php:2966) in /usr/local/pem/vhosts/145416/webspace/httpdocs/wp-login.php on line 427

When you say both sites, do you mean with www and without, or do you have another site that’s working?

I have two separate websites, hosted by the same provider, on different database servers, webspace on different servers, separate install WordPress, different URL. Both exhibiting the exact same issue(s).

First, check this codex page:
How do I solve the Headers already sent warning problem?

You mentioned you FTP’d your files in binary mode but I can’t tell from our conversation if you only uploaded wp-login.php with automatic mode, or everything. As the link above suggests, wp-config.php is often the culprit for the headers already sent error message.

Also, as there’s an notice about deprecate file wp-admin/includes/upgrade-functions.php tells me that old files weren’t deleted first when you uploaded the new ones. WordPress 3.7.1 does not include upgrade-functions.php, but I have a fresh install. However, without the deprecated upgrade-functions.php, the ss-downloads plugin will probably break. However, this shouldn’t be causing the problem, I really think that it’s related to the ‘headers already sent’ error and I’d follow that codex page. Uploading in binary very well could have caused the problem. The headers already being sent is preventing the test cookie from being set.

Did you get the “browser doesn’t support cookies” error right after doing the ugprade through the admin, or did you upload anything before seeing that error? It’s also possible the upgrade via the admin timed out or corrupted some files.

You mentioned you FTP’d your files in binary mode but I can’t tell from our conversation if you only uploaded wp-login.php with automatic mode, or everything. As the link above suggests, wp-config.php is often the culprit for the headers already sent error message.

@scriptrunner I re-uploaded all files after deleting everything except wp-content from the server. Then after earlier remarks in this thread I re-uploaded wp-config.php in automatic mode. The funny thing is that upgrade-functions.php is not in my wp-admin/includes/, which is part of a fresh upload straight from the 3.7.1 archive. So should I re-upload the include directory in automatic mode?

I have just uploaded a clean wp-config.php in text-mode and pasted the content from the old one back in.

By the way, WordPress had been running fine for more than a year with this wp-config.php.

Did you get the “browser doesn’t support cookies” error right after doing the ugprade through the admin, or did you upload anything before seeing that error? It’s also possible the upgrade via the admin timed out or corrupted some files.

I’m not sure if it started right after the upgrade. I remember updating plugins, themes and WordPress. I always do it in that order to be sure everything else is up-to-date before applying the WordPress upgrade. All upgrades were done via the admin.
I don’t think corrupted files as a result of an admin timeout is the culprit, because I have since re-uploaded everything from a fresh archive of 3.7.1

OK, I wouldn’t worry about upgrade-functions.php at the moment. It won’t be in WordPress 3.7.1, so what you have is fine.

The only thing I’ve seen in this thread (and the previous one) that makes any sense is the “headers already sent” error, as that would prevent the test cookies from being written.

As far as the cause of that error (headers already sent), it’s not necessarily wp-config.php, but often is. But it could be any php file with extra white space after the closing php tag at the end of the file. (which is why the closing php tag at the end of a file is often not used)

Once again, if it were me, I’d either delete and re-upload core files or I would just back everything up (I’d do that anyway) and do a complete fresh install (using your current wp-config.php file or copying the content over to the new one so you can use your existing database) and then bring over theme and plugins (from your old wp-content directory) over an item at a time. I’d probably go with deleting and re-uploading core files first, making sure FTP is set to automatic. If that didn’t work, then doing the complete re-install (WordPress only, not the database) might be the only way. Get a vanilla install working and then bring back in your theme and plugins. It looks like over the course of the last two or three days, you’ve made a lot of changes trying to fix things. Sometimes it might be best to start at square one and go from there.

You definitely need to eliminate the “headers already sent” error.
As far as a corrupt file from the upgrade, I just meant originally. That happens sometimes. Anyway, I’m not sure I can offer much more advice, but I don’t mind answering (or trying to ?? any other questions. I don’t think WordPress itself is the problem, but more likely something to do with the install or a theme/plugin compatibility issue.

So, may I paraphrase that as: “the last update from 3.7 to 3.7.1 corrupted one or more files”. What worries me, is that it didn’t just happen to me, it happened to a lot of people. So I think it does have to do with WordPress 3.7.1. I’ll try your suggestions and see what happens.
What’s a vanilla install?

Actually, no, that wouldn’t be a precise paraphrase. It’s possible with any install or upgrade (of WordPress or any other software) for files to become corrupted for a multitude of reasons (often due to a server timeout in the case of web-based installs), nothing to do with WordPress at all. I’ve not seen any reports other than this thread that there’s been any problems. All my installs went from 3.7 to 3.7.1 just fine. There are so many variables – severs, versions of OS, PHP, MySQL, etc, and http connections, which aren’t always reliable. Generally (I’d almost say always) point release versions upgrades of WordPress are seamless.

Vanilla install – sorry, I mean just a plain, basic install. Default themes and no plugins. (other than what comes with WordPress itself)

Also, it’s up to theme and plugin authors to keep their software, which is separate from core, up-to-date and compatible with the latest releases of WordPress and different versions of PHP.

I have same issue after latest update, test cookie is not set on hitting login page. I get the error about needing cookies enabled. On second login attempt, I get into admin fine. Although when clicking logout, I’m able to click back and navigate admin area as if still logged in. This issue is happening on all my wordpress sites on two different servers. All worked fine before the update.

Well, it does appear under certain scenarios this is an issue – I’ve heard everything from admin not allowing cookies (seems less likely) to proxy servers (Varnish) removing testcookie.

The suggested fix in another thread…Comment out lines 744-746 in wp-login.php:

//	if ( isset($_POST['testcookie']) && empty($_COOKIE[TEST_COOKIE]) )
//		$user = new WP_Error('test_cookie', __("<strong>ERROR</strong>: Cookies are blocked or not supported by your browser. You must <a href='https://www.google.com/cookies.html'>enable cookies</a> to use WordPress."));
//	else
		$user = wp_signon('', $secure_cookie);

The suggested fix in another thread…Comment out lines 744-746 in wp-login.php

Will this be removed when WP is updated?

More than likely. (if wp-login.php is updated)

The other thread is here: Cookie Error when Logging In

Someone had something for their functions.php (I know @willem.deboer saw it), but apparently it didn’t work.

So for now, it looks like for those effected, it’s hack a core file, revert to WordPress 3.7, or upload wp-login.php from WordPress 3.7. (it should work with WordPress 3.7.1)

I’m not on the core team, just a plugin developer and someone with clients running on WordPress. I haven’t been effected by this, but this is the kind of odd ball things that popup that I try to keep up with.

I’m curious and don’t know how it’ll be treated a sit seems to be an issue with the environment WordPress is running in. (a proxy server blocking or deleting certain cookies if that report is true)