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

 Replying to [comment:16 dave1010]:
 > I understand a Composer-esque vendor system isn't the WordPress way.
 Perhaps I shouldn't have introduced that in this ticket :-).

 Oh I hope you did not take any of my comments as personal criticism.   I
 too wanted exactly the same until recently after I implemented autoloading
 and tried to implement composer, and learned all that I did about it.

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

 Agreed, in concept. Figuring out exactly what those things are is/has been
 the difficult part.

 > It's up to plugin and theme authors to structure their code how they
 want (inside their own wp-content/plugins/foo directory).

 Yes.

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

 I think I wrote my comments poorly, because forcing developers was not
 something I was suggesting, and did not mean to imply.

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

 Yes your code can be structured to follow the letter of the PSR.  My
 assertion is that would mean you would need to split related code into two
 files each in order to load hooks but not load their related classes, and
 it would add required complexity to a plugin's directory ''if'' the
 developer chose to use the autoloader.

 And yes it is the developer's choice, but an autoloader is pretty simple
 to implement so if a developer want to use one in their plugin nothing is
 stopping them from doing so right now.

 The questions about including in core are: Would the required structure be
 something WordPress core would want to advocate for, and would the
 benefits of the autoloader be worth it in the 80 percentile case? My
 opinion is  ''"no"'' would be the answer to both of those questions.

 And personally I do not think there's a benefit to an autoloader in core
 ''at this stage of WordPress' evolution.'' Maybe later, but not now.

 > Composer has multiple autoloaded roots in `vendor`. WordPress would have
 them in `wp-content/plugins`. I don't see how that's particularly
 different.

 When I tried implementing Composer and getting the directories to work in
 a WordPress friendly way required significantly complexity, way more than
 it should require and really fighting the natural approach of Composer.
 Take a look at [http://stackoverflow.com/a/13547137/102699 my
 StackOverflow question and my own followup answer]. Note that I was
 discussing use with ''(my own concept of) "libraries"'' but the structure
 would be the same for plugins. IMO that's too much complexity to bake into
 WordPress core.

 > This is virtually identical to registering with a PSR-0/4 auto-loader.

 Virtually identical and identical are like horseshoes and hand-grenades
 when it comes to specifications.  If you are following a spec you either
 follow it exactly or don't say you are following it.  There's a huge
 benefit to adopting a standard, but not when you have to fit a square peg
 in a round hole.

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

 That's just how I presented it in the example. The idea could work with
 either relative or absolute URLs, developer preference.

 > Is there any reason plugins couldn't register and get access to
 autoloaded classes immediately if they wanted?

 Yes, but for what benefit?  If you are going to always load specific
 classes why not use a `require()` instead of an autoloader?  Yes
 development might be simpler but I think you should at least hard code
 those `require()`s for deployment.

 > Authors could always wrap the call to `register_autoload_path()` in an
 `add_action()` if they wanted.

 Not following why this would have value.

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

 Because as I said, it's mostly a moot point given the current best
 practices in the WordPress community.  If WordPress were not so dependent
 on hooks being loaded on every page load then it would be different. But
 then it would not be WordPress.

 That said, you'll have to convince the core team members to do it if you
 want; I'm just like you here, another guy offering his opinion.

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

 How do you get an autoloader to be able to not load more than 50% of the
 classes on each page load? That's the question.  If we can tackle that
 then it might be a lot more clear that adding the extra overhead (in load
 time, maintenance cost, support issues when people autoloaded classes and
 hooks didn't get fired, etc.) would be worth it.

 How would I approach it?  I'd specify some well-known constants and
 methods for a class like `self::POST_TYPE`, `self::ARGS()` and
 `self::HOOKS()` that allow a developer to register post types and add
 hooks ''"declaratively"'' instead of using procedural code, and then on
 plugin activation I would load all classes and cache the information to
 allow all registrations and fixups on normal page load to occur without
 having to load any of the classes in which the information was defined.

 But that approach is nothing like anything else being done in core so I
 doubt the core team would adopt that approach in the foreseeable future.

 > 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`?

 I'd really like to have a look at those plugins to see if in fact they are
 really benefitting from autoloading, or just instantiating most classes on
 every page load anyway. If I'm correct and it's the latter, maybe what we
 need to do ''instead'' is to preach the people should ''not'' use
 autoloaders with WordPress ''(unless of course they address the issues I'm
 bringing up in their own plugin.)''

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

 What I'm saying is that you get no benefit from an autoloader if you load
 the class files for each class on every page load ''anyway.'' You will end
 up loading any classes that contain hooks that must be added every page
 load.

 I mentioned the instantiation only because that's what triggers an
 autoloader to load class files.

 > I really don't think the ability to to improve things like post type
 registration would be harmed by making this first step.

 I don't follow how this relates.

 > As a plugin developer, having a standard autoloader would be a big
 victory.

 I'll say it again, it would be a
 [https://en.wikipedia.org/wiki/Pyrrhic_victory Pyrrhic victory] if the
 result is more complexity, increased page load times on average and
 increase support issues where plugins are published but they forget to
 test all logic paths and thus don't load classes that have needed hooks.

 BUT, who knows? Maybe I'm all wrong. Suggestion: If you believe this is
 important why not implement it as you think it should work and submit a
 patch. Then we can discuss specifics instead of just bikeshedding. And
 working code is a lot closer to being committed to core than ideas.

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