More improvements to path generation in blog-related unit tests

Again, we're trying to avoid duplicate paths, so that WP doesn't throw a
hissy fit when trying to use the blog factory.

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8597 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Clean up `bp_blogs_add_user_to_blog()`:

* Compare user roles against `get_editable_roles()` so dynamic roles cannot be accidentally used.
* Use `array_shift()` rather than `array_search()` to speed up comparison.
* Add brackets and inline doc.

See #5749.

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8598 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
More clean up in `bp_blogs_record_existing_blogs()`:

* Do not touch the `$bp` global directly.
* Remove user/subscriber intersection and use `bp_blogs_add_user_to_blog()` instead of `bp_blogs_record_blog()`. This reduces complexity and leans on a function purpose-built for doing this comparison rather than duplicating part of that logic.

See #5749.

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8599 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
In `bp_blogs_add_user_to_blog0` call `switch_to_blog()` before running role comparisons to ensure roles for that blog are reinitialized correctly. See #5749.

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8600 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Revert r8600 for now, likely until roles and caps get themselves a nice overhaul. See #5749.

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8601 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Undeprecate bp_force_buddybar()

The change introduced in r8579 means that bp_force_buddybar() is still used in
a BP core function, and thus should not be deprecated. (If kept in the
deprecated functions file, a fatal error is caused when these files are not
loaded.)

See #5390

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8602 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Add the xprofile field visibility level as a CSS class for the field div

See #5238

Props sgr33n for an initial patch

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8603 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Introduce bp_get_the_thread_message_css_class()

This centralized function assembles CSS classes for message divs within a
single private message thread. In addition to the existing zebra-striping
classes, classes have been introduced for 'sent-by-[userid]' and 'sent-by-me'.

Fixes #5238

Props sgr33n for an initial patch

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8604 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Overhaul access and visibility control for group tabs

Previously, access control to group tabs was handled in two ways:
- for BP_Group_Extension tabs, the 'enable_nav_item' and 'visibility' provided
  some control over access to plugin developers, though it was inconsistent,
  buggy, and difficult to implement properly
- for tabs provided by bp-groups, access to the tabs of non-public groups was
  controlled directly in the BP_Groups_Component::setup_globals() method

Aside from being unclear for developers, this technique for controlling access
was also inflexible. For non-public groups, tab access was hardcoded and
handled before BP_Group_Extension plugins even had a chance to load. As a
result, it was essentially impossible to add public tabs to non-public groups
(among other non-standard customizations).

The current changeset comprises a number of changes that make tab access more
consistent and flexible:

- Access control is moved to the new bp_groups_group_access_protection()
  function. This function has the necessary filters to customize access
  protection in arbitrary ways. And because it loads at 'bp_actions' - just
  before the page begins to render - all extensions have had a chance to load
  and register themselves with the desired access settings.
- The 'visibility' and 'enable_nav_item' properties of BP_Group_Extension are
  phased out in favor of 'access' and 'show_tab' params. 'access' controls who
  can visit the tab, while 'show_tab' controls who can see the item in the
  navigation. These new properties have intelligent defaults (based on the
  privacy level of the group), but can be overridden with a number of custom
  settings: 'admin', 'mod', 'member', 'loggedin', 'anyone', or 'noone'.
  Backward compatibility is maintained, so that existing BP_Group_Extension
  plugins that use enable_nav_item or visibility will continue to work as
  before.

Fixes #4785

Props boonebgorges, dcavins, imath

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8605 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Add a CSS class to xprofile visibility radio buttons describing the visibility value

Fixes #5697

Props SGr33n

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8606 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
block_self should not block all buttons when inside a members loop on one's own profile

This changeset reconfigures the block_self logic in BP_Button so that the
bp_is_my_profile() check is skipped when inside of a members loop. This allows
block_self logic to operate properly when inside of a members loop that happens
to appear on the logged-in user's profile page.

Also adds unit tests for the block_self param.

Fixes #5734

Props r-a-y for the initial patch.

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8607 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Pinking shears

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8608 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Add missing unit tests from previous commit

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8609 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Untangle some load order and mutual dependency issues between component loaders

BuddyPress's components are dependent upon each other in numerous ways. All
components depend in one way or another on bp-core. Many components reference
bp-members functions and globals. References to bp-xprofile can be found in
a number of components. And so on. We have managed to make these dependencies
work on a case-by-case basis, though the system becomes less stable as it
becomes more complex. The fact that all components are loaded at
bp_setup_components introduces the possibliity of numerous race conditions that
may not cause problems on vanilla installations of BuddyPress, but can cause
fatal errors when trying to customize in various ways.

As part of an ongoing project to disentangle and regularize these dependencies
(see eg #5750), this changeset introduces a few enhancements that make the
dependencies between components more predictable, more serialized, and more
stable.

- In bp-members and bp-groups, move canonical_stack determination out of the
  main setup_globals() method and into its own setup_canonical_stack() method.
  This new method runs after all components have had a chance to run
  setup_globals(). As a result, the components are able to reference each other
  safely when determining default and fallback components for redirects (for
  example, the members component has access to the activity component's slug
  and other global data when determining whether
  example.com/members/boone/activity/ should resolve to example.com/members/boone/)
- In bp-members, use only WP core data to set up the loggedin_user and
  displayed_user global objects. Previously, these objects were configured by
  referenced to xprofile, which required that xprofile be loaded before members.
  Now, users' display names are first loaded from wp_users, and are overridden
  by the xprofile component via filter, only after xprofile has fully
  initialized.
- In bp-xprofile, move the Settings > Profile navigation setup routine out of
  the main setup_nav() task. bp-xprofile loads early, before bp-settings has
  had a chance to set up its top-level navigation. As a result, bp-xprofile
  must wait until the bp_settings_setup_nav action to add its Profile subnav
  item.
- Fine-tune the component load order. bp-core, which acts more like a library
  of common functionality than like a traditional component, is moved from
  bp_setup_components:10 to bp_loaded:0. This ensures that it is available to
  all other components. bp-xprofile, which must load after bp-members but at
  the same time is closely coupled to it, is moved to bp_setup_components:2,
  just after bp-members.

These changes are enough to make it possible to move forward on dependent
tickets; see, for example, #5407. It's likely that significant entanglement
and load-order issues remain. We'll continue to fix them as they arise, by
making load order more explicit, and by breaking the component bootstrap
process into increasingly discrete chunks.

Fixes #5436

Props boonebgorges, r-a-y

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8610 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
More conservative page_template checks in bp_is_current_component()

The page_template checks in bp_is_current_component() should not go through if
the currently queried object is not a single page (ie when a plugin is forcing
it to be a CPT archive). So we check for the presence of the `ID` property
before attempting to use it.

Fixes #5751

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8611 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Core: make the filter in `bp_core_register_common_scripts()` more useful.

Prior to this change, the data passed to the filter was pretty limited, making the filter
not very useful. This change makes the filter provide a full path for the scripts being
registered and allows scripts' dependencies to be set.

Minor codestyle improvements have also been included.

git-svn-id: https://buddypress.svn.wordpress.org/trunk@8612 cdf35c40-ae34-48e0-9cc9-0c9da1808c22