BuddyPress.org

I went to your site and I see what it is doing. I have no idea why though. I did notice that you’ve installed mu with the subdirectory option and you are running the bp home theme on your ‘sajjadkhan’ blog. I don’t know what that would have to do with it but try selecting a different theme for your other blog.

The error msg looks like you have the bp home theme in /wp-content/member-themes

Got me.

It doesn’t look like you have things configured quite right yet.

The bp home theme shouldn’t be in: /wp-content/member-themes it should be in: /wp-content/themes

The bp member theme should be in: /wp-content/member-themes

What is confusing to me is that it’s reporting an error looking for *anything* in /wp-content/member-themes/buddypress-home/. That directory path doesn’t exist. Shouldn’t exist.

Those errors are normal. Normal? Well, everybody has them for the moment. Nothing to get excited about. The URLs for the menu items you are having problems with are launching stuff in the member theme.

Double check the member theme installation. Should be in /wp-content/member-themes/(stuff here)

Any custom code in your bp install?

Is wpmu 2.7 out now? Your site says its running “WordPress 2.7” not “WordPress 2.7-RC1-xxxx” like everyone else. The site in your profile must not be the site you are talking about.

Anyway, the dreaded “white screen of death” probably means you have some errors and it’s just not showing you them. Check your php and apache error logs and report back.

Sounds like the bp member theme is crashing for some reason. Do you have *all* the bp components installed?

The member theme isn’t something that you can activate and use independently. It is exclusive to bp. It’s not a normal wp theme. It has no value outside of bp.

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.

how can we make the home theme to redirect the social networking part. I too want to make the social networking stuff under one link.

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:

https://trac.buddypress.org/ticket/223

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.

Posted a ticket (without a fix yet, sorry Andy)

https://trac.buddypress.org/ticket/223

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.

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

Well, WP 2.7 officially released, but WPMU 2.7 should be close behind.

WPMU 2.7 was just officially released.

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.

Trent

Did you move the member theme out of mu-plugins to wp-content? Also, the member theme does not need to be activated. Nor should you. I shouldn’t show up anywhere in wpmu.

EDIT: whoops. dup post due to operator misuse of the browser back and edit post buttons

testbp.org is running ‘WordPress 2.7-RC1-10119’

my dev machine is running ‘WordPress 2.7-RC1-10145’