Posted 2 years ago #
COOKIEPATH equates to 'home' and SITECOOKIEPATH equates to 'siteurl.'
I was initially wrong about it possibly setting two cookies.
What's happening is, it will set a test cookie with path based on the url found in 'home.' If 'siteurl' and 'home' are different, it then rewrites the test cookie with using the path based on 'siteurl.'
Either way, you should get a cookie.
Posted 2 years ago #
OK. How can there be 4 cookies named domain.nl and 2 cookies http://www.domain.nl, when 'home' and 'siteurl' are the same, and no test_cookie?
Am I missing something?
Posted 2 years ago #
You might try deleting all the cookies associated with your domain and hit wp-login.php and see what you get...
Posted 2 years ago #
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.
Posted 2 years ago #
@scriptrunner the output of that is one post higher :-)
4 cookies named domain.nl and 2 cookies http://www.domain.nl, 'home' and 'siteurl' are the same, and no test_cookie.
Posted 2 years ago #
@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
Posted 2 years ago #
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.
Posted 2 years ago #
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.
Posted 2 years ago #
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 http://www.communsense.nl/wp-admin/css/colors-fresh.css
Posted 2 years ago #
They're all rw-r--r-- Is that correct?
Posted 2 years ago #
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:
Posted 2 years ago #
@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 :-)
Posted 2 years ago #
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)
Posted 2 years ago #
Still, how is this bringing us closer to solving the issue of the cookies?
Posted 2 years ago #
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";
}
Posted 2 years ago #
@Scriptrunner: "TEST_COOKIE/COOKIE_PATH - NOT SET"
I'll leave the code in so you can give it a go yourself.
Posted 2 years ago #
@Scriptrunner Both sites behave exactly the same, I may add.
Posted 2 years ago #
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?
Posted 2 years ago #
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).
Posted 2 years ago #
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.
Posted 2 years ago #
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.
Posted 2 years ago #
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.
Posted 2 years ago #
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
Posted 2 years ago #
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.
Posted 2 years ago #
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?
Posted 2 years ago #
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)
Posted 2 years ago #
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.
Posted 2 years ago #
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.
Posted 2 years ago #
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='http://www.google.com/cookies.html'>enable cookies</a> to use WordPress."));
// else
$user = wp_signon('', $secure_cookie);
Posted 2 years ago #
Will this be removed when WP is updated?The suggested fix in another thread...Comment out lines 744-746 in wp-login.php
This topic has been closed to new replies.
