[@johnjamesjacoby Keymaster 17 years, 2 months ago]

I think the white pages identify BuddyPress as giving users a clean slate; something that can easily be built upon.

“BuddyPress: Bear friendly, and no regrets.”

LOL I actually got a white screen when I went to post this.

My guess is it’s a server/user issue; probably getting overloaded as BP becomes more popular. I know that Google is probably indexing the heck out of it, because Googling my name comes up with a TON of BP links.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

At lriggle; Your first issue sounds more like a cookie issue between BuddyPress and bbPress. Logging through bbPress isn’t giving you the correct cookies for WordPress/BuddyPress to recognize you as logged in. You’ve got some kind of one-way communication going on, and that can be hard to track down. Start by checking your bbPress integration settings and go from there?

The second issue is just a login screen thing. If you click the login link on the buddybar anyways, it will just direct you to the WordPress login page, which will dump you back at the blog root by default. There are other redirection plugins for WordPress and WPMU that will help with this.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

Aye; it’s happening for everyone all the time randomly. My guess is the appropriate people wearing the right hats are already working on it.

P.S. – All browsers; Vista 64, random white screens fixed by refresh. Happens with all actions (posting, editing, and just viewing pages and posts.)

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

At the moment there is no access control that determines if a is_site_admin() overrides anything; but Jeff’s working on that component now to provide granular control over BP objects and who can see/do what.

I think that different websites will have different needs regarding things like this, and custom functions/hooks/actions can be created to allow for this if you need them. Example being that currently site-admins cannot edit user xprofile information, but some sites might really want that ability… Same with private messages, etc…

If you need some help looking for a hook or filter or action to tap into, or a function to recreate on your own, we can discuss that in this topic as I imagine others might want something similar for their own use.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

To summarize, the new theme structure includes a skeletal framework right away to start, that allows other themes to inherit the styling of BP HTML, CSS, and AJAX if you choose. It answers the age old “How do I get my child themes to look like my root theme?” question right off the bat. It also answers most of the “How do I port my existing theme to look like BP?” question too, but some adjustments will need to be made to make it look perfect. It also means that as new BP core features are developed, the BP default framework is updated as well, allowing your child themes to tap into the new HTML, CSS, and AJAX without any modifications to themselves. Neat eh?

What this REALLY does (in my opinion) for theme authors, is it puts EVERYTHING that the WHOLE website will need to look and work correctly in 1 convenient theme folder; with the option of subdomains having their own template files override the root if you as a site admin so choose. You can inherit the header.php and footer.php, but change the single.php and category.php if you want to. Or say that one subdomain gets blue links, and the other gets orange; a few changes in the style.css and you’re set for that child theme.

It’s just awesome and the anticipation of how people will use this is killing me.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

What you’re experiencing now sounds normal considering how it’s currently programmed to be.

BP1.1 fixes this with a patch similar to mine.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

In the current stable version of BuddyPress (1.0.3) changing the root blog from 1 to anything else still works in a few funky ways. There is a proposed fix for this (from me) in the trac but it is pending more bug fixes for 1.0.4 (which may get trumped by 1.1 at this rate.)

Basically what I imagine is happening, is that when users sign up, they are given access to the dashboard blog like you specify, but they are given the contributor rights to blog_id = 1 because BuddyPress assumes “1” instead of BP_ROOT_BLOG.

Basically, you’re stuck for the time being. You can apply my proposed fix but it’s pending testing and review so I’d suggest not using it live if you can help it.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

For a private setup, or one that you won’t be reusing for another client, what I do is create a hidden group and invite the special users into it. When they accept the invitation, you can then build your plugins around checking for people being in that group.

Something simple like…

<?php

define('SPECIAL_GROUP', $your_groups_id);



function is_user_special ( $user_id ) {

if (!$user_id) {

$user_id = bp_loggedin_user_id();

}

if ( groups_is_user_member($user_id, SPECIAL_GROUP) ) {

return true;

}

}

?>

…usually does the trick for me?

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

Provided you have wildcard subdomains allowed in your installation, then yes this could be possible with some modification to both BP and your .htaccess rules. Similar to how http://support.wordpress.com/ works with the forum as a subdomain in addition to user blogs being subdomains too.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

Are you using deep integration?

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

The way this works is actually really super easy and very, very awesome…

There are a few different variations of ways to do this, and I can see some really imaginative uses of this method doing some really fantastic and super awesome things, so if you’re not already, I suggest you get excited…

I think the way that most people will use this method is with the included BuddyPress Framework theme as a jumping off point. Think of it as the HTML and bare-bones styling to get your site’s root blog and BuddyPress profile/directory pages up and running. It includes all of the normal files you would expect from a typical WordPress theme (single.php, comments.php, page.php, index.php, home.php, attachments.php, etc…) plus it includes all of the theme files for BuddyPress registration pages and components in their own respective folders similar to what bp-member did.

Currently, parent/child template relationships do NOT include the parent template’s style.css, so if you’re making a child theme, you will need to manually include the style.css of your parent theme with an @import rule, but it takes 2 seconds to type in so no big deal.

