Skip to:

Call to arms – Own your task

  • John James Jacoby


    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 – 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*

Viewing 25 replies - 51 through 75 (of 90 total)
  • If those template functions are similar, I don’t see a problem changing it, but get_template_part() fires an action, but it doesn’t let you filter things. What’s the benefit?

    EDIT: any way, make a patch, and we’ll look at it.

    John James Jacoby


    @svenl77 – Happy to have your team on board. Something as easy as moving the `get_sidebar()` calls into the footer makes sense to me. Would seem an easy patch and reduce some duplication.

    I’m opposed to hosting anything anywhere else (github) for the simple fact it further fragments development. We have Trac, and we have Unless there’s a coup d’état and mutiny abounds us, no sense in moving that code somewhere else and possibly losing out on the eyes that are already here.

    Now if you want to setup your own git repo, and chip away at something until you’re comfortable with the end result, and then provide an SVN diff to put back into core, obviously something like that is fine.

    Bumpety bump bump.



    If those template functions are similar, I don’t see a problem changing it, but get_template_part() fires an action, but it doesn’t let you filter things. What’s the benefit?

    get_template_part() isn’t filterable, but creating a wrapper function would do the job much like the bbPress plugin is doing. (Sorry if I wasn’t clear above.)

    I basically wrote a wrapper function for locate_template(). Similar to what’s suggested here:

    There’s an open ticket (#2649) on BP Trac suggesting to wait for WP core to implement the filter. However, in all likelihood, the WP filter for locate_template() will probably be implemented in a future release.

    I still think a filter for this should be in core, not implemented piecemeal for each plugin.



    I am currently writing my own theme that looks nothing like BP-default, but I’ve been on trac almost daily with the UI tickets. I don’t know if we need a dedicated “UI/UX” team, but as long as folks are submitting on those tickets it will ease some of the other dev’s needing to mess with it. I DO think it is an important component with BP and we need to keep talking about 1.3’s problems.

    I’m glad to see all the discussion going on, especially in light of all the “BP IS DEAD” nonsense. I think the biggest issue is how the forums make it hard to actually talk, but the testBP forums are great and I’m excited to see them go live here. I’m also anxious to see the new which seems to be slated to June.

    My biggest issue with the BP sites I run is spam. Even my non indexed test servers get spammed. My AIGA site was deleting 250 spam users/blogs a day before shutting off new user registration. The first part of that comes from spam users being registered. There are two types of spam services, bots, and (slave) labor. These folks get through the Captcha’s and set up real fake accounts. But in my experience with my comment forms adding a Captcha killed a vast majority of spamers. Then with comments, contact forms, etc this would kill most spam. From there heuristic spam fighting from splogs, comments, etc. Also a system that users can mark a item as spam would help a ton.

    Second, its that to learn how to do ANYTHING in BP I have to take something that works with the current version and hack it a part to figure out basic commands and actions. Once the new site is up I think there should be a real push on getting the Codex up to snuff(look at jQuery and WP) that have examples, resources, etc. Then have tutorials on things, hell syndicate them from other bloggers.

    So as my thing(s) I want to keep being a part of fixing UI issues, and will as long as I can.
    I want to write for the Codex, and am here and willing to write Blog articles for BP. Tutorials, Updates, whatever. I’m game. I will be writing tutorials for AIGA members anyway, so why not sync the content here.
    I am working on the Group Documents plugin with its original developer because my sites need it.

    And lastly I will be writing a BP-Spam component. I will do it as a plugin first and will want/need tons of feedback. But to get the University to sign off on my project I will need to stop all the Viagra and other inappropriate content from making it through. I will do this regardless of it being a part of BP but want to give back however I can.

    I’m so psyched to see all the energy is still in this project!



    @johnjamesjacoby : Wouldn’t moving the sidebar cause a nightmare for backwards compatibility?

    I have a half-finished Akismet plugin for BP 1.3 for the activity stream if anyone wants to work on that with me

    Sven Lehnert


    Hi @johnjamesjacoby

    we are kind of new to all this… How to start? I will check out the latest version via svn. That’s fine. But how to check in? Commit? Push?
    Should I add the complete theme as .zip file on a ticket? I guess the size will be too big.
    I would like to write this patch, I’d like to start with some easy job to slowly go into all this. So the sidebar bug is an easy startup.

    @dennissmolek, i guess we can keep it update save (backwards compatible) by asking if the sidebar is already active

    Some more newbee questions:
    Where do I add my other subjects? The sidebar was just one example of a long list we would like to discuss and write patches for.

    Should we open a ticket for every idea we’d like to change?

    Sorry, if some of the questions are already answered in other forum threads.
    Maybe it would be a good idea, to write a guide to become an active part on the project.
    Thanks for all, we are excited to start

    Anyone interested in UI should keep an eye on tickets marked as needing UI input:

    Perhaps we can add some more reports to the Trac. Are there any on that you would find useful on the BuddyPress trac?

    EDIT: just added report 17 — “Needs User Experience / UI Feedback / Designs”


    Hi. Once you’ve made your changes, create a patch, and then upload to (you will need to make a new ticket — one ticket per patch/idea). Then one of the core team will take a look and give feedback/commit as necessary.
    As @dennissmolek said, if a child theme has customised, for example single.php, it is important that this change does not render a duplicate sidebar. I am looking forward to see your suggestion.
    Also, how much work would it be to make the sidebar go on the left? Is it just a case of changing the CSS or is it lots of work?

    We’re trying to keep backwards compatibility for the theme as much as possible, as we encourage people to create child themes of it ad don’t want to annoy theme developers.

    In general regarding custom post types: we have plans to do this everywhere for BuddyPress 1.4. I am sure that once we are closer to the release of 1.3, we will communicate details for 1.4 on the so everyone can discuss. That may be an appropriate time to kick-start the old groups-as-an-object ticket.

    Andrea Rennick


    @djpaul needs codex / documentation is another trac tag I follow over in core WP. This would be for anything that requires a codex entry to explain.

    @johnjamesjacoby Do you have edit access on the trac, or can you get the SQL used for the reports? There used to be a way to sneak them out, which is how I added some of them to trac, but it’s not possible anymore!

    Also, how much work would it be to make the sidebar go on the left? Is it just a case of changing the CSS or is it lots of work?

    Good question: given that the one of the prime reasons for separating presentation from content and of finally moving away from table based layouts and their rigid inflexibility was that it must always be possible to effect any presentational changes from CSS, moving a sidebar from one side to another is a classic example used to demonstrate the benefits of CSS presentation over table layouts; I would hope it’s a do-able with default layout, if not then the markup structure has interfered when it shouldn’t but doubt that’s the case.



    Sidebar switching should def be added to 1.4 bp-default as a theme function.

    Andrea Rennick


    at its most basic, switching sidebars is usually changing the floats in the css.

    Andrea Rennick


    2 minutes later – I did it in Firebug, so I’d say “it’s easy”. Dunno if you want to include it by default though.

    at its most basic, switching sidebars is usually changing the floats in the css.

    Yep it ought to be adjusting no more than a few rulesets, easily set up using a token on html or body to hook contra styles onto, always set up non wp/bp sites with this option to easily adjust the site layout by simply changing a token in the header.php extending that through to user control if a backend exists.

    It should be simple to set up for bp-default and not break anything.



    Context of “switching sidebar”

    – switching sidebar from right of content to left of content is easy via CSS as andrea_r pointed above

    – switching sidebar to show different widgets/scripts in respective BP component pages can be implemented in simplest way by adding conditional statements with dynamic widget areas for each component all within sidebar.php. More sophisticated method of doing this can be in adding a special widget which will allow you to do all of the above.

    I know how hard it *should* have been, I was asking @svenl77 if it was ;) But that appears to have been answered, thanks ;)

    Or one could take the approach of not moving the sidebar but of providing a second one that using a conditional check for is_active_sidebar() shows the sidebar and also sets a variable to use as a token then you can have an alternate set of rules ready to adjust content margins etc as needed; there is many ways of skinning this cat.

    I know how hard it *should* have been

    oooh pardon us for breathing ;) I’ll get back to doing something interesting, I might provide an option to flip all sidebars horizontally.



    == I might provide an option to flip all sidebars horizontally. ==

    I believe Your Highness would be greatly assisted by the looks of the footer widgets in BP 1.3 bp-default theme.
    From the office of the Lord Chamberlain

    :) Ive provided the option to move header to footer and footer to header written a stylesheet called btt.css and written a JS function to switch browser scrolling from top to bottom to bottom to top and turned the sidebars and content upside down and am going to market this to them that live down under .



    I would go to the trac:
    and create a ticket for your ideas. This would give other dev’s the chance to look at it, and you can work it much easier than starting threads on the forum. It also keeps all the files you put up so its a good revision tracker.
    And what most of us do is create a patch against the newest version of the trunk and the core dev’s check it out and either ad as/is or work to modify it to fit..

    And I was wondering, if moving the sidebar can be done with just CSS why are we adjusting the markup for it then? I understand to avoid repetitious code but for backpat sake if css can do it, why create more hassle? PS, this is the stuff that can go on the trac.

Viewing 25 replies - 51 through 75 (of 90 total)
  • The topic ‘Call to arms – Own your task’ is closed to new replies.
Skip to toolbar