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

[buddypress-trac]

#7218: Only load component action and screen code when we're on the component's
page
-----------------------------+-----------------------
 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/>
BuddyPress Trac