[wp-trac] [WordPress Trac] #25148: Call wp_plugin_directory_constants before loading drop in files

[WordPress Trac]

#25148: Call wp_plugin_directory_constants before loading drop in files
--------------------------------------------+------------------------------
 Reporter:  andreasnrb                      |       Owner:
     Type:  enhancement                     |      Status:  new
 Priority:  normal                          |   Milestone:  Awaiting Review
Component:  General                         |     Version:
 Severity:  normal                          |  Resolution:
 Keywords:  2nd-opinion dev-feedback close  |
--------------------------------------------+------------------------------

Comment (by nacin):

 Replying to [comment:3 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 [ticket:21055#comment:2 comment in #21055] may be a
 better long-game approach to what I think is the problem actually being
 reported here?

--
Ticket URL: <http://core.trac.wordpress.org/ticket/25148#comment:4>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software