@gogoplata No I didn’t file a ticket for wpmu yet. I solved my problem and moved on for the night. I wanted to wait and see if anyone else was having the same prob with that wpmu rev. I’m not really sure it *is* exclusively an wpmu problem.
Yes, I rebooted the dev apache instance. Thanks. I’m not sure that apache has anything to do with it.
I was under the mistaken impression that only css files could be imported from a css file. I can’t exactly figure out who/what is failing here. I was trying to work out in my head the sequence of things that happen in this case.
member theme: style.css @import(css/loader.php) .. loader.php? php? what does a browser do with php code? nothing as far as I know.
so what is taking over the interpretation of the php code in loader.php?
mechanism is:
1) browser gets the style.css file, runs across the @import statement and sends a request to apache for a php file
2) apache hands loader.php off to it’s internally loaded php module
3) loader.php runs and outputs a dynamically created stylesheet to the browser
Where is wpmu in all that? My confusion comes in when I consider that.
STOP. Me not you. While I was pondering this and writing this reply, I took a look at the code on the live server for loader.php. It’s *not* the same.
/* Load the WP environment */
require_once( dirname( dirname( dirname( dirname( dirname ( __FILE__ ) ) ) ) ) . '/wp-load.php' );
That’s on the bp version that is running on the live server. A couple of revs ago.
/* Load the WP environment */
require_once( preg_replace('/(.*)/wp-content/.*/', '1', dirname( __FILE__ ) ) . '/wp-load.php' );
Above is what is in r64x something. I’ve lost track of what rev is running on the dev server at the moment. Anyway, if the require wp-load.php fails for some reason what happens. PHP stops interpreting and nothing else below that happens.
Eh?
