[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