parse_url bug present in script-loader.php (2.6)?

I’m getting the exact same thing in WP 2.7.1. I think the URL string is getting munged somewhere before it’s passed to PHP’s parse_url function. I’ve traced it back to class.wp-styles.php line 41. I don’t have time to monkey with it further. I hope this gets fixed.

SOLUTION!

This issue seems to happen only if WP is installed in the root of the site. Just install it into a subdirectory, and all is well. ??

In 2.8, line 433 in wp-includes/script-loader.php:

$styles->add( 'colors', true, array(), $colors_version );

Is supposed to be a “meta” style for admin colors. Something’s screwy, but I can’t be bothered to trace it any further than this. What’s happening is the “true” value for the base URL is getting passed to the parser as a “1” instead of the path to the css file. This causes the parser to puke if you have a port with five digits because the one make it six, which is invalid (chances are it works for lower port numbers, silently failing and not displaying the style correctly, but I haven’t tested that). It’s obviously supposed to do a substitution somewhere, but it ain’t happening.

Changing the “true” to a path to a css file fixes the error and displays the page correctly, but you’ve hard-coded your admin style (not that it matters):

$styles->add( 'colors', '/wp-admin/css/colors-classic.css', array(), $colors_version );

I haven’t tested Shotster’s subdirectory theory. Not sure why that would or wouldn’t work, given the above; perhaps the “1” gets moved later into the address (e.g., https://www2.heatherandjon.com:2106/subdirectory1) and that also fails silently (i.e., doesn’t cause any problems for the parser).

Anyway, the above fixes it well enough, but it’s a hack because it hard-codes something that shouldn’t be hard-coded and it doesn’t address the real problem. Would someone please take this from here and figure it out so the two of us this affects can satiate our curiosity?