Call wp_plugin_directory_constants before loading drop in files

[andreasnrb]

Currently there are two functions for setting constants.

• wp_initial_constants();
• wp_plugin_directory_constants()

Issue is that the plugin_directory_constants are not available in the dropin files because they are included before the call to wp_plugin_directory_constants() so cannot include extra files inside the plugin directory if custom plugin path is used.

[andreasnrb]

Quick example of refactored functions

[andreasnrb]

Possible solution.

• Split wp_plugin_directory_constants into a DIR function and an URL constant setting function. Then move the DIR function so its called before advanced-cache.php

[nacin]

In single-site, I'm not sure I see the harm here. But the reason these constants wait until just before mu-plugins get loaded is because these constants can be set in sunrise.php (in multisite). Changing this could break quite a bit. And, I'm not sure I see the need...

It seems like all of the main drop-ins would be affected — db.php, advanced-cache.php, and object-cache.php. But for use in inclusion, I don't think one should use WP_PLUGIN_DIR. Instead, __DIR__ (5.3+) or dirname( __FILE__ ) (5.2) should be used. Knowing WP_PLUGIN_DIR isn't necessarily enough to identify your plugin's full path. You should instead always base things off the main file.

Beyond that, ideally any kind of processing can wait for muplugins_loaded or plugins_loaded, at which point the URL constants and such are defined.

[andreasnrb]

The current behavior is illogical. Having constant set in a logical sequence is much better than this weird way.
And using FILE is really bad practice for file inclusion at least in my opinion. It really messes things up with regards to symlinks.

But suppose WP suffers from its past preventing a brighter future.

[nacin]

Replying to andreasnrb:

The current behavior is illogical. Having constant set in a logical sequence is much better than this weird way.
And using __FILE__ is really bad practice for file inclusion at least in my opinion. It really messes things up with regards to symlinks.

But suppose WP suffers from its past preventing a brighter future.

The fact that __FILE__ and __DIR__ resolve symlinks has nothing to do with file inclusion. (I'm well versed in #16953.) It is going to be far more stable than guessing based on WP_PLUGIN_DIR. Is the plugin in WP_PLUGIN_DIR? Or WPMU_PLUGIN_DIR? Did the directory the plugin resides in get renamed? (akismet/akismet.php is valid, but so is akismet-foo/akismet.php). What's better? WP_PLUGIN_DIR . '/my-plugin-name/inc/something.php or __DIR__ . '/inc/something.php?

On the other hand, if you are trying to load something inside a plugin from advanced-cache.php, then yeah, you're kind of out of luck here. This patch *will* break a situation where sunrise.php changes the location of the plugin or theme directories. Is this an edge case? Perhaps. Could the defines take place in a more logical order? Perhaps, certainly something we can look into. Is something actually broken here? Not necessarily. Can something break by changing the order of these definitions in relation to other initialization code? Without a doubt.

Specific to the patch — mu-plugins is a "must use" directory (no longer "MU" as in multi-user) and has been supported in core single-site since WP 2.8. So the split into ms-settings.php won't do.

Something like my comment in #21055 may be a better long-game approach to what I think is the problem actually being reported here?

[andreasnrb]

Well the simplest solution is to check if WP_PLUGIN_DIR is defined and use it if it is. But would be good to be able to assume its existence so behavior is consistent.

But the idea in the comment about defining paths for dropins is good as well. Less need to worry about these constants being set then also makes updating dropins on plugin updates much easier.

[wonderboymusic]

No movement in 2 years