[wp-trac] [WordPress Trac] #32845: Introduce wp_include()

[WordPress Trac]

#32845: Introduce wp_include()
-----------------------------+-----------------------
 Reporter:  johnjamesjacoby  |       Owner:
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:
Component:  Plugins          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+-----------------------
Changes (by nacin):

 * keywords:  close =>


Comment:

 Hi @jjj,

 Thanks for the contribution to WordPres. This isn't something we're going
 to accept into core at this time.

 We've had a fairly miserable, decade-long experience with overloading
 code, in the form of both pluggable functions and drop-in files. Neither
 of them worked out favorably. We no longer add pluggable functions, and
 drop-ins are often more trouble than they are worth, especially when
 allowing for further development.

 The wp-db.php and cache.php files are, in particular, incredibly painful
 to make changes to. Our security-related work that tore up wp-db.php over
 the last year was significantly and negatively impacted by the existence
 of and specific implementation of drop-ins, for example. Improvements to
 caching in core have likewise been hampered.

 We have a significant amount of technical debt in WordPress specifically
 designed around crazy things that plugins do or have done, or core has
 enabled or done itself. This already hamstrings development to some
 extent. This would put massive additional unforeseen burdens on
 contributors, as pretty much everything could break with any change (more
 than it already could).

 Pluggable functions alone are a great case study for why this cannot work.
 They were bite-sized and it was still too much to support new development,
 functionality, and even minor bug or security fixes. It was clear in 2010,
 when we stopped adding pluggable functions, that the proper path forward
 was to ensure we were developing for modification in smart, targeted ways,
 through actions and filters. (For some time, as just one major example,
 the entire customizer could be disabled by removing a single action,
 though it has become much more integrated into WordPress in ensuing
 releases.)

 The core committers simply cannot take on the additional mental burdens
 that this will result. If for nothing else, this won't be accepted. Thanks
 again for the contribution.

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