[wp-trac] [WordPress Trac] #39961: Make SHORTINIT accessible to plugins and themes.

[WordPress Trac]

#39961: Make SHORTINIT accessible to plugins and themes.
----------------------------+--------------------------
 Reporter:  majick          |       Owner:
     Type:  enhancement     |      Status:  closed
 Priority:  normal          |   Milestone:
Component:  Bootstrap/Load  |     Version:  trunk
 Severity:  normal          |  Resolution:  wontfix
 Keywords:                  |     Focuses:  performance
----------------------------+--------------------------
Changes (by dd32):

 * status:  new => closed
 * resolution:   => wontfix
 * milestone:  Awaiting Review =>


Comment:

 Replying to [ticket:39961 majick]:
 > 1. Is `wp-load.php` ''always'' found in the `ABSPATH` directory? It
 would seem so, but just to check for certain, are there any known edge
 cases where this is actually not so?
 Yes. `ABSPATH` is the path which contains `wp-load.php`.

 > 2. Does this create any possible security hole? It would seem not, as
 simply defining `ABSPATH` in a PHP file does not actually do anything and
 is no more accessible than any other file and so poses no real security
 risk.
 Yes, Maybe. It depends on what code is being executed, until WordPress is
 fully loaded anything is possible. No user authentication or capability
 checks can be used within a `SHORTINIT` scenario, and the majority of the
 codebase is not loaded.

 > 4. What is the best way of handling the other (non-direct) file write
 methods? A check for credentials and using the filesystem to write if they
 are already available seems to be all that is needed, beyond that seems
 unnecessary.
 I'd estimate ~80% of installs can probably write to the filesystem
 directly. The rest have no file writability.


 I don't think this is something we want to add to WordPress overall.

 Use of the `SHORTINIT` method is not something plugins or themes should
 utilise - it should be classified as deprecated functionality. I'd argue
 it shouldn't be used by **anything, ever.**

 The argument that WordPress is slow isn't enough to convince me here,
 WordPress's power is in it's extendability, the ability for other code to
 hook in and alter your code, the ability for you to alter other plugins
 code by using hooks, filters, etc, by doing this kind of thing you're
 explicitly opting out of that, and making it harder for other WordPress
 developers to use your code as part of theirs. Plus, WordPress isn't
 exactly as slow as people make it out to be - if you're having speed
 issues you should consider looking at other parts of your stack, and/or
 add appropriate caching.

 I'm going to be blunt and close this as `wontfix`. Another committer can
 re-open if they deem it interesting to explore, discussion can continue
 while the ticket is closed, please don't re-open this just to ask me to
 reconsider it.

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