[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 MikeSchinkel):

 Replying to [comment:18 nacin]:
 > Not saying this isn't a problem, but the solution as proposed won't work
 for core....

 ok.

 > The use of a global is weird...

 Well, the the fact that PHP won't let us discover the symlinked value is
 weird wouldn't you say it might require a "weird" approach to fix?

 > We probably have to do this the other way around:
 wp_get_active_and_valid_plugins() should store its results somewhere...

 It'd be ''(partially)'' happy with a hook in
 `wp_get_active_and_valid_plugins()` to allow me to build an array of
 filenames keyed by the file's `realname()`.  Having that function attach
 the same information to `$current_screen` would be even better.

 > 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.

 Yes, I need to know plugin filenames during activation and deactivation
 too.  Maybe they could also be attached to `$current_screen`?

 > 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...

 In theory yes.  But in practice it's a nightmare to manage. That's what I
 was doing and it was so painful I finally had to move to symlinked
 plugins. I have written code to allow it but the code is outrageously
 ugly, I continue to find new use-cases where it breaks and so I'd really
 scared of discovering new ways it breaks. And all I need would be a simple
 way to get the plugin's expected filename vs. the `realname().`

 The problems are the duplicate symbols in the IDE cause all sorts of
 headache, and I accidentally end up updating the wrong code before the IDE
 takes me to the wrong version of the code. Doing what you propose has
 become such a nightmare I've had to move away from it, and yet all it
 would take would be a tiny bit of new code in core.

 Like I said on Twitter if this is only one (1) thing I ask for 3.6, please
 let it be a solution to allow developers to write symlinkable plugins.
 Please...

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