Call to arms – Own your task
Do you really like the activity stream and have ideas on how to improve it? Are you working on a site where you’re beefing up Private Messages and want to contribute some code back to the project? Maybe you’re just really good at blogging and want to share some BuddyPress experiences?
Now’s your chance to help the BuddyPress core team get things done.
If there’s a task you want to *own* in BuddyPress, let’s start by talking about it here first. Later we’ll move onto development chats, etc… but for now I want to get a feel for who wants to commit to doing what.
Example – Things I am working on:
Step 0 – Better dedicated support forums via bbPress plugin – June
Step 1 – Redesigning buddypress.org – June
Step 2 – Releasing 1.3 – June’ish
Step 3 – Mirroring the WordPress development methods (UI/UX/Trac/etc…) – July
Step 4 – Improved collaboration with contributors – July
Examples of things that could use ownership:
bp-default theme audit (make sure actions are in the right places, CSS is tidy, small visual tweaks to bp-default CSS)
phpDoc audit (verbose documentation on functions, classes, variables, etc…)
deprecated code clean-up (get rid of our old MU specific code)
Moderation tools (integrate them into the WP menu)
Admin interface UI (thinking far, far head here)
Wireframes, mock-ups, ideas, visual stuff
*anything that you think needs doing, and can commit to doing*
@cnorris23 I would suggest that anyone looking into moving where the data is stored in the database hold off a little while, until the core team have a plan about how custom post types will work and be implemented for each of the components. We have had lots of discussions about custom post types for BuddyPress, but we’ve been focusing on finishing up 1.3 for some time now. It’s great you’re interested, though
I am interested in improving the xprofile fields to allow developers to add new field types. currently we have a limited set of fields(say multiselect/checkbox etc). An example extension could be allowing to add an specializationn of select box with Country drop down which will save numerous times for many site owners. I am not sure if that needs to go in the core plugin, but certainly we need to add some action/filters in the core to make that happen. Also, currently, xprofile needs to improve the queries for fetching select field(My benchmark shows one query per item in the dropdown list of a field). So, if we have a field with 100 items in select menu on the edit profile/register page, It will do 100+ queries for that single field.
If improving xprofile fields is still on the card, I will be very happy to work on it.
Brajesh, sounds like a great idea. As you know, early BP used to have a country field type. RE: query; if that’s the case on trunk, it’d be super to patch that part for 1.3.
A huge limitation of BP at the moment (and WordPress in general) is the lack of front-end posting and moderation. I’ve had to hack this into my current site by using conditional user level statements to present a restyled admin screen to users – one which looks identical in terms of header, footer and CSS to the front-end – and unsets or removes redundant menu items. The way around this would be to modularise certain admin functions (posting, comment management) so that theme designers have flexibility in the way they are presented and integrated on the page with other functions. This could be achieved with shortcodes or even widgets. I can see no functional reason why users should be sent to an un-themed back end to post new blogs and I’m sure it’s holding BP back as the choice for many sites.
Unfortunately I can’t offer to help apart from documenting my hack as an interim solution.
In terms of the multiple CSS suggested by @bowromir, I’ve spent the last year working with Zend Scaffold as used within Webligo’s SocialEngine 4 and it was a PITA. Scaffold caches an aggregated version of all stylesheets used in the theme into a single CSS, which sounds logical but makes it very time consuming to debug or alter the base stylesheets since tools such as Firebug cannot tell where styles originate from.
Yes, I remember that. Just trying to bring it back as an option to the site admins and allow them to extend it.Going to put a patch later today for that.
Re query: Yes, the query count is still applicable to bp trunk #4396. It is only in the case of multiselect box where the query is done for each item in the list. will look into that and put some patch.
@doctordr, The front end posting capability is coming as part of wordpress upgrade in near future(hopefully). They are making the quickpress available to front end. checkout this ticket for details(It was dropped in 3.1 and let us hope it comes with 3.2)
I think what needs to be worked on the most is the forums. If you look on a Topic on my site, the forums have been basically vamped from what they were originally from, to a more forum style.
I think this would be a great addition in 1.3, and would be glad to help on anything.
As always, I am more interested in the support & documentation end of things. Anything that needs docs, ping me. When the forums get revamped, I’ll add it more regualr-like to my roster.
And any news that needs yelling from the rooftops – hey, I’m your gal.
Yeah, it’s definitely not something I see happening before CTPs are mapped out. It’s a little too late in the game to try something that big for 1.3, and it would be a much easier transition to wait for CPTs. Just figured I would throw it into the mix.
@MrMaz, @Bowromir: I’m up for linking up about UI / design on the default theme, buddypress.org and also back end admin interface. As I come from a UI and design / front end more should fit in hopefully with those already volunteering. I would love to get involved in both parts and have done a small amount with some sketches for the dashboard previously for @djPaul.
As previously discussed I would like to suggest the formation of the BuddyPress UI/design team. I think in BuddyPress’s case it should include the default theme as that is the main along with admin UI experience most get.
I am also happy to get involved in CSS documentation which I think is a key issue. I actually think it should all stay in one file but be documented and commented so that it’s easy to navigate and find content. I have done some clean up on the CSS before but suggest this goes deeper with commenting and better organisation. I would like to take that task on even with the default theme as think will benefit others – assuming it’s not being done already.
RE: a BuddyPress UI team. People who are interested in contributing in this way need to have shown their interest by contributing to theme and UI tickets and issues as they crop up. I know some of the people in this thread already have, and do; keep on the good work
Mercime has generously done a wp.org-style theme review of BP-Default. I’ve created tickets on trac. The master ticket is https://buddypress.trac.wordpress.org/ticket/3241
I may add a few more tickets once Mercime has clarified a few details. If you are interested and will commit to resolving one of these, please go into trac and “accept” a ticket so that everyone can see that you have assign it to yourself. If it’s a big visual change, I suggest making a mockup picture and attach it to the ticket so that everyone can give feedback.
If I can be of any help or guidance, I’m on skype as “djpaulgibbs”, on IRC and frequently check my email. Don’t hesitate to get in contact
@sbrajesh Thanks, I’ve left a comment. Let’s talk code on the ticket
That rocks just submitted 2 patches – great to get involved in patching thank you.
Just got back in. All tickets listed at this time in https://buddypress.trac.wordpress.org/ticket/3241 are either being worked on and many have already been fixed. Kudos to all
A little late to this thread, anyway, I’m in total agreement with MrMaz; while there’s some nice work going on in bp-default to make it blog and theme-review compatible, I don’t believe it should be the job of the core devs to maintain a blogging theme. BP should only worry about the templating aspects of BP only and should support any WP theme thrown at it.
With that being said, JJJ has done some awesome, awesome work on this same issue with the bbPress plugin. I’d like to help and see this backported to BuddyPress as soon as possible, but I’m not sure if that is considered too big a change for v1.3. (I did write a similar plugin that attempted to add BP functionality to any WP theme, but I didn’t release it.)
Nice to see everyone stepping up and getting involved. You rock. Exciting stuff.
I don’t believe it should be the job of the core devs to maintain a blogging theme. BP should only worry about the templating aspects of BP only and should support any WP theme thrown at it.
Exactly and as has been mentioned many times over, it cuts to the core issue of trying to develop themes which is still simply too difficult. Core needs to concentrate on templating and then handing over to themes to do the frontend rendering. Dying to see what JJJ has done with bbPress as it’s starting to sound quite interesting but haven’t had a moment to test it
The problem with separating the theme completely from the core (right now) is without a fully functioning theme, there’s no way to actually use BuddyPress. Even the bbPress plugin comes with a small set of fallback template files (as a child theme of twentyten) to display forums. The core of this problem is there is no way to create new WordPress functionality without it logically needing new template files to display it. The approach I took with bbPress (which I’d like to port to BuddyPress) is to monitor query_vars and template_include, and replace the_content() with a template part inside an output buffer. With this in mind, bp-default would get turned into a bunch of template parts that don’t all require header, footer, and sidebar calls, and those parts would just drop into any existing WordPress theme whenever they need to, correctly, all the time.
I’m writing for themekraft.com, we are a young startup, making our lives with WordPress and 80% BuddyPress related development.
Buddypress has changed our lives and we want to count us in.
We have read the thread from bowe at bp-tricks.com and this thread here, and we want to help, too. It’s like bowe and this thread is bringing our thoughts to the public, and we feel it’s time to come together.
We are 3 people, and we can give 2 hour every week to help out. That makes 6 hours – let’s say one day a week.
We are two developers and 1 theme designer.
There are many small and bigger problems we found in our daily work, we like to have changed. And we would immediately start helping.
For example: bp-default:
We have developed a theme for BuddyPress. And in the theme you can change sidebars, also for BuddyPress components .
But it’s very difficult for us to provide a left sidebar only, because buddypress comes with a right sidebar in the default theme and the sidebar is included in the pages instead of in the header and the footer.
Every component that extends BuddyPress, comes up with the right sidebar in the template files.
That means for us (and all theme devs with theme options like sidebars), we have to rework every template file from every plugin to support having just a left sidebar.
This is just one theme example, we would like to share all experiences to improve theme development with BuddyPress.
We know, there must be at least some templates files for buddypress to work. But they should integrate in different way as now.
We have read this thread, and there are quite a lot of people willing to get their hands on the bp-default.
Wouldn’t it be a great thing to have the bp-default in github, so we can create a team to work together the git way?
There is also an issue tracker in github, and I feel it’s much easier as the trac…
This way integration in a new bp-default team would be very easy.
Patches and all the BuddyPress stuff.
We have done some funny things with custom post types and groups, because it is so difficult to filter groups in a certain way.
Also if we use the custom post type api, we get a lot of benefits like revision backups and so on.
To be honest, we believe that BuddyPress could handle groups more powerful, and we would like to work on this, too.
I have seen the conversation from the BuddyPress ninjas in the early days of 1.2 where JJJ started to think of groups in a API way.
Everything is a group. Like a group of people and so on. I really liked the idea and we would like to see groups become something more powerful.
I will stop writing now, hoping we will just start working, as I guess everything has been discussed before.
Thanks for all, we love BuddyPress and see it us a powerful tool to build great websites, often without the need of a direct social network, using it to realize our customers needs.
We look forward to start helping. We always had the feeling before, that it’s not so easy to become a working part.
So just let us know where we can start, or what you need to be done
svenl77, konradS and mahype
They way JJJ describes it would be the way to go imo.. Looking at the BBPress beta this seems to work well, and it would make things a lot easier (and more fun). I have another question about templating though;
1: Using get_template instead of locate template Is there a reason why locate template is used in BP-Default instead of get_template? Looking at TwentyTen and TwentyEleven they all handle it with get_template.. From what I understand from talking to MrMaz it also allows greater flexibility doing it like this. Because get_template can be filtered/hooked into while locate_template is very inflexible.
2: <get_template_part: This seems to be the way forward for new themes. It allows you to load specific template parts in your theme so you can reuse them. (http://codex.wordpress.org/Function_Reference/get_template_part)
I think both of these things could make the theme more flexible and easier to work with.
re: default-home, default-member, bphome, bpmember, bp-sn-parent, and bp-default themes
re: get_template vs locate_template
A great article on proper usage of get_template_part and locate_template can be found here: http://justintadlock.com/archives/2010/11/17/how-to-load-files-within-wordpress-themes.
locate_template – function searches in the STYLESHEETPATH before TEMPLATEPATH so that themes which inherit from a parent theme can just overload one file http://codex.wordpress.org/Function_Reference/locate_template.
Even the bbPress plugin comes with a small set of fallback template files (as a child theme of twentyten) to display forums.
I didn’t say we’d get rid of bp-default! bp-default can continue to be a parent theme. Even if we backport the simplest changes from bbPress for now like get_template_part() to BP (instead of locate_template() like Bowe mentions above), this will make things very easy to build a plugin to serve BP template files without copying them over to the WP theme (as BP Template Pack does now).
In my unreleased plugin, I created a function similar to bbp_get_template_part(), copied bp-default BP-only template files to my plugin directory and swapped out locate_template() for this new function. The plugin served BP template files. Then, combined with this, all you’d need to is create a header-buddypress.php (or footer-buddypress.php, etc.) in your WP theme to make it gel with BuddyPress.
You must be logged in to reply to this topic.