Use WPINC constant in script-loader.php, load-scripts.php, and load-styles.php instead of hardcoded wp-includes directory name

[mwarnermindedge]

To allow users to have custom includes directory names, use the WPINC constant in script-loader.php, load-scripts.php, and load-styles.php instead of hardcoding the directory name as wp-includes.

In load-scripts.php and load-styles.php, check whether WPINC is defined before re-defining it. (at the top of the files)

That constant is used most everywhere else, so making these changes would make the code more consistent, as well. The WP_CONTENT_DIR is generally used throughout WP. This change will follow that example.

This is my first ticket, so let me know if I should upload my file changes for review anywhere.

[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

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.

[anonymized_6443559]

Replying to 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

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.

So I think what was started in #14157 should be finished. I would even be willing to provide some patches to accomplish the first and third change. I've never even looked at the updater code to feel comfortable enough to make the second patch that would be needed.

[SergeyBiryukov]

Replying to Ryan_B:

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.

Just wanted to note that this doesn't seem as straightforward in terms of backward compatibility. It would require every WordPress user to perform the change to wp-config.php, which does not seem feasible, since many of them may not know where it's located or how to edit it.

[anonymized_6443559]

Replying to SergeyBiryukov:

Replying to Ryan_B:

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.

Just wanted to note that this doesn't seem as straightforward in terms of backward compatibility. It would require every WordPress user to perform the change to wp-config.php, which does not seem feasible, since many of them may not know where it's located or how to edit it.

I am confused by what you mean by this. What is it that everyone would have to change? If you are referring to everyone having to include WPINC in wp-config.php no they wouldn't. Core could still have the default path defined if it is not already defined, just like it does for wp-content.