[buddypress-trac] [BuddyPress Trac] #6853: Autoload BP classes

buddypress-trac noreply at wordpress.org
Fri Jan 29 04:30:48 UTC 2016

#6853: Autoload BP classes
 Reporter:  boonebgorges           |       Owner:
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  API                    |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |
Changes (by boonebgorges):

 * keywords:   => 2nd-opinion has-patch


 [attachment:6853.diff] is a proof of concept. In my very light testing,
 BP's memory footprint decreases by between 1MB and 1.5MB by switching to
 autoload, since the only classes loaded into memory are those that are
 actually needed to display the page.

 The POC is a bit ugly because we don't have real namespaces, and our
 "namespaces" are inconsistently applied. (Though, to be honest, the
 `$irregular_map` lookup in the `autoload()` method is probably *faster*
 than the path concatenation. It's just harder to maintain in the long

 SPL can be disabled in PHP 5.2, so I've left a fallback in place, which
 uses the existing `bp-{$component}-classes.php` file.

 Any gotchas here? One concern is that the autoload logic - which looks for
 classes named `BP_{$component}_{$foo}` against a whitelist of BP
 components - might hit a false positive in a plugin that has a class name
 like `BP_Groups_Whatever`. This *shouldn't* happen because the plugin
 should be loading its own classes manually before they call them, but
 there could be a conflict if both BP and the plugin register their own
 autoload functions.

 Is it crazy to do this without PHP 5.3, with mandatory SPL and namespaces?
 Seems to me it's worth considering, given the memory improvements.

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

More information about the buddypress-trac mailing list