stonicus

in wp-includes/formatting.php, function sanitize_option(), case ‘admin_email’, I made the following change:

case 'admin_email':
	$values = explode(",", $value);
	foreach($values as $k=>$v)
		$values[$k] = sanitize_email($v);
	$value = implode(",", $values);
	break;

then, in wp-includes/pluggable.php, function wp_mail, I made the following change:

function wp_mail( $targets, $subject, $message, $headers = '' )
{
	$tars = explode(",", $targets);
	foreach($tars as $to)
	{
		// original function code here except for last return line
	}
	return $result
}

This allows commas between emails in the admin email setting, and ONLY the admin email setting, and the wp_mail function will mail whatever to every email separated by a comma. But, since as stated the admin_email is the only one we allow commas for, this is the only one that can receive this multiple-email functionality. We only return the $result of the attempt to send the last email. I don’t think that will cause any problems though.

This particular method requires a comma, and a comma only, between the email addresses. However, you could change the explode/implode functions to allow whatever delimiter you desire, just make sure to make it something that isn’t valid in email addresses anyway, so you don’t split up someone’s valid email address.

Thought I had found a fix, and posted in another thread about it, but it wasn’t correct, although I am on the right track I think.

For my site I’m working on locally, the URL is ‘localhost/WorstOf’. When the server fills out the $_COOKIE array, it does so with cookies with a path of ‘/WorstOf’. However, if I go the site with the URL of ‘localhost/worstof’ (note the case), it fills $_COOKIE with cookies with a path of ‘/worstof’, but WordPress is looking for cookies with a path of ‘/WorstOf’, and they don’t match.

So, the URL you type into the address bar has to match the case of the ‘siteurl’ you have setup when you configured your WordPress blog, as that is what the COOKIEPATH define is made from. If your ‘siteurl’ is ‘/MySite’, then you must put ‘/MySite’ in the address bar. ‘/mysite’ will take you to your site, but WordPress will look for cookies with a path of ‘/MySite’, and will always be empty.

So, you actually get logged on, but the blog can’t detect it if your address and ‘siteurl’ don’t match. But then what happens, is when you ignore the error and go about your business, behind the scenes, WordPress will redirect to your ‘siteurl’, and then the cases match up again, and all is well with the world.

So, what we need to do is detect this mismatch and redirect from the get-go. Here’s what I did.

In wp-blog-header.php, I added the following code at line 18 between
require_once( dirname(__FILE__) . '/wp-config.php');
and
wp();

(code to insert)

if($_SERVER['REQUEST_URI'] != COOKIEPATH)
{
  wp_redirect(get_option('siteurl'));
  exit();
}

I use COOKIEPATH because it is built from ‘siteurl’ and is exactly what I need to check the current URL against. I put it in wp-blog-header.php because index.php is the only file to include it and we only need to catch this mismatch at the first entrance to our site, and the site will then use the proper case for the rest of the session.

Once I did this, all my problems went away. I haven’t done full on extensive testing of every single feature of the site, but so far this has served me well and has shown no ill-effects. Any combination of case in my url will now work (‘/WoRsToF’, ‘/worSTof’, ‘/WORSTof’, etc…)

Anyone who sees a problem with this, or can find a better place to put such a check, or even a better solution outright, please let us know. But for now, I think this will help out some of you having the same problem I did.

In wp-setting.php, I put a strtolower() around the defines for COOKIEPATH and SITECOOKIEPATH… problem disappeared.

if(!defined(‘COOKIEPATH’))
define(‘COOKIEPATH’, strtolower(preg_replace(‘|https?://[^/]+|i’, ”, get_option(‘home’) . ‘/’ ) ));

if(!defined(‘SITECOOKIEPATH’))
define(‘SITECOOKIEPATH’, strtolower(preg_replace(‘|https?://[^/]+|i’, ”, get_option(‘siteurl’) . ‘/’ ) ));

Had this same problem, and I found the cause, at least for me…

Working on a blog called ‘Worst Of’ for people to write complaints about various local businesses etc, that’s not really important, but I’m currently developing it locally (localhost).

In wp-login.php, the variable COOKIEPATH returns ‘/WorstOf’. But when i go to view the site, if I type in ‘localhost/worstof’ (all lowercase), I get the ‘Cookies not supported error’. If I type in ‘localhost/WorstOf’, it all works perfectly. So, the cookie checks are case sensitive. I would suggest putting a lowercase() around all paths that set cookies, and lowercase() around all checks.