BuddyPress.org

finally.. i figured it out after i wrote all of this…

you can delete this thread if you want.. it didnt allow me too.

Thank you.

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.