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

 Replying to [comment:130 schlessera]:

 > The shortcodes API change broke the actual user content in the databases
 of the users.

 No. The change broke the way some plugins use shortcodes. Shortcodes are
 placeholders. Nothing more. That breakage happened because these plugins
 misused the core functionality and used the shortcode API in an unintended
 and unsupported way, even introducing security problems in the process.
 And that happened because the API was (and still is) too permissive.

 > The original "pluggable.php" was a mechanism where developers '''were
 meant to replace''' core parts, and it was badly designed to fulfil that
 purpose. Here, we developers '''are not meant to replace''' classes, and
 the possibility to do so nevertheless is just part of the language. You
 can't make the fact go away that bad coders will do bad things. If they
 intend to replace a class, they will do it, with or without autoloader.

 Right. In "pluggable.php" this is the intended behaviour, and the design
 is bad. However because of the way WordPress works, adding standard
 autoloading of classes introduces exactly the same design flaws like in
 pluggable.php. Of course we can add all the documentation and warnings we
 want, but do you believe all developers will always follow them? After the
 example with the shortcodes the answer tends to be firm "No".

 I'm not sure how to make this easier to understand :) This is somewhat
 similar to using `private` in a class. Is there even one OOP app out there
 that instead of using `private` adds some documentation like "Please don't
 touch this from the outside. Thanks.". Why is there a `private` keyword
 anyway? :)

 > > Not true. Plugins cannot replace any of the `required` classes.
 >
 > They can replace pretty much any object that is stored in a global
 variable. They can overwrite Core files (on most systems). They can
 replace a lot of core functionality through hooks.

 Not exactly. The parts that are replaceable through hooks are sufficiently
 "insulated" and we go to great lengths to maintain backwards compatibility
 for them. Replacing globals doesn't work in many cases as most classes are
 instantiated right before using them. That makes it quite inconsistent
 even for badly written plugins.

 At the same time I'm sure there are plugins that are trying to do that
 even now. This is very limited simply because it doesn't work well.
 However if we let such plugins replace core classes before they are
 loaded, they will.

 > That's not how an autoloader works. The autoloader does not do
 `class_exists()` because it will only get invoked if it doesn't yet. If
 the class has already been defined, the autoloader will not even be
 triggered.

 What I meant is that one possible way of making this work would be to
 rewrite the logic that checks whether a class is already loaded, and add a
 whitelist of the core classes. If a core class is not loaded from the
 respective location/file, it would throw an exception and `exit`. This was
 just a quick suggestion. Hopefully there is a better way that would let us
 use the native PHP functionality.

 > As there has not been an autoloader so far, the code is not optimized to
 make effective use of an autoloader. This is something that can be easily
 changed, though.

 No, what I mean is that no matter what we do, many classes will always be
 loaded as they are needed by the rest of the procedural code. Most of the
 remaining classes are never needed together. They will never be loaded at
 the same time with or without an autoloader. So currently any gains from
 autoloading in WordPress are minuscule. This doesn't mean we shouldn't add
 it, but we shouldn't set any expectations that it would make WordPress
 lighter or faster.

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