BuddyPress.org

@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?