[wp-trac] [WordPress Trac] #22802: Empower Plugin Developers to make Symlink Compatible Plugins

[WordPress Trac]

#22802: Empower Plugin Developers to make Symlink Compatible Plugins
------------------------------------------------+--------------------------
 Reporter:  MikeSchinkel                        |       Owner:
     Type:  enhancement                         |      Status:  reopened
 Priority:  normal                              |   Milestone:  Awaiting
Component:  Plugins                             |  Review
 Severity:  normal                              |     Version:  3.4.2
 Keywords:  has-patch dev-feedback 2nd-opinion  |  Resolution:
------------------------------------------------+--------------------------

Comment (by nacin):

 Not saying this isn't a problem, but the solution as proposed won't work
 for core. For compatibility reasons, plugins need to be included in global
 scope, not from within a function. That's why we have a function to return
 to wp-settings.php an array of PHP files to then include (in global
 scope), versus a function to just include the files.

 The use of a global is weird, because it means the plugin has to
 immediately act on its value. That doesn't make much sense, especially
 since an ideal plugin should have only add_action/add_filter calls in
 global scope, and potentially even just one (waiting until plugins_loaded
 or init to do everything).

 We probably have to do this the other way around:
 wp_get_active_and_valid_plugins() should store its results somewhere, so
 we can later look to it to see which plugins are registered and where they
 are. That won't help for deactivated plugins (i.e. the uninstall process,
 and on activation), but we can separately register those paths at the
 beginning of each of those processes. Then, we can use a plugin slug (say,
 `my-plugin` in lieu of `__FILE__`) in plugins_url() and check the
 registered paths before continuing.

 ----

 Now, cast all of that aside for a moment. Why do we actually need to do
 this? Rather than symlinking, just check the code out in multiple
 locations, or define a single WP_PLUGIN_DIR and WP_PLUGIN_URL, or just
 filter plugins_url(). Having a symlinked setup is environment-specific, so
 why should we go through so much trouble to try to fix this? You could
 easily filter plugins_url() and have it work for all plugins, even ones
 not adjusted for the environment...

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