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

 Replying to [comment:61 jorbin]:
 > 1) Removing the instantiation of things like `$GLOBALS['wp_press_this']
 = new WP_Press_This(); ` from the original file is a breaking change.
 That instantiation was executed at the point where the `require` was made.
 To avoid a breaking change, we just need to add the instantiation so she
 covers all of the scenarios that would have triggered the `require`.

 > 3) I apply the patch, and now development doesn't work right away. All I
 get is `Autoloader was not found, aborting.`  That can't be committed.
 Trunk should include a `composer install` within its build process. There
 should be 1 single action that would trigger all of the required build
 steps. This should be either `npm install` ->triggering `composer install`
 or `composer install` ->triggering `npm install`. As this is mainly a PHP
 project, the latter would be preferable, but both would work just fine.
 For the normal WordPress distribution, autoloaders will of course be
 readily included.

 > 4) I don't like the additon of the toplevel `vendor` folder.  this
 should go inside wp-includes.
 This can easily be changed. However, do note that there should be no
 hardcoded reference to the `vendor` folder either way, it is not supposed
 to be a location you can depend on.

 > 5) running `composer install` generates warnings.
 > {{{
 > Warning: Ambiguous class resolution, "ftp" was found in both
 "/srv/www/blonderepublicansexkitten.com/public_html/src/wp-admin/includes
 /class-ftp-sockets.php" and
 "/srv/www/blonderepublicansexkitten.com/public_html/src/wp-admin/includes
 /class-ftp-pure.php", the first will be used.
 > Warning: Ambiguous class resolution, "ftp" was found in both
 "/srv/www/blonderepublicansexkitten.com/public_html/src/wp-admin/includes
 /class-ftp-sockets.php" and
 "/srv/www/blonderepublicansexkitten.com/public_html/src/wp-admin/includes
 /class-ftp-pure.php", the first will be used.
 > > xrstf\Composer52\Generator::onPostInstallCmd
 > Warning: Ambiguous class resolution, "ftp" was found in both
 "/srv/www/blonderepublicansexkitten.com/public_html/src/wp-admin/includes
 /class-ftp-sockets.php" and
 "/srv/www/blonderepublicansexkitten.com/public_html/src/wp-admin/includes
 /class-ftp-pure.php", the first will be used.
 > > xrstf\Composer52\Generator::onPostInstallCmd
 > }}}
 This is one example of bad class design in a third-party library. A quick
 search seems to indicate that the fix for this would completely contained
 within that third-party library, by renaming the two classes, and changing
 line 906 in `wp-admin/includes/class.ftp.php`.

 > 6) I'm not sure yet how I feel about automatically making so much of wp-
 admin available on everypage load.  In the past, core has forced
 developers to make a cognitive decision to include those pieces on the
 front end if they want to use them. Is that a change that should be made?
 why?
 Well, developers still need to make a cognitive decision to use those on
 the front-end. They just don't need to hard-code any path to get to them.

 Also, it will take the burden off the developers who are less experienced
 at only including stuff that is used within the specific context. For most
 plugins that are built "sub-optimally", this will on average improve load
 times and memory consumption.

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