[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal

[WordPress Trac]

#36335: Next generation: core autoloader proposal
-----------------------------+------------------
 Reporter:  dnaber-de        |       Owner:
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  4.7
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------

Comment (by Clorith):

 I fear I might've not used my words right, and my intent wasn't very
 clear, so let me try again :)

 My worry is that per today's approach, core loads certain things up, and
 they are there; with auto loading, they're never really loaded until they
 are needed (if not already loaded), so if a plugin loads up the same class
 name, we won't load ours. There's currently a list of some 70-80 files
 from `wp-settings.php` which are not pluggable in any way, but with this,
 those would also be re-enabled (unless I'm missing something here, and I
 would be happy to be told so :) )

 This increases the probability of breakage, and we are enabling them to do
 so, we are "making core pluggable" (which is a terminology I like for
 this) by allowing replacement of previously non-replaceable classes, and
 it means even something simple like a bugfix to a class in a point
 release, which are automatically pushed, could result in unexpected
 behavior one way or another.

 You're right that we shouldn't let other plugin or theme developers affect
 how we implement things, but we DO NEED to take user expectations into
 consideration, and users won't know what's going on when one plugin
 declares a core class which another plugin relies on later down the line
 and gets a whole different behavior because the first one to load their
 own isn't a carbon copy of core, or they both try to declare that same
 class because core is pluggable now because we never load up core versions
 of classes if they are already declared.
 From a users point of view, their site is now broken, and they may not be
 tech savvy enough to fix it (because a fix to a fatal error requires hands
 on modifications one way or another), and this would be on us, we enabled
 them to break it this badly and if we can let them break it, we should at
 least make an effort to help prevent it.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/36335#comment:117>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform