[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         |  Resolution:
 Keywords:  close          |     Focuses:
---------------------------+------------------------------

Comment (by Denis-de-Bernardy):

 Which sounds fair enough, but I then beg to ask why WordPress should
 accommodate this any more than other pieces of Software? Did you open the
 same ticket with e.g. Drupal, Joomla, OSCommerce, phpBB, CMF, any one of
 the other gazillions of PHP software out there in the wild, or for that
 matter any of the plethora of PHP frameworks out there?

 Come to think of it, that probably is the main problem I see with this
 feature request. It's not a particularly bad idea per say. I think it even
 has some merit.

 But then: Why WordPress in particular? Especially when you consider the
 fact that you *can* do this already by overriding a define to achieve this
 using an `auto_prepend_file` directive?

 If defining the WPMU_PLUGIN_DIR folder is not good enough, you could
 achieve the same using:

 {{{
 <?php
 foreach (glob("/path/to/folder/*.php") as $file) {
   require $file;
 }
 unset($file);
 }}}

 As a bonus, the same scripts will work for all PHP applications.

 Which brings me to: Why would WordPress need to have a set of
 functionality that is any different from other PHP apps (or Ruby, Python,
 or [favorite language goes here] app, for that matter) in order to enforce
 auto-backups (which can and probably should be done by a cron that dumps
 mysql directly) or enforce a minimum Crawl-Delay in robots.txt (which can
 and probably should be done using e.g. an Apache module before traffic
 even hits the PHP scripts)?

 The idea of logging failed login attempts to feed a firewall admittedly
 rings truer since it's not taken care of in WP Core yet, but then you can
 monitor hits on the wp-login.php file (using an `auto_prepend_file`
 directive for instance) to do the same, and enforce any number of actions
 before the traffic ever hits the WordPress installation.

 On a related note, I can think of plenty of reasons for wanting
 `add_filter()` and `add_action()` for a few of these WP-specific sysadmin
 tasks. But I'm afraid this was rejected in #27208 when I suggested it a
 few weeks ago.

 In the end, I'm not saying the current situation is a panacea. Just that,
 you know… Why should WordPress be held to different standards from other
 applications, and expose a particular API for the convenience of hosting
 companies? Why should we not politely tell them that they've plenty of
 tried and tested solutions already which, as a bonus, also work with other
 applications?

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