[buddypress-trac] [BuddyPress Trac] #6026: And if the Blogs component had Single items?

[buddypress-trac]

#6026: And if the Blogs component had Single items?
------------------------------------+-----------------------
 Reporter:  imath                   |       Owner:  imath
     Type:  enhancement             |      Status:  assigned
 Priority:  normal                  |   Milestone:  2.7
Component:  Blogs                   |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |
------------------------------------+-----------------------
Changes (by imath):

 * keywords:  dev-feedback has-patch needs-refresh => dev-feedback has-patch
 * owner:   => imath
 * status:  new => assigned
 * milestone:  Future Release => 2.7


Comment:

 So i'm back on this ticket, and i'll do my best to have it fixed for the
 2.7.0 milestone :)

 This time, i'll try to work in smaller steps, so that reviews are easier.
 The first step `6026.smaller-steps.01.patch` is about DB and files
 organisation.

 1. I'm adding a new field `is_contributor` to `$wpdb->bp_user_blogs` to
 prepare the site subscriptions feature. Contributors will have this field
 set to 1, and subscribers set to 0. I've also edited a bunch of methods in
 `BP_Blogs_Blog` to take this change in account.
 2. I'm adding a new `Site settings` section where it is possible to easily
 completely deactivate front-end site subscriptions. BTW a site
 subscription is a way to get the subscriber role for a site. When i'll
 build the step for the sites single items, i'll add a new single site
 options (using blogmetas) Site admins will be able to use to disable
 subscriptions for their specific site.
 3. WordPress 4.6 is introducing a very interesting class `WP_Site_Query`
 to query for sites. So i thought we should use it to progressively replace
 the way we are querying sites in `BP_Blogs_Blog::get()`. In the patch,
 you'll see that i check for the `get_sites()` function before using it, if
 the function is not available (WordPress is < 4.6) we fallback on
 `BP_Blogs_Blog::legacy_get()` which has improved a bit how we fetch sites
 and makes sure it can also handle single site queries.
 4. As the site subscriptions feature is optional, i thought we should load
 more "granuraly" the code for the site feature. In other words only load
 the needed code if active components or options allowes us to use it. So
 the `bp-blogs/bp-blogs-site.php` file only loads if `bp_is_active(
 'blogs', 'site' )` and inside it files are `required` only if components
 or the site subscription are active. Most of the files like `bp-
 blogs/site/functions.php`, `bp-blogs/site/template.php`... aren't finished
 yet as it's the first step of the patch :)
 5. I've edited the `phpunit.xml.dist` unit test configuration file,
 because it seems a bit weird to include multisite tests into regular
 tests. So i've added to it a group exclusion (multisite) which allowes me
 to only tests specific multisite tests when the multisite.xml
 configuration file is used (and avoids the `! is_multisite() return;`
 we're currently using inside each multisite specific tests). I'm also
 adding a new configuration file `subdomains-multisite.xml` because it's
 pretty different when `SUBDOMAIN_INSTALL` is true to query for the site's
 slug. These are suggestions, we can adopt or not.
 6. I've edited some tests so that the legacy_get() function is still
 tested in WordPress 4.6+ and add a new one for the single site query.

 Finally after applying this patch, the only difference you can see is how
 the `$wpdb->bp_user_blogs` is populated since the introduction of the
 `is_contributor` field. Depending on the site subscription settings, a
 subscriber will be added or not to this table. If a `user_can(
 'edit_posts' )` role is changed to a subscriber role, it will have his
 contributor field set to 0 (if subscriptions are enabled) or he will be
 removed from this table (if subscriptions are disabled). Today, he stays
 inside this table no matter the changes (till the site owner uses the
 repair tool).
 I'm also introducing a new `site_admins`blogmeta to store the list of
 admins. This way i'm making sure the user avatar is the one of an admin
 and not a contributor as it can be today. + this blogmeta will be usefull
 later for other needs.

 This is it for this first step, feedbacks are very welcome. In the
 meantime, I'm moving to step 2 :)

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6026#comment:33>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac