BuddyPress.org

You already know that,possibly,

but just to make it sure: You are Great, people.

WP to WPMU wasn’t hard at all, actually. I was really nervous taking my site from WP to WPMU but it went without a hitch.

BP for WP sounds sweet!

That message “Are you sure you want to do this? Please try again” is a nonce failure message. Did you upgrade and not upgrade the bp themes? All bp code is now ‘nonce security’ aware. If your themes don’t send these ‘nonce’ values to bp everything comes to a screeching halt.

For example:

<p><input type="submit" value="<?php _e( 'Save Changes', 'buddypress' ) ?> &raquo;" id="save" name="save" /></p>



<?php wp_nonce_field( 'groups_edit_group_details' ) ?>

That’s taken from the edit group details form. wp_nonce_field() creates a little hidden field with an access key for ‘groups_edit_group_details’ that gets compared in to a similar ‘nonce’ value generated in the actual function that does the validation and saving of group details. If they don’t match, the security check fails with that cryptic message from wpmu.

Have a look at buddypressdev.org, Nicola has already developed a plugin for that!

My guess is a directory setting thinks that the BuddyPress install is located in “http://nishinomiya.jp/” so it tries to hit “http://nishinomiya.jp/register”. But something also is weird with the blog, because it looks like clicking on “Blog” takes us to a page, that isn’t a blog. Can you still have your blog be a static page with BuddyPress and MU? I suppose you could eh? Neat!

Strangely, I can type “http://nishinomiya.jp/ebi/wp-signup.php” directly into the browser and get there just fine, sans any sidebars of course.

I’ve never tried to access that file directly, are you supposed to be able to do that? Ha!

I’m curious what his functions.php looks like…

The entire content for members pages is from the member theme itself. Without knowing what your specific question would be, the README for the member themes (creating your own) is a nice start to figuring out where the content comes from:

https://trac.buddypress.org/browser/trunk/buddypress-theme/member-themes/member-themes-readme.txt

Trent

What i’m concerned about is that every user can create his own blog. I’ll miss the possibility to limit the users storage or traffic. Would be great if the BuddyPress Hoster could offer a basic free membership (wich is limited somehow) and if anyone special needs more the hoster could charge him for that. I’m thinking of the concept of http://en.wordpress.com/products/

Is there anything like this in the pipeline?

Given that you are delaying the release of BP until site-wide plugins are introduced into MU, it might also be an idea to wait until the WP version is also ready.

Although as anxious as anyone to see the official release, it occurs to me that any project only gets one shot at it’s 1.0 release and all the publicity that attends it. That one-off burst of attention can make all the difference to how much traction you gain in the long-run.

IF BuddyPress jumps into the spotlight as an MU-only project, that’s obviously going to be of great interest to people already familiar with MU but the average blogger is going to scratch his head and not get much further than the fact that BuddyPress isn’t for “normal” WordPress. Disappointed, he will return to his extensive collection of porn and ignore all future mentions of BuddyPress.

If, on the other hand, BuddyPress appears in the spotlight as a dual-release, with both a WP and an MU version, it will garner far more publicity, will be more obviously relevant to ordinary bloggers and will generally create a far larger splash, hopefully translating into greater momentum for the project.

Just a thought

So do we have a realistic time line for BuddyPress for WP?

John, I’m thinking that the problem with nothing coming back is related to the bug you found with the password. I think that the bbpress side is sending the correct username but a blank password and the authentication is failing.

On the bbpress side the username and password are saved in meta data. I’m not changing the actual ‘connection user’ password. The same thing is happening on the bp side. sambauers is saving the username and password in meta data.

In this case the bug in my code checked the two passwords and saved an empty string as the password. It send it along to authenticate. It fails and doesn’t return an error message.

Fix would be to save the password again. Three times.

1) Change the password in the bbpress user maintenance screen for the utility user.

2) Change the password in the bbGroups config screen.

3) Change the password in the buddypress config screen.

We’ve got 3 passwords floating around and one is hosed. More than likely the one in my stuff.

It was a huge deal to get the multi-db plugin to be honest The only other project out there that has a chance so far would be the HyperDB plugin from Automattic. It gives you the chance to use replication as well as split databases up, but doesn’t come with an automatic blog selection by hash or anything out of the box. I personally am dealing with the huge single database until 2.8 is released.

Trent

bp-blogs/bp-blogs-widgets.php

Line 30:

<?php _e("Site Wide", 'buddypress') ?>

Most of the widgets are in the parent directory of their widget. Some of the core plugins are in the bp-core folder.

Trent

Supporting WP as well as WPMU will not slow down or change the development of BuddyPress at all. I just want to make that clear.

Supporting WP should (and will) be a matter of flicking a switch and continuing along the same roadmap. Most of that switch is already in place, the things I mentioned before are not really blockers, when all things are considered.

Well, i began working on my own theme, but not in the best way. I´m modifing the css files (by example, base.css) of the buddypress-home theme, to change the appereance of the pages. I just wanted to know if there is a tool or something that help me with this stuff. Because the API functions will not help me with my new theme (i think)

Looks like a duplicate in your oci_bb_group_forums_tags.php…

/**

* oci_xprofile_field_value()

*

* Return the specified xprofile field value

* Note: dates are in unix time format

*

* @param <int> $user

* @param <string> $group name

* @param <string> $field name

* @return <type> unknown

*/

