BuddyPress.org

Hi Paul,

I did in fact contact my host, and they told me its an issue with BuddyPress and not a hosting issue. Its true of course, so really there is nothing I suppose that can be done.

I did want to ‘go off’ about this a bit. You can just skip over the following few sentences as I know its not your job to manage or work with Buddypress and that you’re just trying to help me out. For which, I am greatfull. Very much so.

First of all, I love BuddyPress. I love everything about it. The concept, the way its built, the impact it could have and should have. I was so freaking excited about this release I left work early to install it.

Having said, that, what is it with the BuddyPress team, and their leadership?  Buddypress is the future of WordPress, or at least a huge chunk of it.  No other plugin would be released or if released, used, if the person downloading that plug in had to access and touch 3 and 4 files, examine the database and make a trouble call to their host. Are you kidding me/us??

I know there are great people working on Buddypress, but releasing something this vital, this cool in this state is just ‘WordPress abuse’ in my view.

Fix the thing so that its installation matches the rhetoric of ‘easy install’ or ‘tested’ or what ever. Or change the darned rhetoric to say ‘must know how to modify files and databases and be willing to spend the time to do it’.

But ‘break the users site as soon as its activated’ and then tell the user to ‘fix it yourself’, is just not cool. And it really really p’os people too.

Thanks Paul. You’re great for having gotten this far in my note.

My question is, how is your plugin supposed to handle the integration. What is the correct way to remove the sidebar from the member profile only, on an MU site running twentytwelve.

wp-content/themes/child-theme/buddypress/buddypress.php
the above does not work. @hnla

wp-content/themes/child-theme/buddypress.php
the above does not work. @r-a-y

So if you could point me to the solution that 1.7 addressed that would be great. Thanks

Respect is EARNED. There is NO excuse for poorly written, sloppy, incomplete, often confusing, misleading instructions. While I’m new to Word Press, Buddy Press, bbPress I am a seasoned computer user, programmer, with over 30 years experience. If I get confused with the “instructions” I assure you others with much less experience will also.

One big gripe I have is those writing instructions for BuddyPress and bbPress make assumptions and throw out terms WITHOUT first defining them. That is the root of much of the confusion newbies to these plug-ins have resulting in much needless guessing, trial and error and time wasting.

I can say WordPress and it various plug-ins can be a nightmare to work with because of the above. Your comments actually confirm that.

Yes, I read the “instructions” and visited the shortcode page. Since shortcodes are typically “extras” one might add AFTER your site is basically working I glossed over the one that works.

My point here is since anyone installing bbPress or Buddy Press would logically want to make such additions a MENU CHOICE or what’s the point of having them that should be specifically explained in the instructions far more clearly that it is to avoid confusion.

What compounds the confusion is Buddy Press works very different than bbPress. The former automatically generates a listing of Groups by simply making a BLANK Groups page! That bbPress requires a shortcode to generate a list of forums isn’t explained anywhere in the main instructions and many like me will miss how to do it and spend countless hours hunting all over the web and asking for a solution. Again this points to sloppy incomplete instructions and yes, doing that does make me angry!

It would be illogical to assume anyone wishing to use bbPress forums would not make them a menu item. How to do that should be explained in the MAIN instructions not expecting users to wander off to various other pages and pick and choose some shortcode to see what happens. Even the correct shortcode [bbp-forum-index] is misleading in that “index” isn’t defined as to WHAT it will do. Again leaving end users to GUESS. Instructions that make users GUESS are incomplete and sloppy!

Can you tell me what version of android, whether it happens in both portrait and landscape mode, and the exact steps to reproduce?

Thanks, but I’ve already posted the same question on the s2Member customer forum because as I said, I’m not sure if it’s a Buddypress or an S2Member issue. Hoping someone will come up with a solution.

Thanks @aces

I’ve been trying your suggestions and am getting closer I think, but I’m still a bit out of my league so wondering if you or anyone else can help a bit more please.

In the absence of anything in my child theme, should the WooCommerce button CSS always override the BuddyPress default.css? ….Or are there ways that the BuddyPress default.css can win out? For example if both have the same named a.button…etc. definitions which may conflict with each other, which one wins out?

Here is the a.button code from WooCommerce to compare with 1720 of bp’s default.css. I don’t understand it well enough to work out the conflict, or how to hack either to fix it, or better still how to add something into my child theme to fix it. Any ideas gratefully received?

