BuddyPress.org

@Frecking Wildchild: The problem with qTranslate is currently being addressed, kind of. Let’s hope these issues aren’t because of another URL re-writing plugin.

qTranslate also won’t play nice with BuddyPress because of a few issues I addressed in a recent BuddyPress core patch. I’m using qTranslate for a multilingual project I’m working on that also uses BuddyPress, so I’m learning the ins and outs of qTranslate as I go also. I’ve modified it to work as a site-wide plugin similar to BuddyPress, and I’ve created a patch/plugin to allow users to specify their default language in their user preferences.

BuddyPress won’t play nice with a whole lot of language switchers or URL hi-jackers yet, but it will as improvements are made to the core.

Well, a component can be considered a type of plugin similar to any other WordPress plugin, except instead of hooking into WordPress alone, it’s hooking into BuddyPress AND WordPress.

Widgets are accessories, more or less. They aren’t 100% necessary, but most people welcome them as they’re an easy way to include whatever content it is that your plugin is supposed to spit out, on whatever pages that someone has enabled widgets to be displayed on.

A new component is needed when BuddyPress simply doesn’t have the capability that you want or need. The two next components currently in development are status updates (think twitter) and photo albums (think flickr.) Those are functionalities that don’t currently exist in BuddyPress.

Now both of those components may/will have their own widgets also, to do different things. The status update widget may incorporate the ability for the blog author to update their status from their blog, or it might display x amount of recent updates, or both. The photo album widget may include the most recent x photos, recent photo comments, etc…

In the case of BuddyPress, most widgets will come as part of a component. The component will bring in new functionality, and the widgets will allow that function to be displayed without knowing any HTML or PHP.

@WillPCG & Sgoetz: Do you got qTranslate installed by any hand? If so, check out the post at https://buddypress.org/forums/topic.php?id=2693#post-14750 which is started especially to this 404 problem caused by qTranslate.

@JeffSayre: It’s a glad thing I can mention the sunrise plug-in works perfectly with Buddypress as before; it was qTranslate which seemed to be the culprit.. So we’re already a step closer to the solution (as mentioned one post above) …

Thanks for the extensive help though, since development and problem-solving starts with ruling anything of special parameters out.

I guess qTranslate was very special and overseen….

ps: Do you have any idea why we both are marked “inactive” on the forums? I don’t feel idle at all :p

@all: I’ve found the culprit of the entire 404 soap which has been terrorizing my screen the last few weeks (smashes drums): It’s Qtranslate!

Any of you having the same problems while qtranslate is installed? Check out the topic at: https://buddypress.org/forums/topic.php?id=2693#post-14750 which is started especially to this solution.

Bryan868, the short answer is there are some larger changes in the WordPress.org 2.8 and 2.9 pipeline that have been strongly hinted at recently. Those changes won’t make their way into WPMU necessarily at the same time, so we’re mostly safe for now using WPMU.

BuddyPress will continue to get updated as WordPress versions change, however because there are a lot of dependencies there, and lots of distinct differences between a .org install and an MU install, it isn’t just flipping a switch and making it go.

It is going to happen, just not as soon as most people wish unfortunately. Hopefully everyone that’s salivating at the chance to open up their own .org sites to start adding friends and making profiles can understand the dev process and try to be patient.

I know it isn’t exactly what everyone wants to hear, but it’s the straight forward truth of the matter as it stands today. It may change tomorrow, but that’s where it is now.

yup… my bp-custom.php file wasn’t loading. Once I moved it out of the buddypress folder and into the plugins folder the language change worked… anyone know why that is?

Why not anytime soon?

Misterfunk74-

Posting a new request for support in a thread that is marked resolved is not the best way to get help. Why? Because those of us who offer help tend to skip over resolved posts and look for threads that need our attention.

If you’re still having an issue, then please start a new thread. Here are some support guidelines to get you started: https://buddypress.org/forums/topic.php?id=2676

From your admin dashboard

– Select BuddyPress from the left sidebar

– Click Profile Field Setup

– Setup your profile fields

Users will then be prompted to fill in this info when they signup

Bbn-

Rather than trying some fancy install via packaged tarballs, I’d suggest a plain, simple install from scratch. Even though you went back and, as you state, “tried to do a more careful replacement of the files,” try a clean-slate install.

Delete everything, including your MySQL DB–assuming you don’t have any important data. Then, download and install WordPress Mu 2.7.1 from here. Get it working before attempting to install BuddyPress.

Once it is working, download BuddyPress and follow the readme.txt instructions.

Looks like this is happening to a lot of sites

I understand your frustration. But, when I search Google for “Failed+opening+required+’BP_PLUGIN_DIR”, I can count exactly 6 actual sites with this error and then several comments within blog posts that indicate the same issue.

Combine that with the half a dozen reports in the BP Forums for this issue, and you get maybe 15 people–assuming none of these people have commented in multiple places. That is not “a lot of sites”.

Okay, never mind, I’m a moron! I had not activated the Buddypress plugin.

I ran into this same error message this morning. In case it helps, here’s how it happened to me.

I had MU 2.7 installed on a ubuntu server and MU 2.7 also installed on a local dev installation of ubuntu (both 8.10, if that matters). I upgraded the dev MU to 2.7.1, then installed buddypress. worked great. then I tarred up the dev installation, copied it over to the server, and overwrote the old 2.7 MU non-buddypressed install with the dev files. Ran the upgrade (at http://veryhandso.me/wp-admin/wpmu-upgrade-site.php). Tried to preview the buddypress theme and end up with the error mentioned above.

I then backed up and tried to do a more careful replacement of the files as outlined on the upgrading wordpress page (https://codex.wordpress.org/Upgrading_WordPress). Still no love.

Thanks for any help. Grateful newbie.

Ben

Codyb-

Excellent!

So there was a rouge .htaccess file gumming up the works. Those dang invisible files are tricky!

I had the same issue is this bug https://buddypress.org/forums/topic.php?id=2664&replies=19#post-14700

and I ended up finding the solution. Go to that bug and see if it helps

I had the same issue is this bug https://buddypress.org/forums/topic.php?id=2664&replies=19#post-14700

and I ended up finding the solution. Go to that bug and see if it helps

If group pages were group-editable… this would be extremely useful for people who’d like to use BuddyPress as an Intranet / collaboration tool. Buddypress is great but it’s mostly just about community… not sharing files, content, photos, collaborating, etc. Now that 1.0 is out though… I’m sure a lot of this will be coming in time… either via plug-ins or new core development.

Ahhh… The truth, shall set you free…

Any possibility that the Drupal install is mucking this up? I’ve got no experience with that one.

(To explain what’s going on, this isn’t a matter of directory structure, because those directories are virtual; they don’t really exist anywhere. There is no physical folder anywhere in your install called “members” or “users” or anything. The URL is caught by .htaccess and WordPress, and is virtually re-written to match the content it is displaying.)

Does that make more sense? I know it’s hard to understand and have faith in at first, but I promise it’s totally fine.

Cyclzone,

You need to edit core BP files to accomplish this. I’m not sure how this will effect overall BP performance, though.

First thing to do is locate the file “bp-core-catchuri.php” in /buddypress/bp-core/. Open it up.

You’ll want to comment out lines 36 and 37 which look like:

if ( BP_ROOT_BLOG != (int) $current_blog->blog_id )

return false;

Next, you’ll want to change line 92 to read like the following:

if ( ($bp_uri[0] == BP_MEMBERS_SLUG) || ($bp_uri[1] == BP_MEMBERS_SLUG) || in_array( 'bp-core-ajax-handler.php', $bp_uri ) ) {

That should do it.