[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Yeah, that’s probably a bad idea later on…

I guess I would have not seen the harm in an archived, no longer active user having an empty BP profile page. Matter of fact, if they didn’t have a display name set, they wouldn’t show up in the members directory anyhow, so they’d technically be invisible until someone clicks their name when viewing one of their archived posts.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Np. Gonna green light this one.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Is it possible that your host automatically re-routes subdomains for you, rather than allowing them via a wildcard? Or that your .htaccess file is bouncing things back?

I’ve seen some installations where if the server wasn’t configured for subdomains, that the subdomain was put through the URL as a _GET or _POST variable.

When you create a new user/blog, does the blog actually get created? If so, can you navigate to ANY blogs or do all of them bounce back like that?

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

The pages you’re getting are 404’s from the forums, from using deep integration without tricking the header into submission.

The bp.org site will get some more TLC in the coming months, but for now we’re focusing efforts on BP fixes and patches.

Thanks for the heads up though!

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Hard to say? If that file was out of place, it’s possible there’s others? Or maybe a plugin that’s gumming things up somewhere? Usually the best way to trouble shoot this is to start removing plugins one by one and see which one is causing the conflict. If you have no plugins and it’s still white screening, then it’s usually a bad installation from the start, a memory issue with the server, or a PHP version issue; the last two you only have so much control over.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

I second what DJPaul said. :thumbup:

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

So you get the blank page, but this error shows up in your logs? Looks to me like something related to taxonomies is getting triggered, as that kind of query only shows up in /wp-includes/taxonomy.php.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Looks like you put a file in the wrong place somewhere down the line. If this is a new installation then there shouldn’t be any file in your mu-plugins directory named blogs.php.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

chrisknade, those two functions don’t really work together to give you anything that you could compare and get any real value out of.

I won’t quote anyone else, but I’m curious too..

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Have you created a page in your root MU blog called “forum” by chance? Also, it kind of sucks but because bbPress pretty permalinks use “forum” to tell the URL that you’re clicking a forum, having your URL be domain.com/forum/forum/name-of-forum is the reason why most people install bbPress in “/forums/” or something else like “/support/” or “/discussion/”

What I’m saying is that it might just be that bbPress or WordPress are getting tripped up on what the redirect is, and maybe conflicting somehow?

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Basically, you need to bang your head against it for a few more hours and figure out what exactly isn’t perfect. Something is out of alignment, and we can’t really tell you what without looking at it for you…

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Burt Adsit made a plugin called bpGroups that was able to consolidate the essential user data, but with recent changes to XMLRPC, BP, and bbPress, my guess is that plugin no longer works as expected.

To be honest, WordPress has never really been “light” if you know what I mean, at least not like bbPress is. If you’re using the BuddyPress Group Forums, then you probably have a lot of userdata already available from previous queries in the loop. If you’re using bbPress only and trying to get specific userdata or xprofile data, that’s going to usually require some expensive queries to pull off; I would look at how bbPress already does it with userdata per post, and see how it’s able to to do it. Chances are it’s already been called or that the userdata has already been grabbed previously. If you don’t use an IDE like netbeans to trace variable values, then try a print_r or var_dump of the user variable in the loop, and see what it gives you.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

You will need to activate the BPHome theme as your main theme for your site.

Site Admin->Themes, activate BP Home, then make BP Home your current active theme for your root blog.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Yep that’s exactly the problem with subdirectory installations, and why MU is best left as the center of your entire website. The /blogs/ url is hijacked by BuddyPress, so nothing else can live inside of it; same with /members, /groups, and probably eventually /forums too, once there’s a directory for them also.

kengary, if you plan on having another site at the root of your installation, have you considered using another MU blog as your root blog, and using BP on something other than the root? Or, having your root site not center itself around the BP installation or theme, and just page-out the specific BP pages that you want/need?

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

This depends on where you are calling the query and what other information might be available inside of that loop or template tag.

If you’re calling that function for each author every time something happens then for each unique author it is hitting the DB with another query, and in my opinion that’s always something to worry about.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

lynnallan, you could simplify that kind of setup further by using the multi-site plugin for WPMU, which allows you to map multiple domains to specific WPMU blogs. This way you can still keep a single unified login between all platforms.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

It’s important to note that BuddyPress is an opensource project, just like all of the other WordPress related ones. That being said, if you find something isn’t working up to your expectations you are free to develop or contribute to the project to make it work how you wish. As it stands today, BuddyPress does a good job of keeping tidy and cleaning up after itself; better than most plugins in my opinion. The signups table is specific to MU and is a new addition, so you can expect it’s functionality to be misunderstood. When a user is deleted, the idea is that their signup remain in the signups table as proof of their previous registration. One could even argue that removing all user data is a bad idea in the event someone ever needs it later, say for law enforcement purposes.

Regarding blocking spam registrations, read some articles about Twitter. Some analysts have said that nearly 50% of all registrations on Twitter are spammers. Crazy eh? There just isn’t a fool proof way to prevent it from happening unfortunately.

Also, while none of the moderators are directly employed by Automattic, it’s about the best internship I think anyone in our respective businesses can hope for. We all do our best to represent Automattic and are here to help to the best of our abilities.

If you can find a specific bug or flaw in how users are currently managed between BuddyPress and WordPress, you’re welcome to respond here or file ticket in the trac. If you feel your opinion warrants more attention you can message me privately if you’d like also, and I’d be happy to help further.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

If you want all of the directories to be underneath the community page, I would do exactly the same thing you just did to make the community page, and make members/groups/blogs directory pages. I’m not sure there’s a way to contain ALL of BuddyPress within a subdirectory, considering that your users and groups and blogs are all linked off of the root of the site, and not the root of a specific blog, subdomain, or subdirectory.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

As enthusiastic as you are about WordPress, most of us are about BuddyPress, so without speaking for anyone else, my opinion is biased towards using BuddyPress for every website. My moms knitting website will use BuddyPress.

If you want users to be able to blog about their own stuff without moderation, then you want WordPressMU, because each user gets their own blog to talk about whatever they want; WHATEVER they want. That means even though your site is about fashion, that doesn’t stop them from talking about puppies.

If you want these users to be able to interact with each other, and have personalities, then you want BuddyPress.BP will allow your users to talk to each other privately, form groups to talk about things with each other, and comment on each others profiles.

The reasons NOT to use BuddyPress? At the moment there’s very little restrictive control over what people do. You can’t stop someone from putting profanity in their profile. You can’t block a user from messaging you or others. Also, the platform is still evolving as much as WordPress and bbPress are. That means that if you like to keep your website on the cutting edge, you’ll find it hard to install everything and leave it alone, as enhancements and improvements are coming through at least monthly, and so far upgrading isn’t a one click thing yet (almost though)

Those is my opinionses… Not sure how helpful they is, but if you like WordPress, you will probably see the potential of BuddyPress for what you want your website to be.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

2.8.1 is probably installed, but there is a bug in it that is causing that message to still appear. It is fixed in the MU trunk and 2.8.2 is coming soon.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

I’ve used this website before as an example and I hope he doesn’t mind, but check out leadpress.com as an example.

You’re not running BuddyPress in a sub directory, but actually just stopping it from taking over the root and /blog URLs, and instead using the normal WordPress way of assigning pages.

Rename home.php to community.php.

Use the Page Template method to name that page template “Community.”

In the blog admin, Make a page for your home, a page for your blog, and a page for your community, all with similar slugs.

The community page will use the “Community” page template.

Goto your blog settings and assign the front page to be the page you made for home, and make the index/blog page the one you made for your blog.

Then, you will want to install bbPress in a folder called “/community/forums/” and be sure to create a page with the slug “forums” as a sub page of “community”

That should do it?

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

I find strange things like this happen if I FTP a file directly from inside a zip file, rather than unzipping it and uploading it.

It’s a good feeling when the arm flailing and panic file replacement works out.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Using 2.7.1, manually digging into phpMyAdmin and editing the wp_signups table is the only way around it. Not going to lie, I’ve had to do it once or twice myself.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

This is actually more tricky that it sounds, because BuddyPress by default stores most of its information in the blog ID = 1, and it will ignore most other constant settings. If you are installing BuddyPress for the first time, and change any of the BP_ROOT_BLOG or BLOGID_CURRENT_SITE or SITE_ID_CURRENT_SITE variables, BuddyPress still saves most of its information in blod ID = 1.

https://trac.buddypress.org/ticket/823 references this issue, and I’ve included a patch for the instances where this occurs.

lynnallan, I’m afraid there isn’t a core solution for what you want to do yet, but the patch in the trac ticket *should* better prepare BuddyPress for this type of installation.

My only other suggestion, would be to think of it as WHERE the data is in the database doesn’t REALLY matter, unless you’re trying to split server load up across multiple database servers. That being said, you can install your corporate theme on your root blog, and then install the bphome theme on another blog, and then use the WordPress page template ability to recreate the look and feel of a BuddyPress on a blog other than the root. This is kind-of how http://leadpress.com/ has their site setup, if you need an example.

[@johnjamesjacoby Keymaster 17 years, 3 months ago]

Rename the buddypress directory to something else. That will force it to deactivate and you can trouble shoot your installation from there.