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

OK. How can there be 4 cookies named domain.nl and 2 cookies https://www.domain.nl, when ‘home’ and ‘siteurl’ are the same, and no test_cookie?
Am I missing something?

You might try deleting all the cookies associated with your domain and hit wp-login.php and see what you get…

Willem, you mentioned earlier that you got a white screen while using one of the default themes. Please edit your wp-config.php file. Find the line near the bottom that reads define('WP_DEBUG', false); and change false to true, then upload the modified file back to your server. Switch to one of the themes from which you got the white screen by moving any other themes out of the themes folder. Try the login page again. You should see one or more error messages on the white screen. Please report what these are.

@scriptrunner the output of that is one post higher ??
4 cookies named domain.nl and 2 cookies https://www.domain.nl, ‘home’ and ‘siteurl’ are the same, and no test_cookie.

@bcworkz

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

I know you’ve already tried default theme/disabling plugins (and you’ve deleted and reinstalled WordPress core files), but you might do that again with DEBUG set to true.

The first Notice I’ve seen happen from plugins using a deprecated function and also when file are FTP’d up in binary instead of ASCII.

The second notice is from a plugin, and I wouldn’t think would cause issues.

Also, you might try reuploading wp-login.php. It should set a test cookie, and from your report some cookies are getting set.

I know you’ve already tried default theme/disabling plugins (and you’ve deleted and reinstalled WordPress core files), but you might do that again with DEBUG set to true.

OK, I’ve done what you said. The result is a clean white screen without errormessages. As soon as I enable the plugins again the above errormessages return.

The first Notice I’ve seen happen from plugins using a deprecated function and also when file are FTP’d up in binary instead of ASCII.

The second notice is from a plugin, and I wouldn’t think would cause issues.

I tried without plugins and it still doesn’t work, so I think that rules out that option anyway.

Also, you might try reuploading wp-login.php. It should set a test cookie, and from your report some cookies are getting set.

I did that, makes no difference. The upgrade, by the way, was always done through the WordPress admin interface by simply pressing the button “upgrade”.
Only the last time, after the issues developed, I have uploaded the fresh files myself, using WinSCP with the upload set to binary. I have now set it to “automatic”. The fresh upload behaved exactly the same.

Not sure if it’s related but check permissions on the wp-admin directory. I get permission errors on anything in that directory, including things that should be publicly accessible like https://www.communsense.nl/wp-admin/css/colors-fresh.css

They’re all rw-r–r– Is that correct?

Actually, no, not for directories. Directories need be “executable.” Generally for WordPress, directories are 755 (drwxr-xr-x)and files are 644 (rw-r–r–).

These codex pages may help:

Changing File Permissions
Hardening WordPress

@scriptrunner thank you. I have checked, all directories ar 755. Looked at the codex pages, all is sorted. I have also limited access to admin pages by adding the following to .htacces in wp-admin:

order deny,allow
allow from xxx.xxx.xxx.xxx
deny from all

where xxx.xxx.xxx.xxx is the ip of the computer you are doing administration from.

My webhoster’s engineer pointed this addition out to me.

This is also the reason you are getting permission errors on anything in wp-admin ??

I had considered that.

You might want add (or add to) .htaccess in the wp-admin directory with this in it:

<Files admin-ajax.php>
    Order allow,deny
    Allow from all
    Satisfy any
</Files>

as wp-admin/admin-ajax.php is used by the front-end (see Codex: Hardening WordPress – securing wp-admin)

Also, you might want to protect wp-login.php, as it’s in top-level directory, not under wp-admin. (though locking down wp-admin will prevent anyone who does successfully brute force a login to get anywhere)

Still, how is this bringing us closer to solving the issue of the cookies?

At this point, if it were me, I’d add a simple echo statement to check that 1) the test cookie code is being called and 2) if so, check if setcookie was successful.

In wp-login.php, right before this code (which should be line 420):

//Set a cookie now to see if they are supported by the browser.
setcookie(TEST_COOKIE, 'WP Cookie check', 0, COOKIEPATH, COOKIE_DOMAIN);
if ( SITECOOKIEPATH != COOKIEPATH )
	setcookie(TEST_COOKIE, 'WP Cookie check', 0, SITECOOKIEPATH, COOKIE_DOMAIN);

I’d add:

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

@scriptrunner: “TEST_COOKIE/COOKIE_PATH – NOT SET”

I’ll leave the code in so you can give it a go yourself.