[wp-trac] [WordPress Trac] #32845: Introduce wp_include()
WordPress Trac
noreply at wordpress.org
Thu Jul 2 15:48:08 UTC 2015
#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
More information about the wp-trac
mailing list