[wp-trac] [WordPress Trac] #33413: most PHP classes should be in their own file

[WordPress Trac]

#33413: most PHP classes should be in their own file
----------------------------+-----------------------------
 Reporter:  wonderboymusic  |       Owner:  wonderboymusic
     Type:  enhancement     |      Status:  closed
 Priority:  normal          |   Milestone:  4.4
Component:  General         |     Version:  trunk
 Severity:  normal          |  Resolution:  fixed
 Keywords:  dev-feedback    |     Focuses:
----------------------------+-----------------------------

Comment (by nacin):

 A few months ago I told @wonderboymusic that I liked the direction here,
 but that I questioned the need to have such a complicated include path,
 and that I was probably going to go

 So rather than:
 {{{
 wp-settings.php
     -> post.php
         -> post-functions.php
         -> class-wp-post.php
 }}}

 I think we should have:
 {{{
 wp-settings.php
     -> post.php
     -> class-wp-post.php
 }}}

 Performance-wise: If we're going to have all of these files, we should at
 least try to go with as flat of an include graph as possible.

 Back compat-wise: Every file affected by this change is always included in
 wp-settings.php. Thus, the simplified include graph is only going to break
 a situation when someone is short-circuiting or forking wp-settings.php.
 We '''cannot''' support this. It puts our feet in too much cement to
 support this. We have never supported it before. We have split files many
 times before, including post-3.0 when multisite (and SHORTINIT) came in
 and made us a bit more cautious. And we have never done any BC work for
 files that are always included, beyond just putting it in wp-settings.php.
 If we support this now, then we must always support this, and WordPress
 will get even harder to maintain. Does this mean we also can't move
 functions between files? There are many things that we should be
 accounting for, but certain things we have to agree '''void the
 warranty''' and should not restrict us.

 This also avoids the problem noted with class-http.php, though I agree
 with the sentiment that it won't break much or at all.

 So, I'm going to commit a change that moves all `(.*)-functions.php` files
 back to `\1.php` and moves the includes up to wp-settings.php. It's not
 ideal in that wp-settings.php is now quite a bit more loaded up with
 includes. (I also load up the customize manager with includes -- it could
 break things, but it's a low risk.) I also move the constants back to
 rewrite.php. And, I always load the functions before the classes.

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