[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]

#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:  Script Loader    |     Version:  5.1.1
 Severity:  normal           |  Resolution:  invalid
 Keywords:                   |     Focuses:
-----------------------------+----------------------

Comment (by Ryan_B):

 Replying to [comment:1 dd32]:
 > 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.

 According to #14157 the original purpose was to eventually allow it to be
 customized. So why not get us the rest of the way there. The three reasons
 you mentioned IMO are more reasons not to define WPINC in your wp-
 config.php now even though you "technically" could.

 The first reason of double defining the constant is a simple enough fix,
 have core make sure its not already defined before defining it to the
 default name.

 The second seems to be the biggest blocker, but the updater could be
 updated to rename wp-includes after download the new version to whatever
 WPINC is defined as.

 Third, anyone using one of the loaders would need to define WPINC in their
 script before calling the loader. Or better yet, allow wp-config to be
 completly stand alone and not fully load WordPress. That would be a simple
 as moving `require_once( ABSPATH . 'wp-settings.php' );` out of wp-
 config.php and into wp-load.php after the require_once statement for wp-
 config.php then the script loaders could bring in wp-config.php to get teh
 WPINC constant from there if its defined.

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