Skip to:

Opened 11 years ago

Closed 11 years ago

Last modified 8 years ago

#4671 closed enhancement (fixed)

BuddyPress Default Components

Reported by: johnjamesjacoby's profile johnjamesjacoby Owned by: johnjamesjacoby's profile johnjamesjacoby
Milestone: 1.7 Priority: high
Severity: normal Version:
Component: Administration Keywords:
Cc: mercijavier@…, georgemamadashvili@…, vpundir@…


In Vancouver, the core team (minus Paul) discussed the idea of switching up the default components that BuddyPress comes activated with. I think the "all-on" approach is overwhelming for new users, can be confusing, and isn't a very rewarding experience.

Since every component is pretty awesome, and they all rely on each other in some way, the idea of turning components off at all is a little weird at first. Each component has strengths, weaknesses, and potential to be extended into something more than it starts as.

I'm mostly agnostic about which components make the most sense as the default ones, but if I had to pick a favorite, I think having activity streams and profiles turned on, with everything else turned off, would make the best starter experience, and here's why:

  • Profiles are completely missing from WordPress.
  • Friends don't make sense without profiles.
  • Groups don't make sense without users and profiles.
  • Settings doesn't make sense without profiles.
  • Private messaging is useless without a profile to connect it to.
  • Forums come with bbPress now, and don't need profiles to function at all.
  • Activity streams don't make sense without profiles, but they can run pretty silently in the background and aggregate activity.

It's true that even with the XProfile component off, BuddyPress still fakes the profile experience pretty well. I'm imagining an activation experience without a setup wizard. One where when BuddyPress is activated on a new installation, the admin is greeted with a message like:

Welcome to your new community! Check out your new profile to get started''

With a tabbed What's New/Credits page like WordPress core has, we could easily explain what the components are, and why they might want to roll them out over time. Opening this up for discussion here, with the intention of getting this decided shortly after this weeks dev chat, and into trunk soon after.

Change History (16)

#1 @mercime
11 years ago

  • Cc mercijavier@… added

#2 @Mamaduka
11 years ago

  • Cc georgemamadashvili@… added

#3 @sooskriszta
11 years ago

Check out your new profile to get started

is a bit odd. Maybe "fill out" or "create" your new profile to get started?

#4 @sooskriszta
11 years ago

  • Cc vpundir@… added

#5 @johnjamesjacoby
11 years ago

(In [6558]) See #4671:

  • Round one changes...
  • Remove the cumbersome update wizard and associated CSS and images.
  • Copy "About" and "Credits" pages from bbPress.
  • First pass at default components array.
  • Deprecate some functions, consolidate others.
  • Introduce bp-core/admin/bp-core-actions.php to handle admin sub-actions.
  • More to do here (update script, testing, css/images, etc...)

#6 @johnjamesjacoby
11 years ago

  • Resolution set to fixed
  • Status changed from new to closed

First pass at this is done. The rest need to be hammered out with new activations. Things like auto-page creation, etc... Not worth spending too much time on, as core rewrites in 1.8 will fix this up much more nicely.

#7 @DJPaul
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Noticed that activating the retired Group Forums component deactivates all other active components.

I also assume the "install group forums" screen was been intentionally removed. This is a bit annoying for BP plugins that have a hard requirement of the Group Forums on new installs, such as BuddyPress Courseware, but this isn't the end of the world.

#8 @vinaysagar4u
11 years ago

Ohh no. Anything but BP Courseware. :)
I'm on Buddypress only because of BP-Courseware

#9 @djpaul
11 years ago

(In [6672]) Make new BuddyPress installs run the DB table schema and set the Activity and XProfile components to be active by default. Fixes #4733. See #4671.

Also fixes a problem with the 1.5/1.6 upgrade code not being run by sites upgrading from pre-1.5.

#10 @DJPaul
11 years ago

To do:

  • Is the wp_cache_flush() in 1.6 step_components_save() needed anywhere in 1.7?
  • Need to port step_pages_save() to auto-create pages.
  • The "missing page" nag seems to be missing; we should add all of bp_core_activation_notice() back to 1.7, it's helpful for debugging on the support forums.
  • Adding back bp_core_activation_notice() will also display a "you need to set your permalinks" nag if required. I don't think we should quietly/automatically change someone's permalinks if they are installing BuddyPress.
  • We need to force-migrate pre-1.5 upgraders away from the Toolbar as discussed somewhere recently (a dev chat?).
  • Bug: activating the retired Group Forums component deactivates all other active components.
Last edited 11 years ago by DJPaul (previous) (diff)

#11 @djpaul
11 years ago

(In [6673]) Fixes a bug introduced in r6672 where the schema of old tables was not being updated on upgrades from early versions of BuddyPress. Antiprops DJPaul. See #4733, #4671.

#12 @djpaul
11 years ago

(In [6693]) Make new BuddyPress installs (and <1.5 upgrades) automatically create pages for component mapping. See #4671.

#13 @djpaul
11 years ago

(In [6695]) Bring back bp_core_activation_notice() from the bench; it provides a notice for admins if pretty permalinks aren't enabled and/or the BP component/page mapping is incomplete. See #4671.

These notices are helpful for debugging people's sites on the support forums, and for telling people they need to set permalinks. Most (all?) of this will be taken back out in a future version of BuddyPress when we switch to using rewrite rules.

This commit also accidentally fixes a regression in trunk where, if the Blogs component is active on multisite, we weren't recording existing blogs' information for use in the Sites Directory.

#14 @boonebgorges
11 years ago

(In [6842]) Improves the save routine for the Components Dashboard page

The subtabs of the Components Dashboard page (All, Active, Inactive, Must Use,
Retired) all work differently in terms of how data is returned from them. Some
of the subtabs - All and Active - are accurate reflections of the components
that the user currently wants to be active. Retired and Inactive, on the other
hand, don't contain complete data about which components are supposed to be
turned on. For that reason, we can't trust the checkbox data submitted through
the POST when setting the active components.

This changeset introduces bp_core_admin_get_active_components_from_submitted_settings(),
which handles the logic necessary to determine which components the user
intends to be active, based on the data submitted in the POST request. It's
been separated out into a standalone function for better unit testing.


See #4671

#15 @DJPaul
11 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

#16 @DJPaul
8 years ago

  • Type changed from task to enhancement
Note: See TracTickets for help on using tickets.