[wp-trac] [WordPress Trac] #21300: Implement autoloader compatible with PSR-0 / PSR-4 for plugins and themes

[WordPress Trac]

#21300: Implement autoloader compatible with PSR-0 / PSR-4 for plugins and themes
-----------------------------+-------------------------
 Reporter:  dave1010         |       Owner:
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Bootstrap/Load   |     Version:
 Severity:  normal           |  Resolution:  maybelater
 Keywords:                   |     Focuses:
-----------------------------+-------------------------

Comment (by F J Kaiser):

 Replying to [comment:19 Denis-de-Bernardy]:
 > It would be *very* sweet if, instead of needing to dig through a
 hodgepodge of files in order to locate a class, one could find
 `Foo_Bar_Baz` in `Foo/Bar/Baz.php`.

 It would be *much* sweeter if we could simply write

 {{{use WCM\FooBarPlugin\Controllers\PostLoopController;}}}

 and then instantiate {{{$loop = new PostLoopController();}}}.

 Replying to [comment:20 MikeSchinkel]:
 > Please don't. Deep directory structures are a real pain to deal,
 especially when you are talking about a small number of files like with
 most plugins.

 That's why we got PSR-4 nowadays. Less deep nested than PSR-0.

 Replying to [comment:19 Denis-de-Bernardy]:
 Keep in mind that this (your example autoloader) isn't all of it. We'd
 need a logger as the [https://github.com/php-fig/fig-
 standards/blob/master/accepted/PSR-3-logger-interface.md PSR-3 specs]
 state that there should be no interruption of the loading process and
 later autoloaders should be given the chance to have their own attempts at
 loading files. And as debugging without errors, warnings and notices is a
 guessing game, it won't work without a PSR-3 compatible logger.

 Replying to @Everybody:

 Proposal: As PSR-4 keeps the rule of two namespace levels for vendor and
 bundle/package, we could easily use one big namespace {{{WPPlugin}}} that
 points to {{{~/wp-content/plugins}}} (or whatever is defined) and then add
 all plugins into vendor folders. Example:

 {{{namespace WPPlugin\HyperMegaSEO;}}}

 '''Summed up:''' We need a PSR-4 compatible autoloader to not have
 unnecessary deeply nested folder structures. It needs to work together
 with other PSR-4 compatible autoloaders and it has to be silent and has a
 PSR-3 compatible logger (I'm not going to punch anyone for that
 Singleton!) for debugging.

 Also it has to play nice with other PHP-fig/PSR compat autoloaders. Else
 you would break all my plugins that use stuff like
 [http://guzzle.readthedocs.org/en/latest/ Guzzle] or that parts that I
 reuse from (for e.g.) Symfony2, Zend or elsewhere from user land.

 And Composer has proven to work seamlessly in WordPress installs (powered
 by at least PHP 5.3), I don't see a reason why we should cook our own
 soup. We have to play nice with other autoloaders anyway to not break tons
 of installs. So let's face it: We have jQuery in core because it's easy to
 use, widely accepted and has a big contributors base and on going
 development. The same goes for backbone.js. Why not use Composer?

 ''Additional notes and thoughts:'' Most of the major PHP frameworks
 already use Composer: Zend2, Symfony2, Laravel. IIRC Yii and CakePHP use
 an incompatible one (dunno if that's still true) while the one from
 Phalcon works nicely when switching to Composer. Drupal8 will be shipped
 with Composer and make use of Symfony2 bundles. Imho this will have a huge
 impact as it's plugin/module (whatever it's called) base massively
 increase overnight. They will have thousands of well coded (and tested)
 bundles at their fingertips. If we want to keep pace with what's happening
 there, I don't see any way around using Composer as developing and
 maintaining our own Autoloader (plus a package/dependency manager that
 reaches over the boundaries of wp.org) would take too long and would not
 be worth the effort. We already have too many APIs that need constant
 polishing and love.

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