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

WordPress Trac noreply at wordpress.org
Sat Sep 24 04:35:03 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 MikeSchinkel):

 Taking a look at the files in WordPress core 4.6.1 I found many different
 ways to group them that will help us decide how to move forward with
 patches:

 '''Admin vs. includes'''
 1. Classes declared in files found within `/wp-admin`
 1. Classes declared in files found within `/wp-includes`

 Ideally for classes found in those directories we would like to keep them
 within those directories, but if we need to anticipate an autoloader that
 will some day not use a classmap it will be more performant to have one
 root directory for files.

 So this distinction of admin vs. includes will not really matter unless we
 assume we will always use a classmap. If we can always assume a classmap
 then we could leave the files within the same top level directories where
 they are currently found.  But since so many people here want to have the
 option of moving away from a classmap I will assume we will have one
 autoloader root combining files from both of these sources.

 BTW, if we ever do have an autoloader that does not use a classmap the
 `is_file()` calls used to validate if a file exits before an attempt to
 load it is made can add up and can be a significant performance hit. Or at
 least that was made clear to me when several of our projects were code-
 reviewed by 10up for an enterprise client. Their code sniffer, which I
 understand was the same code sniffer used for WordPress VIP flagged all
 calls to `is_file()` as errors and would not allow us to use them if not
 cached in persistent cache.

 The above is one reason I have been so adamant that our autoloader needs
 to be classmap based.  But the patches I am currently working on to make
 WordPress core classes autoloadable will not require a classmap so there
 is no reason to halt progress waiting on a decision about this.

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


More information about the wp-trac mailing list