member theme “trunk-r640″
members theme was working perfectly with trunk-r571. yesterday I installed the latest trunk-r640, everything went okay but the issue is member theme does not work?!!
I removed the latest installation and installed the previous trunk and now member theme is working fine, any idea whats the issue with the latest trunk?!! thanks
just to clarify my issue, when I go to user’s profile, the content is fine but with white background, user bar becomes vertical, there is no layout!!
Ya, got a similar problem. Installed wpmu 2.7 and r644 and no member theme css all of a sudden. The home theme is fine, just the member theme is affected. Trying to debug it now.
I have the same problem on trunk r646. No members page. Everything else seems okay.
The difference between the member theme and the home theme css is that the member theme uses a a main style.css file that is composed of nothing except this:
loader.php determines what bp components are installed and then sends those to the browser. My live install of bp is running wpmu 2.6.2 and my dev server is running a fresh install of wpmu 2.7 from trunk.
Both the live and dev installs are basically the same. They both have the stub style.css sheet that runs loader.php for the actual css for installed components.
The only difference is the one that works is running wpmu 2.6.2, the one that doesn’t is running 2.7 trunk
What’s different on your installs from then to now?
Yep. That’s the problem on this dev install. The @import(css/loader.php) statement
I just changed the member theme style.css file to import all the css files in the css directory that loader.php sucks up. Works like a charm.
wpmu 2.7 doesn’t like that statement?
testbp.org is running ‘WordPress 2.7-RC1-10119′
my dev machine is running ‘WordPress 2.7-RC1-10145′
EDIT: whoops. dup post due to operator misuse of the browser back and edit post buttons
burtadsit did you file a ticket in wpmu trunk? I would imagine that it should be sorted when Donncha pulls right to 2.7 release, but who knows. I actually am running 10145 right now and it works fine for me. I always reboot apache to make sure my xcache doesn’t keep the wrong data as well as make sure “turbo” isn’t the problem with old files.
Well, WP 2.7 officially released, but WPMU 2.7 should be close behind.
@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?
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.
Yep. That’s what is happening. In the php error log, it’s trying to require_once the wp-load.php file from the bp member theme css dir. It ain’t there. I’ll figure out what is wrong with the regex and post a ticket.
Posted a ticket (without a fix yet, sorry Andy)
This is a windows file name problem. loader.php was looking for forward slashes in a directory name and getting backslashes in windows.
Trac has a patch:
I gotta switch over to a linux dev server. But I really like my Vaio running windows. I’ll just buy another domain and hook it up to the DV server. $10 won’t break me. It does mean that I won’t be able to do laundry this week though.
I’ve replaced loader.php with the old one “r-571, now its working fine.
Ya, that’s almost what I did at first just to get things running. It was driving me nuts though. Should work, didn’t work. Now it does work with the patch. Just a regex change. I haven’t worn my regex hat for years.
Thinking in ‘regex’ is a strange thing. Leaves me goofier than usual for days afterward.
The more I stare at a little 12 character formula for the regex engine, that mutates the natural laws of the known universe, the closer I am to understanding what it is actually doing, instead of what I think it is doing, the farther from reality I get.
When I finally do understand what it is doing, I have a slight headache and I need a nap.
The person who wrote the original regex engine was obviously not human. Aliens walk amongst us.
You must be logged in to reply to this topic.