[buddypress-trac] [BuddyPress Trac] #7218: Only load component action and screen code when we're on the component's page
noreply at wordpress.org
Fri Feb 2 16:44:13 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 johnjamesjacoby):
I still don't like the changes proposed here, and 1% doesn't seem
significant enough to me.
It also seems like a "classes are better" approach that gets negated when
PHP eventually improves the way files and/or functions are loaded. We'll
have introduced classes we're stuck with maintaining that don't actually
do what classes are intended to do.
I also have a hunch the next bit of code we write to try to mask this
complexity will probably negate the 1% improvement @boonebgorges found
I'm still not convinced this is worth it, but I don't want to be a blocker
towards motivation and/or progress.
What I'd want to see:
* A base class that provides some value to all these screens and actions
* Consider renaming classes away from `Action` to avoid confusion with
WordPress action hooks
* Consider breaking mono-methods up into ones that: check permissions,
check the correct screen/action are being called, call a display() method
for their output, etc...
* The `bp_actions` and `bp_screens` hooks are already abstractions of the
`bp_uri` routing system. Is there anyway these classes can talk directly
to that instead of being stubbed in the way they have been?
Because of the functional nature of action & filter hooks, we'll never
completely get to the point of conditionally loading
code/files/functions/classes until we include a dictionary of hooks to
files. Other projects (Woo, EDD) are thinking of trying this, and I'm
cautioning them against it, too, at least today.
A more complete, albeit totally insane, approach would be to:
* Create wrappers for `add_action/add_filter/do_action/apply_filters` and
hook everything into a central routing system
* Listen for hooks to be executed
* Magically include relative files just-in-time as their relative hooks
To do this, we'd probably want to:
* Create a script that generates an autoload-stuff.php file, based on what
functions are hooked in where and when
* Add that script to our grunt build process, so it stays up to date as
new things are hooked in
* Include that autoloader, which is basically just a big array of files to
My above hunch of overhead vs. value applies to the proposed patch and my
terrible idea. After introducing this extra code complexity, what does
BuddyPress (or it's community of users/developers) gain? Is anything
actually easier to use/understand? Have we increased performance or
reduced consumption by more than what it took to support it? Are these
classes easier to interact with? Have we architected an inviting
environment to increase BuddyPress adoption?
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7218#comment:53>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac