BuddyPress.org

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’

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?

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:

@import url(css/loader.php);

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?

I have the same problem on trunk r646. No members page. Everything else seems okay.

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.

Move the buddypress-member theme from wp-content/themes/ to wp-content/member-themes/

Well, a good place to start would be the widget code itself.

Let’s take the ‘archives’ widget as an example. I look at the widget code in: /wp-includes/widgets.php for the archive widget function: function wp_widget_archives($args), I see that it extracts the stored widget options and then eventually calls the template function: wp_get_archives(‘param=xxx&param=yyy’). The widget is just a wrapper for the template function that allows blog admins to set the behavior of the template function that does all the work.

We need to pull the guts out of the members widget and create a template tag that does the work by parameters only. Looking at the archive widget again I see some code that sets up defaults, parses the passed args and then turns the args array into vars with extract().

We could also just modify the widget to parse and actually pay attention to passed args.

In any case did I mention that ‘We don’t need no stinking help’. (that was my best Mexican bandito accent). I forgot you are Italian. That was a reference to a Western movie. Never mind. I gotta go play with something else right now but I’ll return to this.