BuddyPress.org

Hi, @megainfo hope all is going well. Looks like this will be an awesome plugin. I am excited to offer our users more privacy that they can choose to have.

Nevertheless, there is one situation I am confused on.

As you can see in the example image, the privacy and post update button are now in a scrollable window.

Could this be fixed? Thank you so much for your time.

Joseph

@strangechild — there is some documentation here: https://codex.buddypress.org/themes/theme-compatibility-1-7/theme-compatibility-2/

The intro is confusing, but if you jump to the second section, it tells you where to find files and where they need to be added to your theme, if you want to override them.

Essentially it sounds like you need two roles. Band and fan.

Then, once a ‘band’ user has logged in after they’ve registered you want them to be able to embed music into their profile. Users of role ‘fan’ won’t be able to do this.

On those requirements, why isn’t it as easy as the process outlined in my post?

Once you have separated the fans from the bands at the point of registration as outlined in my post, you can treat them as discrete entities in BuddyPress. Throughout your theme files you just do some simple logic

if ( is a band ) {
   // this is a band so let the band play
} else {
   // this is a fan so do something else
}

Hope this info helps.

+1 Boone.

@synaptic as Boone mentioned above, BuddyPress is developed and supported by volunteers. If you’d like to contribute, check out how at https://codex.buddypress.org/participate-and-contribute/

in the buddypress settings, not sure how to be any more explicit.

have you set the registration page in the buddypress page settings?

This file: https://plugins.svn.wordpress.org/buddypress/tags/1.8.1/bp-templates/bp-legacy/buddypress/members/single/member-header.php

@synaptic Thanks for starting this interesting discussion (and for doing it in a more sensible and measured tone than the linked article).

I agree that the current process for selecting and advancing features is not ideal. It is indeed a shame when a ticket like the CPT one gets punted release after release. I’m not sure that I can *justify* it, but I can *explain* it.

In brief, BuddyPress is maintained and developed by a small number of volunteers. (Contrast with WordPress, which has quite a large number of contributors, and a number of people who are paid to work exclusively on WordPress core as part/all of their day job.) So, the things that get developed during any given release are those things that the small number of volunteer developers have chosen to spend their time on. How do the developers choose? Personally, I tend to gravitate toward those items that fall into one or more of the following categories:

1. Items that other people have contributed code to, either in the form of an existing plugin, or a patch, or whatever. This is both because these items mean not starting from scratch, and because it validates those contributors’ time and effort. The new dynamic menu system (described here http://www.wptavern.com/buddypress-1-9-will-include-dynamic-menu-links) is a great example of this: community member imath contributed a very nice patch, so it got moved up in the list and will be part of the 1.9 release.
2. Items that someone is paying me to build anyway. I’m a consultant working on BP projects, and sometimes a client wants a feature that would be valuable in BP itself. If I’m not mistaken, the new notifications component for 1.9 is an example of this – jjj was working on it for a client, and so was much of the way toward having it ready for BP.
3. Low-hanging fruit. Often there are relatively easy tickets, something I can knock off in an hour or two.
4. Stuff I enjoy doing. There are some sorts of features I prefer to work on, and I’m more likely to spend my volunteer time working on them.

This isn’t an exhaustive list, but it gives you an idea of the kinds of motivations that go into the contributions of a volunteer. And it means that sometimes tickets that garner interest and conversation – your CPT ticket example is a good one – can fizzle. Sizable features like this really need to be personally shepherded by someone in order to be successful, and there is simply too little developer time to cover all worthy tickets.

Is our system for choosing features and fixes perfect? No, definitely not. Your voting idea is a nudge toward something missing from my list: “items that are wanted most by the community”. If you’re interested in pursuing something like this, please please please do – the Future Release pile has lots of good stuff in it, but it really needs people to read through tickets and pick out the stuff that should be presented to the community. Feel free to reach out to me if you want to talk more about this.

As a side note: Deciding on roadmaps, etc is really hard. We want to do what’s best for the project (whatever that might be, and however you might determine it), but at the same time we want to ensure that contributors – who, it’s important to remember, are giving their free time to the project – are working on things that they personally find valuable and enjoyable. I’m eager to work with interested members of the community do a better job at striking the necessary balance.

BuddyPress utilizes WordPress’ version of jQuery.

But I can see how this would be a problem for custom themes relying on something like Zepto.

You can try adding some javascript directly after the Zepto library is called to declare the jQuery variable as an instance of Zepto.

Something like:

<script type="text/javascript">
if ( typeof jQuery == "undefined" )
	var jQuery = Zepto;
</script>

Not sure if that will work at all, since Zepto is a lightweight-alternative to jQuery, but hopefully that gives you an idea.

well from the looks of things your admin bar has been modified, check buddypress’s admin bar for example, so i would start by deactivating all plugins – minus bp AND use bp default theme. Also is the admin bar displayed while bp is deactivated?

Hello! This thread is mostly accurate, but just to wrap things up —

@jjj has been working at 10up.com since August, and I’ve been at Automattic since the beginning of 2013. John and I had been contributing to BuddyPress for years before we started at Automattic. Our day jobs only affect our contributions to BuddyPress in a positive way; as @henrywright-1 pointed out, John’s built a whole new notifications component since he’s been at 10up! Wow!

While Automattic does own BuddyPress and the trademark in a very legal sense — and it’s my personal wish that one day the BP trademark is transferred to the WordPress foundation — they have no influence over the day-to-day of the plugin, and John remains in charge of the ship.

I’m also having the same issue as mentioned above.

BuddyPress 1.8.1
WordPress Multisite 3.7.1

The button works from the main Groups page, but not when on a single group page.

i think all this hullabaloo about who’s working where is a bit of a distraction how come nobody mentions that @djpaul is now working for automattic?

JJJ’s work on the notifications component pretty much answers that question. If you look at the updates in the Trac ticket you’ll see just how much time and effort he has put in over the past month.

The article didn’t say JJJ deserted BP all together. It simply points out that he took another job and Boone appears to be taking more initiatives as far as BP is concerned. Trolling is when you intentionally act like a pr*ck just to get a rise out of people on the net. Pardon my candor!