[buddypress-trac] [BuddyPress Trac] #6026: And if the Blogs component had Single items?
noreply at wordpress.org
Mon Jul 25 09:11:09 UTC 2016
#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
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
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
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/>
More information about the buddypress-trac