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

 Replying to [comment:171 TJNowell]:
 > Nobody is suggesting we bundle Composer with WordPress.

 Not true.  From @schlessera's own comments on his proposal we are
 discussing:

  For the approach I recommended above, Composer would only be used at
 development time for as long as WP stays at PHP 5.2. After that, you can
 just as well include Composer with WordPress, it does not need to be
 installed globally. So, if you want to bake in an autoloader into
 WordPress Core, why not just use the one that the rest of the PHP world
 uses?

 > Composer generated autoloaders are widespread, well known

 The fact that something is in widespread use is not a reason to use it
 '''when it is not fit for purpose'''

 Composer champions an approach that places '''all''' autoloadable classes
 into a `/vendor/` directory and then maps to the file based on class
 names.  WordPress places autoloadable files in at least 5 different
 general locations and mapping from classname to those locations would
 require torturous naming conventions, or it would require the Composer
 autoloader to look into tens if not hundreds of directories:

 * `wp-includes`
 * `wp-admin`
 * `wp-content/plugins/`
 * `wp-content/mu-plugins`
 * `wp-content/themes/`

 Sure, we could collapse `wp-admin` into `wp-includes by moving all the
 admin classes into `wp-includes`, but does that really make sense?

 Then within each of `/plugins` and `/mu-plugins` there can be a
 potentially unlimited number of locations to look for classes to autoload.

 '''The fact you cannot map classes in WordPress plugins and themes simply
 by their classnames is the main reasons why Composer is not a good fit as
 an autoloader for WordPress. And no one on this ticket has acknowledged
 and addressed this concern.'''

 I have been working with this exact problem in WPLib for several years, so
 I have some strong insight into the problem. I know that had I not gone
 through this painful effort I would not have recognized the issues with
 Composer either and would have thought using it to be a great idea.
 Matter of fact, I previously did think Composer was a great idea for
 WordPress.

 Autoloader requirements for add-ins turns out to be different than an
 autoloader for site builders unless WordPress changes the location of
 plugins and themes to be inside a `/vendor/` directory. And even then it
 would still have an impedance mismatch.

 Really '''the only approach that works across all of WordPress is a
 classmap''', and there is no reason to include a complex Composer
 autoloader just to get a classmap autoloader.  And having core use its own
 classmap autoloader does not preclude anyone from using Composer's
 autoloader for PSR0/4 libraries.

 > Composer generated autoloaders are ... reliable, well tested,

 A classmap autoloader is so trivial that it makes this concern moot.

 I could provide a working example to illustrate but this discussion is
 coming at a really bad time for me because I have other hard deadlines
 over the next 10 days that keep me from devoting the time to it.

 > This gets you these 10 files:

 Why include ''(some of)'' these 10 files when you really only need two
 '''trivial''' files?  One containing a trivially simple autoloader and
 another file containing a trivially simple classmap?

 In addition core could load core's classmap and then run hooks to allow
 plugins and themes to contribute their own classmaps.

 > Composer can also be passed a generator that controls what is generated
 when an autoloader is created. The above list is merely the default.

 Yes Composer is flexible, by why go to so much effort to make it contort
 in ways
 [https://github.com/composer/composer/issues/3852#issuecomment-172925273
 the Composer team choose not to support]? ''(Go back and read
 [https://github.com/composer/composer/issues?utf8=%E2%9C%93&q=is%3Aissue%20wordpress%20
 some of their GitHub discussions].)''

 BTW, I do really like the OP's original proposal of having pluggable
 autoloaders to make it easy to use PSR0 and PSR4 when '''''site
 builders''''' want to use libraries that were designed with  PSR0/4 in
 mind.

 > I'd also advise against including the autoloader in wp-config.php, wp-
 config.php is for setting constants and configuring, including the
 autoloader there will necessitate modifying every config file that exists
 already, as well as handling those scenarios when the file is up one
 directory, etc

 Agreed there.

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