So that means that your parent/child relationship is really only for .php files until you manually @import a CSS file from another directory.

To answer your question about multiple parent themes, yes and no.

Lets say we have three themes: bp-framework, bp-default, and bp-child.

Each theme/template can only name off one parent, but that doesn’t stop the parent theme/template from having its own parent also. Example: bp-child could name bp-default as its parent, and bp-default could name bp-framework as its parent, and they will recursively overrule each other down the parent/parent/child ladder with the current template winning at the end.

This works well in situations where you might not need a home.php for your child themes. Home.php is a WordPress file for hardcoding the landing page of your blog, and maybe child themes don’t need one. In that case, move home.php into a “bp-home” folder with a style.css that makes the bp-framework its parent and includes the parent style.css, assign bp-home as the theme for your root blog, and you’re done. This way the other blog themes won’t have a home.php for no reason.

Because of this, it’s possible to have themes inherit from multiple other themes if you plan ahead in such a way that allows for this. My experience with this idea and creating my own framework is that it takes a little pre-production planning, but it pays off big time later on.

The other crazy fluke is that parent themes don’t need to be active in the Site Admin area. This means that you could have child themes active for users to select without allowing them to select the parent theme, and still have the parent theme’s files be accessible to the child. This really gives you a better way to control the themes that users have access to and how they work with your custom framework to keep your header/footer/other files in sync.

I personally can’t wait to see what some of the more popular WordPress theme guru’s are able to pull off with the next version of BuddyPress.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

I used Burt Adsit’s BPGroups plugin to achieve this a few months ago. It helped to pull all user data over and transfer the XProfile data into a deeply integrated bbPress installation.

In future versions of BuddyPress this will be much, much easier.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

A majority of the registration protection you would want to do currently comes from the WordPress side of it; captchya’s and what-not.

I’ve seen it happen on a few BP sites I’ve done for clients already. Seems to come with the territory unfortunately.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

Andre Tan, I suspect the issues you’re having are related to shared hosting + the XMLRPC interface for including forums into groups. Future versions of BuddyPress will not have this problem as it includes bbPress and references it directly going forward.

It may still end up being a little heavy on the server, but you should experience the random load issues that you are currently.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

BuddyPress has functions to get most of the data that you need without globaizing the $bp. I think different people will give you different answers about globals, but the general idea is that the less you use them is the better off you will be.

BuddyPress wraps most of the return/echo functions for most content in the -templatetags.php files for each specific component. If you need data that isn’t available, you can always build your own function in bp-custom.php or whatever.

If you look at the built in BP functions, you’ll see that $bp is globalized a lot in those functions, so the answer to your question comes down to the nuts and bolts of how PHP operates deep within the core of it, and how globals are processed on a per library basis and at what point in the process it occurs.

Long story short, if it gets you where you need to be safely, it’s probably fine enough unless you notice a slow-down or something.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

Yeah this is more of a WPMU question really. It does its best to hide the deprecated www. from most URL’s if it can help it.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

Seems most people that were previously loving the FaceBook/WordPress bridge have shifted their attention over to RPX as a better alternative for allowing users to register and login from anywhere.

Regarding the FaceBook Connect plugin (and most others really) someone will usually come along and take it over when they have a personal need that is bad enough to do it. Tends to happen with most abandoned projects as time goes on.

I’m sure Andy will chime in as to whether or not he plans to support it going forward.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

Maybe the current discussion isn’t out of date, but the discussion and assumption that Nicola is developing this is.

I can’t speak for DJPaul, but in the general clean-up that I do, I try to keep the conversations as focused on what is currently relevant as possible, to avoid confusion for newcomers and to let any old-schoolers know questions are being addressed.

Does that make sense? I’m sure Paul will chime in and slap me with a trout if I’m wrong.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

No idea what’s happening, but my advice would be to disable all plugins, check and recheck the existence of all of the BuddyPress files in their correct locations, and try again?

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

Yeah it’s a webkit browser issue, happens on Chrome also. BP.org is going to get some attention when 1.1 comes out, as the forums integration is going to get a facelift, etc…

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

Yep. It works really slick and does exactly what it sounds like you want it to do.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

So far so good here, at least with the latest trunk version. I imagine BP1.0.3 will react the same as it did to 2.8.2.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

If you’re using a custom theme, you’re going to want to copy the code from the bphome functions.php into your custom theme, otherwise none of the BP specific virtual pages will exist.

[@johnjamesjacoby Keymaster 17 years, 2 months ago]

You need to have the WordPress language files in wp-contents/languages first, before WordPress will give you the option of changing the site and blog languages to something other than default. Once you have the files there, set your Site Language in Site-Admin->Options, then set your blog language in Settings->General.

Basically BuddyPress will follow whatever WordPress MU is set to do, but it cannot tell it what to do (yet).

WordPressMU has a specific way of handling language settings that involves a function that overrides the typical get_locale().

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

They’re on the way in a very basic, text only form. Check the trunk version if you’re curious, but right now the trunk is getting some big changes so don’t count on it working 100%.