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

 > I can't see why a plugin would want to do that, and it would probably
 break half of the time, because autoloading means there's no set point in
 time where you know the class was or wasn't loaded any more.

 Unfortunately this is not entirely true. The plugins are loaded relatively
 early. They will always be loaded before a bunch of classes are first
 needed effectively letting the plugins always "preload" some classes. I
 agree with @Clorith: "...you say they shouldn't, I agree. But from
 experience, they will, they most definitely will."

 Having "pluggable" classes in WordPress is out of the question.

 @schlessera, @flixos90, @flixos90 not sure how well you know the WordPress
 codebase but there is a thing called "pluggable.php". As far as I know
 this is a left-over from forking b2 14 years ago that wasn't fixed/removed
 in time. This is probably the worst architectural decision ever. Why would
 you want to extend it? :)

 > Autoloading has several benefits out of the box, even with a more
 procedural codebase like WordPress

 I agree. Autoloading is great for classes. After a quick look through the
 code, about 80-100 of the 200 classes will always be loaded, and half of
 the rest would never be loaded together. So currently autoloading will
 affect maybe about 5% of the code. This is still good, that percent will
 increase in the future.

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

 Not true. Plugins cannot replace any of the `required` classes.

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

 Totally agree. As far as I see the way to proceed here is:
 - Make an experimental branch where all this can be tested and cleaned up
 before merging in core.
 - Find a way to "lock down" core classes so they cannot be replaced by
 plugins. Think of this like having the `final` keyword in class
 definitions. One possible way would be to have a custom autoloader that
 has a list of the core classes and doesn't do `class_exists()` before
 loading any of them (and keeps some sort of state to test if they are
 already loaded).

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