Updates from Boone B. Gorges RSS Toggle Comment Threads | Keyboard Shortcuts

  • Boone B. Gorges 12:51 am on March 27, 2012 Permalink | Reply
    Tags: 1.5.5   

    I’ve just released version 1.5.5 of BuddyPress in the wordpress.org repository. BP 1.5.5 is a security and maintenance release. Read more about it at the buddypress.org blog http://buddypress.org/2012/03/buddypress-1-5-5/ or on the Codex http://codex.buddypress.org/releases/version-1-5-5/

     
    • Master of Awesomeness 10:03 pm on April 9, 2012 Permalink | Reply

      Is there a way you could make BuddyPress available for WordPress.com??? I really enjoy BuddyPress for a site I write for with WordPress, but I also make websites with WordPress.com and BuddyPress would really help me.

      • Chris Clayton 6:38 am on April 10, 2012 Permalink | Reply

        @awesomebentv i don’t believe their is anything that the BuddyPress Core Devs can do as it’s ultimately up to Automattic to decide to allow BuddyPress support. Your best bet might be to send feedback to Automattic suggesting they allow BuddyPress.

    • Chris Clayton 5:03 am on April 11, 2012 Permalink | Reply

      Sorry for spamming your update with unrelated stuff, Boone, thought i’d mention it here instead of spamming trac. but since i always miss devchats live (due to sleeping patterns) could someone remember to ask JJJ whether he had time to write the “to do” list for bbpress stuff promised last week? Love to see if theirs anything i can help with to get 1.6 in beta.

  • Boone B. Gorges 9:52 pm on March 16, 2012 Permalink | Reply
    Tags: , visibility, xprofile   

    Several weeks ago, a series of changesets addressed what is perhaps the most popular request in the history of BuddyPress: profile privacy. (See #3695.) We’re calling it “visibility”, and you can check it out now in BP trunk. Here’s what developers need to know:

    Profile Edit view

    Profile Edit view

    • Users can edit their profile field visibility on a field-by-field basis.
    • Options available by default under “Who can see this field?” are Anyone, Logged In Users, and My Friends.
    • Site administrators can select a default visibility level for each field. Admins can also force a field to maintain the default visibility – for instance, an admin may decide that a field called “Phone Number” should always be limited to Friends. (See the new bp_xprofile_map_meta_caps(), and the bp_xprofile_change_field_visibility cap.)
    • Developers can customize the available options using two new filters:
      • bp_xprofile_get_privacy_levels – Register or deregister new privacy levels with this filter. The data being filtered here is an array that looks like this:
        
        array(
          'public' => array(
            'id' => 'public' // Canonical, non-translatable name
            'label' => __( 'Anyone', 'buddypress' ) // Label visible to users
          ), // etc
        )

        Add or remove items as you see fit.

      • bp_xprofile_get_hidden_fields_for_user – This is an array of xprofile field ids that should *not* be visible for the current viewer of the current displayed profile.

      In the upcoming weeks, I’ll write a short example plugin to demonstrate how to remove existing levels and add custom levels.

    • While the visibility filtering does not happen at the template level itself, the markup that allows users to modify profile visibility does require theme-level changes. The two key files are: /members/single/profile/edit.php (see the block beginning if ( bp_current_user_can( 'bp_xprofile_change_field_visibility' ) )) and /registration/register.php. In each case, you should be able to simply copy and paste the relevant blocks from bp-default; if you need to support older versions of BP, you may want to wrap it in a if ( function_exists( 'bp_xprofile_get_privacy_levels' ) ) check.

      Note that if your theme does not provide the proper markup for users to customize their profile field visibility, fields will default to the admin-provided visibility level, which itself defaults to Public. Thus, the feature degrades gracefully in the absence of theme support.

    Questions or comments? Leave them below, or in a relevant Trac ticket.

     
    • slaFFik 10:19 pm on March 16, 2012 Permalink | Reply

      Yay! That’s what the whole community wants!
      Thanks, Boone, for such news :)

      And what about activity items, profile sub-pages?

      • Boone B. Gorges 10:38 pm on March 16, 2012 Permalink | Reply

        Just xprofile fields for now. Activity items are immensely more complicated and resource intensive. Profile subtabs are handled by the components that register them, so would have to be taken care of in a distributed fashion. Maybe in the future :)

    • slaFFik 10:20 pm on March 16, 2012 Permalink | Reply

      And can we expect this to be in 1.6?

    • croixhaug 11:10 pm on March 16, 2012 Permalink | Reply

      A client just asked about this as a custom feature, awesome that it will be part of core!

    • hoho 11:34 pm on March 16, 2012 Permalink | Reply

      great !!

    • modemlooper 12:09 am on March 17, 2012 Permalink | Reply

      My profile privacy plugin handles sub tab privacy

    • Martin 12:24 pm on March 17, 2012 Permalink | Reply

      Awesome news! Now BP is on the best way to get the favorite tool to create a social network. I cant wait until the acvtivity stream get its own privacy settings too :-)

    • Jimmy 3:38 pm on March 18, 2012 Permalink | Reply

      So will this change create the ability to have different registration forms/fields depending on what option the users choose when registering?

      • Boone Gorges 6:30 pm on March 18, 2012 Permalink | Reply

        No. These changes allow the user to dictate who gets to see the data he/she enters into profile fields. It does not introduce any logic for profile field dependence.

        • Thomas 3:32 am on March 19, 2012 Permalink

          I have seen this request in the forums is there any discussion in including this in the core in the future? I’m sorry if this is already been brought or is in the tickets newbie with wp and bp..

        • Boone Gorges 8:07 pm on March 19, 2012 Permalink

          There is a ticket for similar functionality at https://buddypress.trac.wordpress.org/ticket/3962, which has been closed as ‘wontfix’ for now, in the hopes that a plugin developer will build it.

    • Boone Gorges 3:34 pm on March 22, 2012 Permalink | Reply

      As promised, here is a sample plugin to show how these visibility levels can be extended: https://github.com/boonebgorges/bbg-custom-bp-field-visibility

      That plugin does two things: Removes the ‘friends’ level, and adds a new ‘Admins Only’ level. It should give you the framework needed to add whatever levels your heart desires.

    • Hamed 6:36 pm on May 18, 2012 Permalink | Reply

      Can users create their own privacy groups?

  • Boone B. Gorges 6:40 pm on January 10, 2012 Permalink | Reply  

    BP 1.5.3 is available, with some fixes for better WP 3.3.x compatibility. Read http://buddypress.org/2012/01/buddypress-1-5-3/ for more details.

     
  • Boone B. Gorges 10:24 pm on December 12, 2011 Permalink | Reply
    Tags: bp_activity_get_meta(), bp_update_meta_cache(), cache, groups_get_groupmeta()   

    Several recent changes in the BuddyPress trunk have added better cache support for group meta (r5460) and activity meta (r5505). In brief, these changesets make it so that every time you call up groups or activity (as in, for example, bp_has_groups() or bp_has_activities()), BuddyPress will automatically fetch all of the metadata for those items and add it to the WordPress object cache. The net effect of these changes is that, inside of the group and activity loops, the performance of groups_get_groupmeta() and bp_activity_get_meta() is radically improved, since individual database queries are no longer required. (This behavior is modeled on how WordPress handles postmeta after a posts query – our new bp_update_meta_cache() is based on WP’s update_meta_cache().)

    For the most part, plugin authors do not need to do anything to take advantage of these new features. However, in order to make bp_update_meta_cache() as flexible as possible, the format of the keys used to cache activity meta has changed. It used to be of the form:

    'bp_activity_meta_' . $meta_key . '_' . $activity_id

    but is now of the form

    'bp_activity_meta_' . $activity_id . '_' . $meta_key

    to better match other components. As a result, your activity meta cache will be flushed when you upgrade to BP 1.6. And if you made any manual references to the activity meta cache in your own plugin, you’ll need to change those references. (If you used bp_activity_update_meta() and bp_activity_get_meta(), you don’t need to do anything.) This should affect very, very few (if any) BP customizations.

     
    • pink 11:56 am on December 16, 2011 Permalink | Reply

      Hello Boon,

      I am a newbie to WP an BP. I’ve just upgraded to BP 1.5.2 from 1.2.8. I cannot get BP-lotsa-feeds plugin working after the upgrade. :(

      Can you suggest how can i make this ultracool plugin of yours compatible with BP 1.5.2. This is really an emergency. Please help me sort this out.

      • Boone Gorges 2:22 pm on December 16, 2011 Permalink | Reply

        If you’re having a problem with the plugin, please post details (and I mean more details than just “it won’t work”!) to https://github.com/boonebgorges/bp-lotsa-feeds. This thread is for discussion related to BuddyPress core development. (Also, I’m dubious about the “emergency” part – few lives have ever been put in danger over a plugin!)

  • Boone B. Gorges 8:00 pm on October 13, 2011 Permalink | Reply  

    BP 1.5.1 was just released. Check out the blog post, the changelog, and the Trac milestone.

    Thanks to all contributors for your hard work!

     
  • Boone B. Gorges 4:49 pm on September 29, 2011 Permalink | Reply
    Tags: , , skeleton component   

    A new version of the BuddyPress Skeleton Component, complete with rich documentation on how to use the new BP_Component class, is now available. Read more about it.

     
  • Boone B. Gorges 2:52 am on September 21, 2011 Permalink | Reply
    Tags: template pack   

    If you’ve used the BP Template Pack to make your WP themes BP-compatible, you’ll be happy to know that BP Template Pack 1.2 is fully compatible with BP 1.5. Check out the announcement post here.

     
  • Boone B. Gorges 8:17 pm on September 5, 2011 Permalink | Reply
    Tags: , , , BP_Group_Extension, groups, navigation   

    If your plugin or theme manually manipulates the navigation tabs in individual groups, either through the use of functions like bp_core_new_subnav_item() and bp_core_remove_subnav_item() or through the direct manipulation of $bp->bp_options_nav, you’ll want to know about some changes in BP 1.5.

    Due to an oversight long ago, in BP 1.2.x, the key ‘groups’ (or, more precisely, $bp->groups->slug) was used to store two totally different nav items in $bp->bp_options_nav: the ‘Groups’ item on a user’s profile, and the main navigation of an individual group (Admin, Forums, Members, etc), an overlap that caused incorrect navigation to be rendered in some cases. In BP 1.5, this inconsistency has been rectified by moving individual group navigation items from $bp->bp_options_nav['groups'] to a new array position, keyed by the group slug. So if your group has the slug boone-for-president, the navigation for the Boone For President group will be stored at $bp->bp_options_nav['boone-for-president']

    What does this mean for you? If you use the BP_Group_Extension class – which is true for the vast majority of plugins that create group navigation – you will not be affected (because the BP_Group_Extension class builds navigation for you, and takes this change into account). You may be affected if, like Jonnyauk was attempting to do, you’re using bp_core_remove_nav_item() to take stuff out of the group nav, like this:

    function bbg_remove_send_invites_from_group() {
    	global $bp;
    	bp_core_remove_nav_item( $bp->groups->slug, 'send-invites' );
    }
    add_action( 'bp_setup_nav', 'bbg_remove_send_invites_from_group' );
    

    which won’t work anymore. Do this instead:

    function bbg_remove_send_invites_from_group() {
    	bp_core_remove_nav_item( bp_get_current_group_slug(), 'send-invites' );
    }
    add_action( 'bp_setup_nav', 'bbg_remove_send_invites_from_group' );
    

    Navigation for profiles, and elsewhere in BuddyPress, has not changed; the advice above is only relevant for groups (or custom components that have single items – Achievements comes to mind, meaning that if you are manually manipulating the single-Achievement subnav, you’ll need to make similar modifications.)

     
    • Boone B. Gorges 9:24 pm on September 5, 2011 Permalink | Reply

      I forgot to mention that if you need to keep 1.2.x compatibility in a plugin, you can try this method:

      $parent_slug = isset( $bp->bp_options_nav[$bp->groups->current_group->slug] ) ? $bp->groups->current_group->slug : $bp->groups->slug;
      bp_core_remove_nav_item( $parent_slug, 'send-invites' );

      That should cover both 1.2.x and 1.5+.

      • Tim Carey 10:16 pm on October 28, 2011 Permalink | Reply

        Try this method where

      • Leland 5:22 pm on January 11, 2012 Permalink | Reply

        Boone,

        Could you put in the full code for this? I have been trying to hack this updated group tab code for hours and nothing is working. Adding to functions file. Thanks.

    • Stas Sușcov 10:45 pm on September 5, 2011 Permalink | Reply

      Another thing to mention, since this post was about group component, if you were using in your plugins $bp->groups->slug to check for current page component, you should change that to $bp->groups->id since slug and component id refer to absolutely different information:
      1. to group component permalink slug
      2. to group component id itself

      As an example, if you’ve mapped groups component to a page called classes, your code will never work!

    • Johan 10:28 pm on September 27, 2011 Permalink | Reply

      Thanks for the info, guys. Can you please give me an example of how to ADD stuff to the menu option, as well?

      Cheers

    • Tim Carey 9:50 pm on October 28, 2011 Permalink | Reply

      Could someone please explain how to use bp_groups_default_extension to make your default group tab

    • Johnny 5:12 am on November 2, 2011 Permalink | Reply

      Also, could someone explain how to change a group tab slug too?

      Cheers

      Johnny

    • Chris 8:12 pm on April 29, 2012 Permalink | Reply

      Hi Boone,

      In your original post I think you have an error after ‘Do this instead:’ ….

      bp_core_remove_nav_item(….

      should read:

      bb_core_remove_subnam_item(…

      I’m also interested in what method you would recommend using for re-ordering the subnav items, e.g. renaming ‘Home’ to ‘Activities’ and moving ‘Forum’ to the start of the sub-nav

      And also changing the default subnav item (e.g. to Forum) in the example above, so that all other links to the group default to that subnav?

      Kind regards

      Chris

      • Chris 8:15 pm on April 29, 2012 Permalink | Reply

        (ignore this reply – I forgot to click notify boxes before I clicked reply)

  • Boone B. Gorges 9:17 pm on August 12, 2011 Permalink | Reply
    Tags: , , bp_blogs_record_comment(), comments, custom post types   

    There was a quirk in the way that BuddyPress 1.2.x’s Blogs component recorded posts and comments in the activity stream. With you published a new post, it only got published in the activity stream if $post->post_type == 'post'. In other words, Pages and all custom post types were ignored. On the other hand, no such post_type check took place in the case of comments, with the result that comments on pages and other post types did show up in the stream.

    This odd inconsistency was fixed in the BuddyPress trunk with changeset 4959; BuddyPress now checks to make sure that the item being commenting on is a WordPress ‘post’ before adding the comment to the activity stream. However, anointed chimed in to let us know that some BuddyPress admins were taking advantage of the quirk. The result of this discussion is r4971, in which the post type checks are enhanced by turning them into checks against a filterable whitelist.

    Plugin authors should be aware of this changed default behavior. If your plugin creates custom post types, and if you want comments on those custom post types to be recorded in the BP activity stream by bp_blogs_record_comment() (if you are using your own function for this purpose, you don’t need to worry about the change), you will have to update your plugin to do something like this:

      function bbg_record_my_custom_post_type_comments( $post_types ) {
          $post_types[] = 'dolphin'; // Add your custom post type name to the array. If you have a post type called 'dolphin' then you have a weird plugin
          return $post_types;
      }
      add_filter( 'bp_blogs_record_comment_post_types', 'bbg_record_my_custom_post_type_comments' );
    

     
    • Dianakc 4:24 am on August 13, 2011 Permalink | Reply

      Newbie question: BP or WordPress plugins should add this filter?

      • Boone B. Gorges 2:55 pm on August 13, 2011 Permalink | Reply

        Any plugin that wants to record comments on custom post types in the BP activity stream using bp_blogs_record_comment(). If any of the following are true about your plugin, then this post does *not* apply to you:

        • your plugin has nothing to do with BuddyPress
        • your plugin does not use a custom post type to store data
        • your plugin uses a custom post type, but does not use comments on those CPTs
        • you have manually unhooked bp_blogs_record_comment(), and are recording CPT comments with your own custom function

        (In short, it really only applies to a small number of existing plugins.)

        • stevenkword 4:43 pm on December 30, 2011 Permalink

          @Boone — Great solution. This helped me out today. Thanks!

    • Simon 5:47 pm on August 17, 2011 Permalink | Reply

      Question for you Boone, so let’s say you have a WP / BP site where your primary “members” can create posts. Does the above functionality (function bbg_record_my_custom_post_type_comments) imply that both post creation and commenting on posts can be integrated into the activity stream?

      caus that would be really cool.

      • Simon 5:49 pm on August 17, 2011 Permalink | Reply

        Further to that last question….

        Are there any caveats within the new 1.5 framework to tie custom post types to groups?

        i.e. create a new post in a group?

    • landwire 7:01 am on September 11, 2011 Permalink | Reply

      Keep me informed on this.

    • Johan 2:37 pm on September 26, 2011 Permalink | Reply

      Hm, I can’t get this working. I’ve tried adding the bit of code above (after replacing “dolphin” with my custom post type) to the plugin files, functions.php and bp-custom.php but no luck.

      Comments made on my custom post type pages does not appear in the activity stream. Any ideas?

      Thanks

    • Johan 10:31 am on October 11, 2011 Permalink | Reply

      Bump. Anyone have an idea of why my custom post type comments won’t show up in the activity stream? Any suggestions on how to troubleshoot?

      Thanks!

      • Anthony 5:05 pm on January 10, 2012 Permalink | Reply

        Same here. Would love to get this working

    • Mika "Ipstenu" Epstein 1:12 pm on October 11, 2011 Permalink | Reply

      Johan – This is the wrong place to post that. You should post in the support forum.

  • Boone B. Gorges 6:59 pm on August 9, 2011 Permalink | Reply
    Tags: , , abstraction, bp_is_current_component(), bp_is_group(), bp_is_groups_component(), BuddyPress Group Email Subscription   

    In a few of the previous posts in the 1.5 plugin update series, I’ve talked about maintaining backward compatibility with earlier versions of BP while upgrading your plugins for BP 1.5. In those posts, I suggest the function_exists() method, which will always work nicely.

    However, there’s another method you might want to consider: update your plugin as if you weren’t going to support earlier versions of BP, and then conditionally include an abstraction file that defines the necessary functions. Here’s what I mean.

    When I was upgrading BuddyPress Group Email Subscription for BP 1.5, I wanted to make use of a few BP 1.5-only functions: namely, bp_is_groups_component() and bp_is_group(). So I did. Then, I created a new file called 1.5-abstraction.php, which looks like this. You’ll notice that I haven’t copied the functions directly over from the 1.5 source. The main reason for this (especially in the case of bp_is_groups_component()) is that the original function references bp_is_current_component(), which in turn has a bunch of complicated logic that is not necessary in my case. So, in my case, it made sense to take a minute to write less general functions from scratch. However, I could just as easily have copied these two functions directly into my abstraction file.

    Then, I loaded the 1.5-abstraction.php file conditionally, like so:

    if ( defined( 'BP_VERSION' ) && version_compare( BP_VERSION, '1.5-beta-1', '<' ) ) {
    	require_once( dirname( __FILE__ ) . '/1.5-abstraction.php' );
    }

    In this way, I only load the file when necessary.

    The nice thing about this method is that my main codebase remains clean and easy to read. When I decide to drop backward compatibility for early versions of BP, this file can simply be removed from the package.

    Another great thing about these abstraction files is that we can share them. Feel free to copy the small one from BP Group Email Subscritpion into your own plugin and build upon it – and share your own version with other developers.

     
    • Ray 7:12 pm on August 9, 2011 Permalink | Reply

      I just use `version_compare( BP_VERSION, ’1.3′ ) < 0`, which does the same thing, but I don't have to type out the long beta string ;)

    • Boone B. Gorges 7:39 pm on August 9, 2011 Permalink | Reply

      Smart :)

    • modemlooper 7:44 pm on August 9, 2011 Permalink | Reply

      but Apple has made it trendy to drop support and make things obsolete older than 6 months.

    • Stas Sușcov 8:09 am on August 10, 2011 Permalink | Reply

      Hey,
      I was thinking maybe bpdevel team should release those functions into a plugin?

      • Boone B. Gorges 4:41 pm on August 10, 2011 Permalink | Reply

        It’s a big job, and will create a really big file with functions that will be unnecessary for most plugins. That said, if someone wants to step up and do it, they are more than welcome :)

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Follow

Get every new post delivered to your Inbox.

Join 142 other followers