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

 I understand a Composer-esque vendor system isn't the WordPress way.
 Perhaps I shouldn't have introduced that in this ticket :-).

 Replying to MikeSchinkel:

 > PHP best practices for configuration management typically target those
 who are setting up development, testing, staging and production
 environments where PHP will be deployed and used and where code is
 deployed by either developers or system administrator. All of those
 features work very well for that use-case, but WordPress has a different
 primary use-case.

 Agreed. Though I think there's certain things that WordPress can do for
 developers who want to follow PHP best practices without hindering site
 builders who cannot write PHP code.

 Getting back to providing an autoloader to plugins and themes:

 > Across plugins and themes there is potentially a large number of classes
 to autoload, but those classes do not follow the PSR-0/4 autoloader
 standard because there is no single top-level directory to load from, nor
 are there really vendor names.

 It's up to plugin and theme authors to structure their code how they want
 (inside their own wp-content/plugins/foo directory). Some plugins don't
 use classes at all; some `require_once` one or 2 files in their root
 directory; others follow PHP best practices by using a PSR-0/PSR-4 class
 loader, with vendor names and namespaces. This file structure isn't
 defined or influenced by WordPress.

 > Another solution would be for WordPress to implement an autoloader and
 then every plugin and theme could opt-in to the autoloader, thus creating
 many top-level autoloader roots. But that seems silly because it might
 follow the letter of the PSR autoloaders but not the spirit, and we could
 end up with deeper subdirectory structures this way too.

 This is the solution I was proposing. WordPress can't force plugins to use
 an autoloader, the same way WordPress can't force plugins to use `$wpdb`.
 As a developer if all my code (WordPress and other PHP) can follow the
 letter of the PSR autoloaders then it makes life much easier.

 Composer has multiple autoloaded roots in `vendor`. WordPress would have
 them in `wp-content/plugins`. I don't see how that's particularly
 different. Is plugin authors using deeper subdirectory structures an
 issue?

 > What I would propose instead of a PSR-0/4 auto-loader is a WordPress
 autoloader that is much simpler, one that has only the following method:
 > `register_autoload_path( $path_from_wp_content, $class_prefix )`
 > It might look like this in use:
 > `register_autoload_path( 'plugins/my-plugin', 'My_Plugin_' )`

 This is virtually identical to registering with a PSR-0/4 auto-loader.
 Requiring the plugin to know it's path from wp-content seems like a small
 overhead over just using `dirname(__FILE__)` or `__DIR__` though. I'm all
 for WordPress providing a simpler API to an autoloader, but it would be
 great if the actual autoloader was exposed too.

 > Then any plugin can register it's class paths in a
 'register_autoload_paths' hook that I'd proposed to be called by WordPress
 just before 'init` and WordPress can collect all those files into an array
 and run a very simple autoloader when needed

 Is there any reason plugins couldn't register and get access to autoloaded
 classes immediately if they wanted? Authors could always wrap the call to
 `register_autoload_path()` in an `add_action()` if they wanted.

 > HOWEVER, the idea of an autoloader is mostly moot anyways, at least
 until we make some significant changes in WordPress and/or best practices
 for plugin and theme development all because of how WordPress plugins and
 themes bootstrap themselves.

 PSR autoloading is already best practices for PHP in general, which I
 don't see any harm in WordPress at least providing minimal support for. No
 BC breaks are required and it's purely opt-in.

 Plugins can already bootstrap themselves with their own PSR autoloader, or
 they could use one provided by WordPress. WordPress provides useful tools
 to plugins (like `$wpdb`) so they don't have to reinvent the wheel every
 time. An autoloader would be a good addition IMO.

 Grepping a recent site build, there are 9 plugins (out of 22) that have
 calls to `spl_autoload_register`! How many plugins would use their own DB
 abstraction layer if WordPress didn't provide `$wpdb`?

 > There are few non-trivial plugins or themes do not add actions or
 filters on the 'init' hook, and most developers I've seen using classes
 place these hooks in the a method of the class file. And placing hook
 initialization code outside of classes means separating the hook from the
 code it invokes making maintenance more difficult. And most of my systems
 I've worked on have over 50 classes and even with all those classes very
 few of them are without actions or filters that need to be hooked on page
 load. So if you autoload those classes you don't end up setting the
 actions and filters the code requires.

 I don't think I follow this. Autoloading is just a more consistent and
 maintainable way of requiring classes. Instantiating them shouldn't be
 affected.

 > So yes we can get an autoloader, even a PSR-0/4 autoloader, but it would
 be a Pyrrhic victory. At least until WordPress adds an alternate approach
 to registering post types, taxonomies, and hooks I can't see an autoloader
 providing any real, practical benefit for WordPress.

 As a plugin developer, having a standard autoloader would be a big
 victory. I really don't think the ability to to improve things like post
 type registration would be harmed by making this first step.

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