[wp-trac] [WordPress Trac] #28105: Feature (with patch): allow system-wide inclusion of code

[WordPress Trac]

#28105: Feature (with patch): allow system-wide inclusion of code
---------------------------+-----------------------------
 Reporter:  DavidAnderson  |      Owner:
     Type:  enhancement    |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Plugins        |    Version:  trunk
 Severity:  normal         |   Keywords:
  Focuses:                 |
---------------------------+-----------------------------
 A way for a server operator to be able to include code, in a plugin-like
 fashion, on every site on his server would be very useful.

 Example use cases:
 - Collating system-wide IP data from distributed attacks (and feeding that
 data to a firewall)
 - Detect and terminate brute-force attacks early (e.g. detect certain
 $_POST patterns, and end execution before further server resources are
 used)
 - Require a local plugin on every site, without needing to manage every
 site individually (e.g. hosting-company-provided automatic backups)
 - Have a default hook into wp_mail() that uses the local SMTP setup
 - Hook into a local cacheing system

 From that list of 5 examples, you can see that the potential is infinite.
 Currently, system administrators would have to install and activate a
 plugin on every WordPress site; or alternatively use PHP's
 auto_append_file configuration variable.

 The attached patch enables this functionality. It provides a defined file
 location that a system administrator can place his PHP code at, to hook
 into WordPress. It runs immediately before mu-plugins, and hence unlocks
 all the potential of an mu-plugin.

 Possible questions:

 Objection: It's creepy! We don't want system administrators to be able to
 include code on my site.
 Answer: They already can, via PHP's auto_append_file. Or, since they're
 the system administrator, they could just auto-modify your WordPress core.
 The options are infinite. If you have reasons to distrust your sysadmin,
 then this patch changes absolutely nothing for you.

 Objection: If the sysadmin introduces a PHP error in the included file,
 then he'll cause every site on the server to fall over!
 Answer: Of course. Same as if he mis-configures the webserver or pours
 juice over the hardware. Sysadmins have the power to break everything if
 they lack proper sysadmin skills. Again, if your sysadmin is this kind of
 person, then this patch makes no difference.

 Question: Why isn't the inclusion path over-ridable via a constant?
 Answer: Because it's not intended to be site-local configuration. It's
 intended to be a server-wide setting. If the sysadmin wants a particular
 site to be opted-out, then he should add code for that in the system-wide
 included file.

 Question: If server admins can already do this via installing plugins or
 auto_append, then why is that not sufficient?
 Answer: Installing an mu-plugin on each site, for example, has a lot of
 over-head: it needs to be done on every site, and there'd need to be a
 mechanism for detecting new sites when they appear. auto_append also
 severely limits what bits of WordPress can be hooked into, as it's running
 too late. auto_prepend could be used, together with pluggable functions,
 but it involves ugly hacks. The solution in the patch makes what is
 already possible to be both possible and elegant.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28105>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform