Ed

Unfortunately sunrise.php doesn’t seem to work unless it’s on a mapped domain site, it didn’t affect either the test code to show the cookies or allow IE users to log in on non-mapped sites.

jkhongusc, the COOKIE_DOMAIN for ed.gs domains are now blank. Mapped domains use the domain as a the COOKIE_DOMAIN.

That’s the standard sunrise.php. It’s only happening on unmapped domains, in Internet Explorer, works everywhere else. Mapped domains work fine in IE too.

Sorry Mika, forgot to mention that I grepped through all files and there’s no defining of COOKIE_DOMAIN anywhere.Here’s a gist with it all to save space on here https://gist.github.com/Coopeh/18d6ca3d88da4d3b27ab

Cheers, Ed

DOMAIN_CURRENT_SITE is set to ed.gs but there’s no COOKIE_DOMAIN defined in my wp-config. I’ve checked sunrise.php, it’s the current one from Donncha’s latest domain mapping plugin. I even removed it and re-added from the plugin.

<?php
define('DB_NAME', '***');
define('DB_USER', '***');
define('DB_PASSWORD', '***');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
define('AUTH_KEY',         '***');
define('SECURE_AUTH_KEY',  '***');
define('LOGGED_IN_KEY',    '***');
define('NONCE_KEY',        '***');
define('AUTH_SALT',        '***');
define('SECURE_AUTH_SALT', '***');
define('LOGGED_IN_SALT',   '***');
define('NONCE_SALT',       '***');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');
$table_prefix  = '***_';
define('WPLANG', 'en_GB');
if ( isset($_GET['debug']) && $_GET['debug'] == '1' ) {
        define('WP_DEBUG', true);
} elseif ( isset($_GET['debug']) && $_GET['debug'] == '2' ) {
        define('WP_DEBUG', true);
        define('WP_DEBUG_DISPLAY', true);
} elseif ( isset($_GET['debug']) && $_GET['debug'] == '3' ) {
        define('WP_DEBUG', true);
        define('WP_DEBUG_LOG', true);
}
define('VHP_VARNISH_IP','***');
define( 'AUTOSAVE_INTERVAL', 120 );
define( 'WP_POST_REVISIONS', 30 );
define( 'EMPTY_TRASH_DAYS', 7 );
define( 'WP_MEMORY_LIMIT', '128M' );
define( 'ALLOW_UNFILTERED_UPLOADS', true );
define( 'DISALLOW_UNFILTERED_HTML', false );
define( 'FS_METHOD', 'direct' );
define( 'WP_DEFAULT_THEME', 'twentytwelve' );
define( 'MULTISITE', true );
//define( 'SUBDOMAIN_INSTALL', true );
define( 'SUBDOMAIN_INSTALL', false );
define( 'DOMAIN_CURRENT_SITE', 'ed.gs' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
define( 'NOBLOGREDIRECT', 'https://ed.gs/' );
define( 'WP_CACHE_KEY_SALT', '***' );
define( 'SUNRISE', 'on' );
define( 'GF_LICENSE_KEY', '***' );
define( 'FORCE_SSL_LOGIN', false );
define( 'FORCE_SSL_ADMIN', false );
define( 'WP_AUTO_UPDATE_CORE', false );
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
       $_SERVER['HTTPS']='on';
@ini_set('log_errors','On');
@ini_set('display_errors','Off');
@ini_set('error_log','/var/www/***');

if ( !defined('ABSPATH') )
        define('ABSPATH', dirname(__FILE__) . '/');
require_once(ABSPATH . 'wp-settings.php');

FYI, this also breaks post previews for draft and private posts.

This still isn’t working. I’ve also tried changing my auth keys and salts with alphanumeric values only.

I’m at a loss.

I’ve got Remote Login, Permanent redirect (better for your blogger’s pagerank) and User domain mapping page enabled. If you enable 4 (Redirect administration pages to site’s original domain (remote login disabled if this redirect is disabled)) on mine then it will disable Remote Login.

Ok, this is very strange. If I do “define( ‘SUBDOMAIN_INSTALL’, false );” then it now lets me log in, but the installation is a subdomain installation.

I’ve now copied the entire site and replicated it on another domain and I can’t replicate the issue.

I also receive these errors if I enable WP_DEBUG:

Notice: wpdb::escape is deprecated since version 3.6! Use wpdb::prepare() or esc_sql() instead. in /***/wp-includes/functions.php on line 2913

Strict Standards: Non-static method Bau_Installer::check() should not be called statically in /***/wp-content/plugins/blogs-and-users/blogs-and-users.php on line 76

Strict Standards: Declaration of emc2_enhanced_menu_walker::start_el() should be compatible with Walker_Nav_Menu::start_el(&$output, $item, $depth = 0, $args = Array, $id = 0) in /*/wp-content/plugins/enhanced-menu-editor/emc2-enhanced-menu-editor.php on line 0

Notice: Undefined index: pagenow in /*/wp-includes/link-template.php on line 1999

Notice: Constant EXTERNAL_IMAGES_DIR already defined in /*/wp-content/plugins/import-external-images/import-external-images.php on line 37

Notice: Use of undefined constant UPLOADS - assumed 'UPLOADS' in /*/wp-content/plugins/ultimate-branding/ultimate-branding-files/includes/functions.php on line 281

In my opinion and from the above testing, I don’t think any of these would be causing it.

Sorry, I didn’t mean as a permanent fixture. I’ve been going through all the similar threads and implementing the ideas as tests.

The test I performed with the removal of the hidden input resulted in a wordpress_logged_in cookie being created, but it still didn’t log me in and still shows the cookie error message on each submission.

I’ve also tested the code you supplied above previously and it again creates the wordpress_logged_in cookie, but still redirects back to the login page and shows the cookie error message.

Really can’t get my head around this, the cookies are EXACTLY the same on all browsers. I’ve also re-uploaded all the files, disabled all plugins & object cache, set theme back to TwentyEleven and TwentyTwelve, checked wp-config settings, temporarily removed domain mapping plugin + sunrise.php, added the COOKIE_DOMAIN declaration, disabled all caching and CloudFlare interference. No idea what else I can do, it’s getting to the point where customers are now leaving because of it.

I’ve tested removing the following login form check and it creates a wordpress_logged_in cookie, but still goes back to the login page.

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

Do you think it has something to do with the dot at the start of the cookie domain?