` /* =Buttons
————————————————————– */

a.button, button.button, input.button, #respond input#submit, #content input.button {
font-size: 100%;
margin: 0;
line-height: 1em;
cursor: pointer;
position: relative;
font-family: inherit;
text-decoration:none;
overflow: visible;
padding: 6px 10px;
text-decoration:none;
font-weight:bold;
.border_radius(2px);
left: auto;
text-shadow:0 1px 0 @secondary + #111;
color: @secondarytext;
.darkorlighttextshadow( @secondarytext );
border: 1px solid darken( @secondary, 20 );
.vertical_gradient( @secondary, darken( @secondary, 10 ) );
white-space: nowrap;
display: inline-block;

-webkit-box-shadow:
inset 0 -1px 0 rgba(0,0,0,0.075),
inset 0 1px 0 rgba(255,255,255,0.3),
0 1px 2px rgba(0,0,0,0.1);
-moz-box-shadow:
inset 0 -1px 0 rgba(0,0,0,0.075),
inset 0 1px 0 rgba(255,255,255,0.3),
0 1px 2px rgba(0,0,0,0.1);
box-shadow:
inset 0 -1px 0 rgba(0,0,0,0.075),
inset 0 1px 0 rgba(255,255,255,0.3),
0 1px 2px rgba(0,0,0,0.1);

&.loading {
color: lighten( @secondarytext, 10 );
border: 1px solid @secondary;

&:before {
content: “”;
position:absolute;
top: 0;
right: 0;
left: 0;
bottom: 0;
background: url(../images/ajax-loader.gif) center no-repeat rgba(255,255,255,0.65);
}
}

&.added {
&:before {
content: “”;
position:absolute;
height: 16px;
width: 16px;
top: 0.35em;
right: -26px;
text-indent: 0;
background: url(../images/success.png) no-repeat;
}
}

&:hover {
.vertical_gradient( @secondary, darken( @secondary, 15 ) );
text-decoration:none;
}

&:active {
top: 1px;
}

&.alt {
.vertical_gradient( @primary, darken( @primary, 10 ) );
border-color: darken(@primary, 20);
color: @primarytext;
.darkorlighttextshadow( @primarytext, 0.6 );

&:hover {
.vertical_gradient( @primary, darken( @primary, 15 ) );
color:@primarytext + #111;
.darkorlighttextshadow( @primarytext + #111, 0.6 );
}
}
}

.cart .button, .cart input.button {
float:none;
}

a.added_to_cart {
padding-top: .5em;
white-space: nowrap;
display: inline-block;
}`

Here is a link to a post I started on the WooCommerce forum which gives some more info about how I am working around this conflict at the moment, whilst still trying to get a fix –
https://wordpress.org/support/rss/topic/woocommerce-205-cart-button-colours-not-workinbg-on-ie89

Many thanks for any help and I hope it helps some others too.

@chouf1 thank you for being so explanatory!

Let me explain what I need/want. I do mind for the looks of the community I’m building. That means that I want my site to be eye appealing and easy to use. In my opinion designing a beautiful UI is one thing and there are many more. How users/members see each other inside this community and how easily they can search and find one another is important to me.

There are three main reasons that I prefer real names over usernames:
1. They are more easy on the eye. It’s better to see “John Smith” than “john_23” or “johnny_s_12”.
2. It is easier to find “friends” searching with real names. When I meet someone they introduce themselves with their names, not with usernames. So, later I can search for them with ease.
3. When registering using usernames, there are many chances that your first 3 or 4 choices to be already taken and you would have to select a username that even you couldn’t easily remember or like. But if the only parameter for uniqueness was the email address, you could use the same name as someone else without any problems.

I know that users might not want to use their real names, but I want them to have the choice…

As for the FB autoconnect, it’s not something I “absolutely want”. In fact it wasn’t even in my original plans. It came to me as idea while I was searching for ways to work around the usernames.

Thanks chouf1 for your suggestions,

I found what I was actually looking for in buddypress/bp-friends/bp-friends-loader.php

Line 97:

`

$main_nav = array(
‘name’                => sprintf( __( ‘Friends %d’, ‘buddypress’ ), friends_get_total_friend_count() ),
‘slug’                => $this->slug,
‘position’            => 60,
‘screen_function’     => ‘friends_screen_my_friends’,
‘default_subnav_slug’ => ‘my-friends’,
‘item_css_id’         => $bp->friends->id
);

`

`‘name’                => sprintf( __( ‘Friends %d’, ‘buddypress’ ), friends_get_total_friend_count() )`

So I’m just going to substitute my function for friends_get_total_friend_count().

Leaving this here in case somebody else ever wants to find this out as well.

@mercime thanks for clarifying that because I didn’t know.

@modemlooper
My point is if users open a support thread and we have a form that is required for them to fill out then it gives them no option other than to supply the basic info we need to assist them. I don’t intend to be harsh but I just would like it if we had that info in advanced before having to ask for it. I hope this makes sense as it would help all that voluntarily give there time to the forum. As far as the users not knowing the fields are mandatory then we can use whats built into BuddyPress and make those fields required. Does this make sense guys?

For the first point, what I meant was some people like reading just an “official” review of a movie by the main reviewer, and may not want to read commentary by others in the community.

So you’re saying with group meta I can create a new filter in the Order By drop down menu? Or create a completely different interface for displaying the list of groups based on any number of criteria?