[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 19:35:18 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 r-a-y):
Thanks for the feedback everyone.
Replies to @boonebgorges follow:
1. `is_user_logged_in()` checks are to improve the load time for logged-
out users. That's why they do not reside in the classes. If we want to
unit test these new classes with `is_user_logged_in()`, we can add
additional `is_user_logged_in()` checks to the class files.
2. `late_includes()` method strategy was part of an earlier idea to
offshore all of our action and screen code until we've actually landed on
the component's page. This would have increased our memory savings, but
due to concerns with this strategy and to be safe, I compromised on a
class-autoloading strategy to prevent potential breakage. The reason I
separated activity RSS feeds in the `late_includes()` method is RSS feeds
likely are never touched by other plugins so the potential for breakage is
very low. I would prefer all future code to be written in a way that
utilizes the `late_includes()` strategy, but if that isn't desired, I can
roll back these changes as well.
3. I had a hard time thinking if nonce checks should be in the class or
not. I think we can move the nonce and permissions checks to the class.
Don't really have an issue with this.
5. Yeah, could use your recommendation on naming for this. Or we just
omit the new class additions for these functions.
Replies to @johnjamesjacoby follow:
As I mentioned in my reply to Boone in point 2, I prefer my earlier idea
to load all action and screen code when we're on the component page rather
than the class-autoloading in the current patches. To me, that is the
cleanest way of doing this within our current APIs instead of introducing
all these new classes and files.
To be honest, my idea in #7666 (load template functions only when the
template loop is initialized) will dramatically increase even more memory
savings and I would rather spend time working towards a solution for that.
I think the idea to create wrappers for add_action() and add_filter()
would introduce even more complexity than it already is for developers new
to BuddyPress. Relying on Grunt to do this properly (much like how
Composer writes its autoload.php file on generation) would take awhile to
write and build. I do like this idea though and would wonder how it would
all look like.
I honestly think BuddyPress is at an important juncture where we need to
start optimizing before we increase the codebase with even more features
and that's what my recent tickets have been exploring.
We have to do something now rather than later.
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7218#comment:54>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac