[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 schlessera):

 Replying to [comment:117 Clorith]:
 > 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.

 What you're describing is certainly something worth discussing. I'm not
 happy with that terminology, however, because it relates this to the
 already "pluggable" elements in WordPress Core like `db.php` and
 `advanced-cache.php`. The point about these is that '''they are meant to
 be replaced'''.

 Nobody is meant to replace core WordPress classes. And if they do, they
 would have done it with or without an autoloader. The addition of an
 autoloader does not in any way change the fact that plugins can already
 replaces whatever they want on most systems, and cause havoc. Correct me
 if I'm wrong, but I think that on most systems (those which belong to
 "end-users"), a plugin can replace any filesystem file within web root if
 it wants. So, with or without an autoloader, there are no guarantees, and
 you can't keep malicious/un-smart people from doing malicious/un-smart
 things.

 Does that mean that we should discuss how best to proceed so that some
 precautions can be taken? Yes, absolutely! But does that mean that we
 should avoid a definite code improvement because it could be "mis-used"? I
 don't think so. I'd rather, we make it easier and better for the proper
 developers to do their jobs and for WordPress Core to more easily adapt to
 changing requirements.

 > 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.

 Well, although I don't see why this would be an "autoloader issue" (as bad
 plugins kill users' sites, even today), I understand why we might need to
 worry that errors happen at a different level and prevent plugin
 deactivation (although I'm sure almost any "end-users" have had to deal
 with a WSOD before). So, apart from improving the WordPress error handler
 in general, we might also improve the standard class loader that gets
 registered to provide some safeguards. These safeguards would have a minor
 impact on performance, though, so ideally, we could also provide a switch
 for the pros to just disable these safeguards. If end-users are a concern,
 a proper error handler would not kill the site, but allow admin logins in
 safe-mode and ask the user whether to deactivate the offending plugin. But
 that's definitely a topic for a different ticket.

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