[wp-trac] [WordPress Trac] #36335: Next generation: core autoloader proposal

WordPress Trac noreply at wordpress.org
Thu Aug 25 15:48:37 UTC 2016


#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 wonderboymusic):

 Replying to [comment:61 jorbin]:
 > Some initial thoughts on the proposal:
 >
 > 1) Removing the instantiation of things like `$GLOBALS['wp_press_this']
 = new WP_Press_This(); ` from the original file is a breaking change.
 >

 Press This was never loaded automatically, it was only loaded whenever we
 are specifically in a Press This enviro: `press-this.php` or one of the
 AJAX callbacks. I feel extremely comfortable making this change, and then
 waiting out the most bizarre of edge cases: someone who built something
 that loads `WP_Press_This` in isolation.



 > 2) I would like to see a travis's build matrix updated to include a 5.2
 environment with spl disabled. Should likely have been done with the
 original addition of the shim, but

 Great idea. Thank you.

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

 If we are just using Composer for dev, should we check in the `vendor`
 files and pretend that the composer file doesn't exist? As a first step, I
 think we should.

 > 4) I don't like the additon of the toplevel `vendor` folder.  this
 should go inside wp-includes.

 Why? To be forward-thinking, we should use the default name and it should
 encompass all classes in the codebase. Hence, be outside of the roots the
 autoloader searches.

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

 I feel like I checked that library last year, and we may be using code
 that is no longer maintained ("I might be wrong" - Thom Yorke). If so, we
 should rename those classes. Yes, it is entirely possible that some person
 on this globe is directly using one of those files, not likely though.

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

 It's already available on every page load, the code just chooses not to
 include it. There is a bunch of image-related functionality which can
 happen on the frontend which has to include admin files. The way our files
 are organized is wanting, and I think the only reason some files from
 admin were desirable to be loaded on the frontend were to expose a class
 or some utility functions anyway.

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


More information about the wp-trac mailing list