BP Registration Options 3.0.3 with Fixes for BuddyPress 1.3 – Trunk

Just posting some modifications made to get the BP Registration Options 3.0.3 plugin working with WordPress 3.2-trunk and BuddyPress 1.3-trunk that I needed for a current project. This was only tested on a WordPress multi-site network with BuddyPress and using sub-domain mapping, so my modifications may not fix everything for you. I also did not build in any backwards compatibility or test with BuddyPress 1.2.8. Here are my notes.

  1. I got the menus added to the WordPress multi-site “Network” menu.
  2. Removed the global $iprefix and went with $wpdb->base_prefix to set the database prefixes instead. Not really necessary, but cleaner and possibly more appropriate.
  3. Created the pbrwg_get_loaded_components() function to replace $bp->root_components since I think it’s depreciated. The pbrwg_get_loaded_components() uses the $bp->pages objects to build an array with the component name as the key and the slug as the value. This should replace some URL parsing since $bp->current_component can be used instead of trying to figure out the URL to component relationship.
  4. Changed the ‘bp_core_activate_account’ action for ‘bp_members_activated_user’ and passed through the user-ID.
  5. Changed a few values from string to INT where possibly appropriate.

Stopped myself, but probably could have done some isset() and empty() in a few places. I didn’t want to rewrite the whole plugin because I’m expecting this will improve as BuddyPress gets updated, and I don’t want to merge a massive change back into the current project using this plugin. BP Registration Options has a nice simple premise, but just needs a little code simplification love (not that my_overly_verbose_ass can do any better).

All the changes are in this package: BP Registration Options 3.0.3 with Fixes for BuddyPress 1.3 (zip)

3 responses to “BP Registration Options 3.0.3 with Fixes for BuddyPress 1.3 – Trunk”

  1. Nice – thanks for making the changes, and for making them public so that others can benefit from them.

    Re pbrwg_get_loaded_components(). I’m not sure I understand 100% what you’re trying to do with it, but I thought I would take a minute to explain some component-related changes in 1.3 trunk that might make some of your work easier:
    – The new function bp_is_current_component() contains a generous way of checking the current component, and will accept a number of different kind of arguments: component slugs (the old way) like $bp->groups->slug; canonical, non-translatable component names (like ‘groups’); and new “root slugs”, which are the slugs, relative to the root_domain, of the WP page corresponding to the component (like ‘community/groups’, if your Groups page is a child page of Community).
    – You’re right that root_components is deprecated (by $bp->pages, essentially) but we do have a couple other new values in $bp that might help: $bp->activated_components, which is populated by the items you have checked in on the Components tab of the Dashboard; and $bp->loaded_components, which is populated by the components that actually successfully load.

    Thanks again for your post!

  2. Thanks Boone! This post was really for the folks at http://webdevstudios.com/ since it’s their plugin, but I’m sure it’s gonna help a few others. I needed to fix it for a skills profiling project at work.

    I’m glad you mentioned that I was on the right track with $bp->pages. The current version of this plugin does a little ugly URL parsing. Hopefully this will help the developers since it is a very useful plugin.

  3. Oh yea. I needed to mention I’m only using that pbrwg_get_loaded_components() function to set up a key value pair from $bp-pages that makes the “Privacy Settings” for this plugin.

    This is a shoehorn hack job. :P

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.