BuddyPress.org

We’ve installed buddypress + wordpressmu on our server. We’ve also installed RPX module foe WordPress. It’s working fine for login and allows user to login without sign up.

But we want to have it on sign up screen and replace the existing signup process with RPX and redirect the user to custom welcome page. Is there any work around for it?

Codyb and John James Jacoby

I read through https://buddypress.org/forums/topic.php?id=2664&replies=19#post-14700 and noticed something…

The first two lines in my .htaccess file is different to that explained in the post. Also, the “RewriteBase /” is missing the “wp/” at the end. I’m hesitant to delete the file like Codyb did unless you guys think it’s OK to do.

My .htaccess reads:

AddType application/x-httpd-php5 .php

AddHandler application/x-httpd-php5 .php

RewriteEngine On

RewriteBase /

#uploaded files

RewriteRule ^(.*/)?files/$ index.php [L]

RewriteCond %{REQUEST_URI} !.*wp-content/plugins.*

RewriteRule ^(.*/)?files/(.*) wp-content/blogs.php?file=$2 [L]

# add a trailing slash to /wp-admin

RewriteCond %{REQUEST_URI} ^.*/wp-admin$

RewriteRule ^(.+)$ $1/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule . – [L]

RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]

RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]

RewriteRule . index.php [L]

#<IfModule mod_security.c>

#<Files async-upload.php>

#SecFilterEngine Off

#SecFilterScanPOST Off

#</Files>

#</IfModule>

John James Jacoby

I found the error logs section and the only entries are the following:

[Wed May 13 03:49:22 2009] [error] [client 66.249.71.46] SoftException in Application.cpp:544: Directory “/home/bucksboa/public_html/wp-content/plugins/buddypress” is writeable by group

[Wed May 13 03:49:18 2009] [error] [client 66.249.71.46] SoftException in Application.cpp:544: Directory “/home/bucksboa/public_html/wp-content/plugins/buddypress” is writeable by group

Doesn’t mean much to me. Sorry, I’m a novice… but on a steep learning curve!!

@Kunal17

Is the bp-custom.php file something that I download or create?

You create it yourself, and place it in “/wp-content/plugins”.

What is the ‘mysite’ language translation as defined in the tutorial?

That is a sample definition that I used for the tutorial — you can use whatever you want. Just make it a label that makes sense to you and your site.

Still wondering about the command to convert .po to .mo. How is that run and from where?

Running that command requires that your web server have basic GNU gettext support — if you don’t know if it’s supported, ask your host (it’s pretty standard on most Linux servers).

Running this command also requires command line access to your server via a program like PuTTY (Windows), Terminal.app (Mac), or from inside an FTP program and requires that your server support “msgfmt”. If you do not know how to run commands like this, or don’t have command line access to your server, please see Translating WordPress for other software options for converting language files (like Poedit).

@Craig dean

Also not understanding the conversion of the po. to the mo. using the run command. Is it a ftp app command. Just not sure.

See me answer above. I also updated the Codex page with these notes.

@Mstoppay

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?

Yes, as of BuddyPress 1.0 the “bp-custom.php” should be placed in the “plugins” folder instead of inside the BuddyPress directory, as noted by Andy in this thread. Thanks for the reminder — I updated the Codex page to note the correct location.

Note also that if you use the “Automatic upgrade” option to update your BuddyPress install, make sure to backup your language files first since they could be removed during the upgrade process (see this thread).

I’m developing a customised buddypress member theme and a directory view special for artists, musicians and multi media interested people.

This is my fun learning project to get deeper into wordpress and buddypress theme design and plugin development.

The hole website is still in beta mode. So don’t aspect it to work 100%

http://rheinrauschen.de (In the moment just firefox ie will come al last)

I will give the theme and plugin’s step by step to the community.

For this I have to wait for some bug fixes, the stable bp-events component. Better forum integration and many more….

Thanks for the report.

Proves once again that BuddyPress alone works fine, but sometimes plugins don’t play nice.

So far WP Super Cache and qTranslate are the two white-screen causing culprits in the past two days.

@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