[wp-trac] [WordPress Trac] #47100: Use WPINC constant in script-loader.php, load-scripts.php, and load-styles.php instead of hardcoded wp-includes directory name

WordPress Trac noreply at wordpress.org
Fri May 3 00:45:25 UTC 2019


#47100: Use WPINC constant in script-loader.php, load-scripts.php, and load-
styles.php instead of hardcoded wp-includes directory name
-----------------------------+----------------------
 Reporter:  mwarnermindedge  |       Owner:  (none)
     Type:  enhancement      |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  General          |     Version:  5.1.1
 Severity:  normal           |  Resolution:  invalid
 Keywords:                   |     Focuses:
-----------------------------+----------------------
Changes (by dd32):

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


Comment:

 Hi @mwarnermindedge and welcome to Trac,

 Unfortunately in this case, `WPINC` is not designed to be overridden or
 set in configurations, and definately should not be set for the purposes
 of 'having a custom includes directory', as that is fundamentally not
 supported by WordPress - #24368 is a previous ticket that covers that
 functionality and feature request.

 See also #23249, #28264, and for the original purposes of the `WPINC`
 constant see the discussion in #14157

 [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/load-
 styles.php load-styles.php] and friends are also a "lightweight" entry
 point, which doesn't load the majority of WordPress or configuration
 files, and as a result even if it were possible to use `WPINC` to provide
 a custom `wp-includes` folder, it wouldn't be respected by these as it's
 not possible to load `wp-config.php` without also bootstrapping core
 WordPress.

 Although you can set `WPINC` in your `wp-config.php` file, do note that
 you'll a) Cause PHP notices about attempting to redefine constants and b)
 be unable to use WordPress inbuilt upgrade routines and benefit from the
 automatically installed Security Releases. and c) as you've found out,
 find that some places in WordPress still hard-code `wp-includes`.

 Unfortunately I'm going to close this as `invalid` as it's not something
 that WordPress currently supports or to my knowledge plans to support.

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


More information about the wp-trac mailing list