[buddypress-trac] [BuddyPress Trac] #7218: Only load component action and screen code when we're on the component's page

buddypress-trac noreply at wordpress.org
Fri Feb 2 02:46:40 UTC 2018

#7218: Only load component action and screen code when we're on the component's
 Reporter:  r-a-y            |       Owner:
     Type:  enhancement      |      Status:  reopened
 Priority:  normal           |   Milestone:  3.0
Component:  Core             |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch early  |

Comment (by boonebgorges):

 Let's move forward with this ticket. The patches are huge and keep getting
 stale. Let's get it in.

 == Benchmarks ==

 I ran some primitive benchmarks to gauge memory + time changes. (I set up
 a logger that captures memory usage and elapsed wall time in a log file at
 `register_shutdown_function()`, and then I used Apache Bench to hit a URL
 - in this case, example.com/activity/ - 100 times, to gather averages.)

 A: Trunk
 B: Trunk with activity-v3.patch
 C: Trunk with activity-v3.patch + groups-v3.patch

    Avg Mem  | % Diff Mem | Avg Time | % Diff Time
 A  60,436KB |     -      | .476668s |     -
 B  60,336KB |   -0.17%   | .476679s |   +0.002%
 C  60,136KB |   -0.50%   | .468618s |   -1.69%

 Worth noting that these percentages are against the entire memory/time
 footprint of the WP installation (with many plugins active, etc). The
 percentage of BP-specific resources that are saved by this change would be
 larger. And as we add components, the numbers will get larger.

 Obviously these are rough numbers, but I think it shows that the
 improvements are meaningful enough to make the project worthwhile.

 == Questions ==

 I'll be combing through the patches one component at a time (there's a lot
 there!) and I'll have a couple of questions before giving a final signoff
 on each.

 1. The checks that remain in the `-screens.php` and `-actions.php`
 functions are mostly of the form `bp_is_current_component()`, etc. In
 other words, mostly "routing" logic - only load if we're in the right
 place. I think this makes sense. But in a number of cases, you're also
 checking `is_user_logged_in()`. To my mind, this is a permissions check,
 and permissions checks should be kept together, to make future security
 reviews easier to reason about. @r-a-y Do you have thoughts about that, or
 am I overthinking?

 2. The only potential compatibility breaks I see in
 [attachment:7218.activity-v3.patch] are related to the new `-feeds` file.
 That is: Screen/action functions that are converted to wrappers for
 classes will continue to be available as they always were. But functions
 moved to a new file `bp-activity-feeds.php` and then not loaded until
 later are potential vectors for breakage. I assume that the reasoning
 behind bp-activity-feeds.php and the `late_includes` strategy is to pare a
 bit more stuff out of the initial pageload. This is sensible, but in my
 opinion, it's too much engineering for a very modest gain. Perhaps new
 functionality could be introduced in a late-loading way, but the edge-case
 potential for breaks leads me to think that maybe we can just keep the
 `feed` functions in `-actions.php`. @r-a-y Have I understood this
 correctly? What do you think about rolling this change out, at least to
 simplify the specific task at hand?

 3. Similar to 1 - [attachment:7218.groups-v3.patch] has some permissions
 checks `bp_user_can_create_groups()`, some nonce checks, and even does
 some `bp_core_redirect()` logic. For consistency, I'd be in favor of
 moving this logic into the new classes.

 4. Not a question, but good catch on
 `bp_groups_update_orphaned_groups_on_group_delete()` :)

 5. `groups_screen_notification_settings()` is not really a screen
 function, as it doesn't load a template. I'd favor moving it elsewhere,
 and not treating it with a `Screen` class.

 @r-a-y I know that a few of these suggestions require a non-trivial amount
 of work (especially 1 and 3) so please let me know your thoughts before
 rushing in. I can help to update the patches if that eases the pain at all

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7218#comment:52>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list