function oci_xprofile_field_value($user, $group, $field){

$bp_user = oci_get_userdata($user);

return $bp_user['xprofile_' . $group . '_' . $field]['value'];

}



/**

* oci_xprofile_field()

*

* Return the specified xprofile field array

* Note: dates are in unix time format

*

* The field array is composed of:

* array(

* 'group' => group name string,

* 'name' => field name string,

* 'value' => field value string,

* 'type' => bp's name for the field type

* )

*

* @param <int> $user

* @param <string> $group name

* @param <string> $field name

* @return <type> array

*/

function oci_xprofile_field_value($user, $group, $field){

$bp_user = oci_get_userdata($user);

return $bp_user['xprofile_' . $group . '_' . $field];

}

Second one should be changed to oci_xprofile_field according to the doc above it.

Still trying to get the import to work…

When I uncomment the `

var_dump($groups_n_users); die;`

I get…

bool(false)

Still looking…

When I uncomment the `

var_dump($args); die;`

inside oci_bb_xmlrpc_query(), I get array(3) { [0]=> string(4) "dsoc" [1]=> NULL [2]=> int(0) }

dsoc is the name of my user, but it looks like the PW is empty?

So I uncomment the next line, and I get this…

string(5) "err: "

object(IXR_Message)#188 (14) {

["message"]=>

NULL

["messageType"]=>

NULL

["faultCode"]=>

NULL

["faultString"]=>

NULL

["methodName"]=>

NULL

["params"]=>

NULL

["_arraystructs"]=>

array(0) {

}

["_arraystructstypes"]=>

array(0) {

}

["_currentStructName"]=>

array(0) {

}

["_param"]=>

NULL

["_value"]=>

NULL

["_currentTag"]=>

NULL

["_currentTagContents"]=>

NULL

["_parser"]=>

NULL

}

object(IXR_Error)#187 (2) {

["code"]=>

int(-32700)

["message"]=>

string(28) "parse error. not well formed"

}

Now I’ve typed and retyped my PW twice. I can get post data from bbPress to BuddyPress, and I can post from BuddyPress and see it in bbPress. It’s communicating back and forth successfully…

Looks like it isn’t updating the PW to me for some reason… brb

K… Deleting the line from the DB and resaving the bbGroups options info, still makes the PW = NULL or nothing… Looks like it’s stopped saving the PW somewhere.

Thanks burtadsit. I’ll take a look, I’ve used the plugin before though and I’m not sure if it’ll achieve what I’m looking for.

Essentially the issue is that http://www.domain.com is a public website and we use http://staff.domain.com as an intranet (it’s just a members only blog).

What I’d like to do – although I haven’t yet investigated setting up BuddyPress as a closed system – is run BuddyPress at http://social.domain.com.

The problem is, when I do this is works perfectly except that it renders all links as though they’re from the top domain.

So, as jedbarish mentioned, none of the following links work:

* Home

* Blog

* Members

* Groups

* Blogs

As instead of going to http://social.domain.com/blog they point to http://domain.com/blog which yields a 404.

When I do the $burt variable debug trick, it looks like http://delsolownersclub.com/discussions/xmlrpc.php is pulling a 404 again like it was before over here https://buddypress.org/forums/topic.php?id=426, but it’s very clearly there, and nothing else appears to be in the way.

Arg… Still looking…

Arg… It broke somewhere before I even was playing with this.. I reverted everything back to the previous version (.23 I believe) and while I can get forum post info, for some reason I can’t post anything.

lol Oh Ren… haha!

@brandtd, this is certainly possible. As a matter of fact, this should happen as default unless you change the width of the body or html elements themselves. This is because the “Buddy Bar” isn’t contained by anything that has a relative position attached to it.

In bp-core/css/admin-bar.css – Try…

#wp-admin-bar {

position: absolute !important;

top: 0 !important;

left: 0 !important;

width: 100% !important;

z-index: 1001 !important;

height: 26px !important;

color: #fff !important;

text-align: left !important;

background:url(../images/admin_bar_back.gif) #818181 repeat-x !important;

}

@brian, duh I get what you’re saying now. If I can give some feedback about the Buddy Bar for a moment, I feel that it should be an all or nothing kind of deal. Either it’s always there for people to use, or it’s never there and people have to naturally find their profile area and do things from there. Toggling a whole new set of what are essentially just short-cuts and adjusting the entire layout of the screen, even if by 26px, provides for a moment of awkwardness from a user perspective. For the 3 seconds it takes for someone to think to themselves “Hey what’s that? Do I need it? What does it do? Oh gosh there’s tons of menus now? What is this stuff?”

Now if you’ve used WordPress.com or signed up for a Gravatar before, then the bar idea isn’t new. But for what I consider the core crowd we’re catering to by using BuddyPress as a social networking platform, if it isn’t uniformly worked into the design of the site from the beginning, it only serves to confuse.

Again, this is just my opinion. Not saying it’s right, and certainly not saying that there is a better way. Just saying…

/rant

Back on topic. In theory you could put a…

<body>

<?php if (is_user_logged_in()){ ?>

<div id="buddy-bar-buffer"></div>

<?php }?>

In your header file, and attach the CSS to that, rather than to the body itself? That would then only show that buffer when the user is logged in, and once they are logged in, that buffer will push the body down (as styled by the CSS you will give it in your base.css).

Does that make sense?