[wp-trac] [WordPress Trac] #13550: WP_PLUGIN_DIR doesn't detect symlinks

[WordPress Trac]

#13550: WP_PLUGIN_DIR doesn't detect symlinks
---------------------------+------------------------------------------------
 Reporter:  acumensystems  |        Owner:  westi   
     Type:  enhancement    |       Status:  reopened
 Priority:  normal         |    Milestone:          
Component:  Plugins        |      Version:  3.0     
 Severity:  minor          |   Resolution:          
 Keywords:                 |  
---------------------------+------------------------------------------------
Changes (by shallot):

  * status:  closed => reopened
  * resolution:  wontfix =>


Comment:

 Replying to [comment:1 dd32]:
 > Using simlinks is not a good idea here, as you've found out.
 >
 > Instead, You should be adding a define to your wp-config.php to direct
 WordPress to the true folder:
 >
 > {{{
 > define('WP_PLUGIN_DIR', ABSPATH . '/wp-content/themes/my-
 theme/plugins');
 > define('WP_PLUGIN_URL', 'http://.....');
 > }}}

 I have a system-wide Wordpress installation, with some system-wide
 plugins, but I need to allow individual (virtual host) users to have some
 of their own plugins. At the same time they remain their own
 responsibility, so I don't want to just copy them over to the system-wide
 directory, I just symlink their particular plugins to their particular
 directories.

 This basically works. However, wp-includes/plugins.php's plugin_basename()
 has no facility to allow for it, it only removes the WP_PLUGIN_DIR or
 WPMU_PLUGIN_DIR from the paths, not the custom destination paths. In wp-
 admin/includes/plugin.php the _registered_pages global array gets filled
 with inconsistent values as get_plugin_page_hookname() first gets called
 with the readlink'd plugin file path and later with the original one
 relative to the systemwide directory, which in turn makes
 user_can_access_admin_page() drop all plugin settings page requests.

 If I were to reverse the directory layout and use a custom WP_PLUGIN_DIR
 for each virtual host, then I would again have to copy over all the common
 plugins into each of them - the same logic would prevent me from
 symlinking them.

 Wouldn't it be useful to simply add an optional array of custom plugin
 directories that plugin_basename() could add to its list for pruning?

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