Scriptrunner (Doug Sparling)

I’ve moved a few sites to PHP 5.4 on BlueHost, and the only issue I ran into was plugins using PHP call-time pass-by-reference, which was deprecated in PHP 5.3 and removed in PHP 5.4.

The easiest way to track this down is testing your site in PHP 5.4 locally or a test machine and setting WP_DEBUG to true. PHP 5.4 will not effect WordPress itself in anyway, but any plugins/themes using call time pass by reference will cause a fatal error.

@adamelmer – this is starting to venture into needing to start a new thread, but I’ll go ahead and give you a couple of suggestions none the less.

It sounds like you have a plugin that’s not compatible with WordPress 3.7.1. So, try:

1) Turn on WP_DEBUG and/or look in your server error logs. Besides the “Cookies are blocked or not supported” that’s displayed on the login page, do you see any errors with debugging turned on? (and most likely, they’ll be “headers already sent”)

2) Rename your plugin folder like you were doing, but add a single plugin back at a time to your new empty plugin folder and go through the logout/login process until you find the plugin that’s causing the issue. Or alternatively, do what you’re doing now, except deactivate all your plugins before logging out.

OK, thanks to @jgjh151 sharing his Varnish config file, I think I’ve got this mystery solved.

So…it is definitely an issue with Varnish configuration, but, something also did change in WordPress 3.7, but it was a bug fix. So due to a bug in wp-login.php in pre-WordPress 3.7, an incorrect configuration in Varnish did not cause any issues with WordPress because the bug in WordPress caused wp-login.php to not actually check the test cookie.

Here’s the line in Varnish config that’s causing the issue:

if ( (!(req.url ~ "(wp-(login|admin)|login)")) || (req.request == "GET") ) {

It needs to be:

if ( (!(req.url ~ "(wp-(login|admin)|login)")) ) {

Now for the quick explanation. In WordPress 3.6.1 (and earlier I assume), the req.request == "GET" part of Varnish config was preventing wp-login.php from writing the test cookie when the form was loaded (called with a GET), but the code that checked if the test cookie was actually set (when wp-login.php called via a POST) never ran if the user’s credentials were good. That is, on the form post, if the user authenticated properly, then the user was redirected to wp-admin without this code being run:

if ( isset($_POST['testcookie']) && empty($_COOKIE[TEST_COOKIE]) )

In WordPress 3.7, this bug in wp-login.php was fixed, moving the redirect to wp-admin on successful login *after* the cookie check code above. So now the cookie check is actually run. So if Varnish is deleting the test cookie on GET request to the wp-login.php, this won’t prevent a login with WordPress 3.6.1 or older, but now that WordPress is actually checking for the test cookie, it will fails the cookie check as it should.

So even though something did change in WordPress, it’s due to misconfiguration of Varnish. (and any other proxy/caching server I imagine)

To use Varnish with WordPress, at least Varnish 3, it’s best to follow the sample template here:

Varnish 3.0 templates – WordPress, Drupal, Joomla and Fork CMS VCL templates

And specifically for WordPress:

fetch/wordpress.vcl
receive/wordpress.vcl

@esmi – in the case of @willem.deboer it looks like he’s coming through a proxy server as well, but no sure it’s Varnish:

Via: 1.1 W0211, 1.1 W020

I doubt it’s PHP. (and I’ve tested on PHP 5.2.x, 5.3.x, 5.4.x, and 5.5.x – all good) Since JavaScript runs client side, no surprise that cookies can be set that way. It all points to server configuration/environment, with proxy server definitely a possibility.

In all the testing I’ve done, the only way I’ve gotten the cookie to not set properly is by modifying my Varnish config.

I’m still able to login by after removing:

<input type="hidden" name="testcookie" value="1" />

but then again, I’m not having any trouble with it either. I would be very curious what’s in the server error log if you can get access to it or the engineer can get you a copy.

I downloaded fresh archive versions of 3.5, 3.6, 3.6.1, 3.7, and 3.7.1. What I did notice is that wp-login.php did not change between 3.7 and 3.7.1. 3.5-3.6.1, wp-login.php sets the test cookies in the same way as it does in 3.7+, but the code dealing with logic for a missing test cookie is somewhat different between pre-3.7 and 3.7+.

I’ve been guessing too much, but it seems that nothing in 3.7/3.7.1 has changed in regard to setting of the test cookie when first hitting wp-login.php. You might try removing:

<input type="hidden" name="testcookie" value="1" />

as that should disable the test cookie check on form submission.

As I said, for now I’m going to bow out of any more troubleshooting suggestions, at least until I discover something substantial. It seems to be an environment issue of some sort. I run a dozen or so sites using three different hosting companies and have yet to have any problem, which is the opposite of your situation.

I’m back in work mode, so I’ll have lest time to devote this issue. If I discovering something tangible, I’ll let you know.

OK, curiosity got the best of me and I installed Varnish.

Actually, it’s conf.d/fetch/wordpress.vcl

By doing this:

#if (!(req.url ~ "wp-(login|admin)")) {
    unset beresp.http.set-cookie;
#}

I can stop the testcookie from being set and I get the “Cookies are blocked or not supported” error. However, that gives me the error on WordPress, at least back to 3.6.1, and if I uncomment the if statement, it works on 3.7.1. So yes, Varnish can cause the issue, but it doesn’t seem to be 3.7.1 specific. (but once again, it could depends
on configuration)

So I’m bowing out this thread…I can duplicate it, but I’m not sure my results mean much.