Allow symlinked plugins

[scribu]

There are many scenarios where one would like to have a plugin's folder symlinked to another location.

A couple of these scenarios are described in #13550.

However, when using symlinks, code such as this fails:

plugins_url( 'script.js', __FILE__ );

This happens because __FILE__ resolves to the real path, which confuses plugin_basename().

The most simple and most flexible solution is to add a filter to plugin_basename(), leaving individual devs to handle symlinked paths, depending on their environment.

'pre_plugin_basename' filter

Test files coming up.

To test:

1. Extract test.zip​ into a wp root directory
2. Activate Test Plugin

The archive already contains a symlink, so it probably won't work on Windows out of the box.

Not a 3.2 feature moving to Future Release.

Well what'ya know... there's already a 'plugins_url' filter which can be used just as well.

Found a case that's not covered by the 'plugins_url' filter: register_*_hook().

Yes, very annoying, it boils down to lack of feature in PHP, see ​PHP bug 46260 (I actually believe best way to fix PHP bug is to create new constant like __FILELINK__ to keep backwards compatibility). But getting that fixed anytime soon is not reality.

@scribu, can you elaborate what kind of problems you encountered using plugins_url filter hack for symlinkked plugins? The problem on those register_*_hook() seems to be in plugin_basename().

Alternative for plugins_url filter that converts plugin realpath to WP plugin path is naturally to make all symlinked plugins to create their URL differently, e.g. using plugin WPMU_PLUGIN_URL and WP_PLUGIN_URL.

Well, anything that uses plugin_basename(__FILE__) won't work properly and can't be fixed by hooking into 'plugins_url'.

Changing each plugin to pass to plugin_basename() what it would expect is not a good solution.

Hence the proposed filter, which would allow to handle this from a single point.

An alternative solution would be to allow plugins from multiple directories, like we do for themes.

Fix for correctly extracting the local directory and filename regardless if the file comes from a symlink or not

the above patch has been tested in our local and production environments. The patch is really simple as all that's needed is to use the basename() and dirname() functions to extract the local directory and filename from the passed in file.

dirname doc = ​http://www.php.net/manual/en/function.dirname.php

basename doc = ​http://www.php.net/manual/en/function.basename.php

or use pathinfo to get all the information = ​http://www.php.net/manual/en/function.pathinfo.php

The ticket will be closed automatically when a fix is commited.

What's up with WP_fix_for_plugin_basename_to_allow_symlinks_2011-07-28.2.patch​?

this patch is incorrect. it only works two levels deep. my issue is that that a lot of the jetpack modules are acting screwy when symlinked, and their JS and CSS files are 3/4 levels deep in the plugins folder.

To clarify, the WP_fix_for_plugin_basename_to_allow_symlinks_2011-07-28.2.patch is a patch to the WP_fix_for_plugin_basename_to_allow_symlinks_2011-07-28.patch so apply the WP_fix_for_plugin_basename_to_allow_symlinks_2011-07-28.patch first then the WP_fix_for_plugin_basename_to_allow_symlinks_2011-07-28.2.patch.

Replying to yincrash:

this patch is incorrect. it only works two levels deep. my issue is that that a lot of the jetpack modules are acting screwy when symlinked, and their JS and CSS files are 3/4 levels deep in the plugins folder.

This patch is not incorrect. You're welcome to contribute to it if you have found scenarios that have nested paths, but I'll bet those scenarios are easily solved by using relative paths to the directory determined by this plugin basename patch.

I keep getting bit by this and end up patching individual plugins (Raw HTML Pro, Advanced Custom Fields, More Fields, Post Page Association, etc.) They end up generating bad paths to CSS and JS — the <link> and <script> tags have the filesystem path embedded in them.

It would be nice if WordPress' plugins_url() did the right thing out of the box.

There are other complaints about symlinked plugins:

• http://core.trac.wordpress.org/ticket/13550
• http://core.trac.wordpress.org/ticket/16199

I urged you to seriously consider fixing this for 3.3.x or 3.4.

Had the same issue - symlinks are defintely important if one is managing a complex WP farm.

Applying the patches did solve the issue, so I propose that these are included upstream.

Alternative approach, which caches symlink targets and replaces them

Patching up plugin_basename() (or allowing for that patching) isn't the only issue here; symlinked files will show up in the plugins listing in wp-admin, but symlinked directories are not. I just attached a patch which also touches get_plugins() to support this.

My fix to plugin_basename() is also a little more robust, but perhaps more overhead than wanted. I hope this patch is helpful for others.

In the mean time, if this functionality should come as a plugin, scribu's pre_plugin_basename isn't the only hook needed; a filter in get_plugins() will also be necessary. If these filters are added, I'd be happy to release a "Symlink Plugins Support" plugin.

FTR, this feature is also needed for the setup picked by the official Debian package where we wanted to have packaged plugins in and manually installed plugins kept in two different directories (which is not really possible, so we put symlink to packaged plugins in the directory which is controlled by the local administrator). It would thus be nice to see this issue fixed.

See ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686228 for a report of this bug on the Debian side.

Weirdly enough, while augustash's patch works for me (debian wp 3.4.2 package), mitchoyoshitaka's (included in there) does not.

This is also an issue for WordPress sites deployed via Capistrano.

Capistrano keeps previous deployments of the site so you can easily roll back changes. So the actual filesystem path to the site might be:

/home/username/web/example.com/releases/20121018101521/public

But it's symlinked as:

/home/username/web/example.com/current/public

The latter is the path in my web server config. The current directory is a symlink to the latest deployment, which is actually the datestamped releases/20121018101521 directory.

As a result, the entire site is in a symlinked directory. This isn't an issue for most plugins but it's come up more than once in my experience running a handful of sites this way.

#22802 was marked as a duplicate.

Replying to scribu:

#22802 was marked as a duplicate.

#22802 is related, but it's not a duplicate.

Since #22802 was reopened anyway, let's keep this ticket focused on a solution that would enable symlinked plugins without plugin authors having to do anything special.

I resolved all my plugin problems caused by symlinks in the wp-content path by using the realpath() function in my wp-config.php. I simply replace this:

define('WP_CONTENT_DIR',$_SERVER['DOCUMENT_ROOT'] . '/wp-content');

With this:

define('WP_CONTENT_DIR', realpath($_SERVER['DOCUMENT_ROOT'] . '/wp-content'));

Thought that might help anyone ending up in this ticket when troubleshooting.

I've uploaded a path with another approach. The patch hooks 'pre_update_option_active_plugins' so anytime 'active_plugins' is saved it finds which active plugins have been symlinked and saves an array to a 'symlinked_plugins' key of wp_options. The array has an element for each of the symlinked plugins with the array key being realpath( $virtual_plugin_file ) and the value being virtual_plugin_file, i.e.

update_options( 'symlinked_plugins', array(
   '/Users/user/Plugins/my-plugin-1/my-plugin-1.php' =>  
   '/Users/user/Sites/test/wp-content/plugins/my-plugin-1/my-plugin-1.php',
 
   '/Users/user/Plugins/my-plugin-2/my-plugin-2.php' => 
   '/Users/user/Sites/test/wp-content/plugins/my-plugin-2/my-plugin-2.php',
));

Then plugins_url() simply checks to see if the value of the $plugin parameter -- which is typically passed in as __FILE__ -- is a key in the array returned by get_option( 'symlinked_plugins' ) and if yes it assigns $plugin with that array element's value.

I think that's all it takes. I've been circling this problem for a while so maybe this is all we need to enable plugins_url() to work correctly with symlinked plugins. But I might have missed a requirement and if so will need others to point out what I've missed.

Also please consider this a starting point for discussion; I don't expect that it's completely ready for production, but crossing fingers it might be.

Patch to enable plugin_url() to support symlinked plugins.

Re symlinked_plugins.diff​: the check you added to plugin_url() should be moved to plugin_basename(), since that's the more general function (and also the one that doesn't have a filter).

Replying to scribu:

Re symlinked_plugins.diff​: the check you added to plugin_url() should be moved to plugin_basename(), since that's the more general function (and also the one that doesn't have a filter).

Originally I didn't put in plugin_basename() because it looked like that would not have worked but I just tested and you are correct, it works. I also tested it with a symlinked plugin where the virtual directory was different than the real directory and it still worked correctly, i.e. my-plugin-dev/my-plugin.php vs. my-plugin/my-plugin.php:

Virtual Path => /Users/my-user/Site/my-site/wp-content/plugins/my-plugin-dev/my-plugin.php 
Real Path    => /Users/my-user/Plugins/my-plugin/my-plugin.php 

Attached is a new patch with the check moved to plugins_url().

2nd attempt at patch to enable plugin_url() to support symlinked plugins.

This has been working pretty well over the past few months.

Is there any chance of this making it into 3.6 so that I can update WordPress without fear of loosing all these code changes?

It has made a HUGE difference for me on the organization of my server files and makes maintaining dozens of sites on a single server so much easier. I no longer have to worry about any clients getting lazy and not updating their plugins and potentially leading to a security breach.

Has anyone at all come up with a problem that would cause this not to work properly in time for 3.6?

*If for some reason it can't be done in time, is it possible to turn this into an 'mu' plugin in the meantime?

Looks like MikeSchinkels code works for me.

Agree with everyone else here, please add this to the core. Putting it into 3.6 would be great so we don't have to wait 6 months.

pre-plugin-basename.diff

If adding my patch to the core is too much for 3.6, can you please consider adding a 'pre_plugin_basename' hook that would allow us to create an mu-plugin to do the rest? I've attached a patch for that, above.

Replying to MikeSchinkel:

If adding my patch to the core is too much for 3.6, can you please consider adding a 'pre_plugin_basename' hook that would allow us to create an mu-plugin to do the rest? I've attached a patch for that, above.

+1 if we can't have a core patch, this would work just fine for now!

16953.diff​ could go in before the beta, but we don't typically add new hooks after feature freeze.

Replying to SergeyBiryukov:

16953.diff​ could go in before the beta, but we don't typically add new hooks after feature freeze.

Given how this ticket has been languishing for 2 years with lots of interest and having come full circle, it sure would be nice. :)

I can confirm that the below solution worked for me in using:

define('WP_PLUGIN_DIR', realpath('/home/152858/domains/example.com/html/all/wp-content/plugins') );
define('WP_PLUGIN_URL', 'http://example.com/all/wp-content/plugins');
define('WP_THEMES_DIR', realpath('/home/152858/domains/example.com/html/all/wp-content/themes') );
define('WP_THEMES_URL', 'http://example.com/all/wp-content/themes');
define('WP_CONTENT_DIR', realpath('/home/152858/domains/example.com/html/all/wp-content') );
define('WP_CONTENT_URL', 'http://example.com/all/wp-content');

Replying to markus.magnuson:

I resolved all my plugin problems caused by symlinks in the wp-content path by using the realpath() function in my wp-config.php. I simply replace this:

define('WP_CONTENT_DIR',$_SERVER['DOCUMENT_ROOT'] . '/wp-content');

With this:

define('WP_CONTENT_DIR', realpath($_SERVER['DOCUMENT_ROOT'] . '/wp-content'));

Thought that might help anyone ending up in this ticket when troubleshooting.

Worked for me as well.

Replying to aubreypwd:

I can confirm that the below solution worked for me in using:

define('WP_PLUGIN_DIR', realpath('/home/152858/domains/example.com/html/all/wp-content/plugins') );
define('WP_PLUGIN_URL', 'http://example.com/all/wp-content/plugins');
define('WP_THEMES_DIR', realpath('/home/152858/domains/example.com/html/all/wp-content/themes') );
define('WP_THEMES_URL', 'http://example.com/all/wp-content/themes');
define('WP_CONTENT_DIR', realpath('/home/152858/domains/example.com/html/all/wp-content') );
define('WP_CONTENT_URL', 'http://example.com/all/wp-content');

Replying to markus.magnuson:

I resolved all my plugin problems caused by symlinks in the wp-content path by using the realpath() function in my wp-config.php. I simply replace this:

define('WP_CONTENT_DIR',$_SERVER['DOCUMENT_ROOT'] . '/wp-content');

With this:

define('WP_CONTENT_DIR', realpath($_SERVER['DOCUMENT_ROOT'] . '/wp-content'));

Thought that might help anyone ending up in this ticket when troubleshooting.

I didn't see until now there was a consensus on a simple filter. My question: What's more useful? pre_plugin_basename, or one just before the return? I'd think the final filter would be more useful, since it smooths out the processing?

Replying to nacin:

My question: What's more useful? pre_plugin_basename, or one just before the return? I'd think the final filter would be more useful, since it smooths out the processing?

Yes, given that you are passing in both a post-processed value and a pre-processed value a 'plugin_basename' would definitely be more generally useful and also still meet the need stated on comment 52 of this thread.

Replying to MikeSchinkel:

Replying to nacin:

My question: What's more useful? pre_plugin_basename, or one just before the return? I'd think the final filter would be more useful, since it smooths out the processing?

Yes, given that you are passing in both a post-processed value and a pre-processed value a 'plugin_basename' would definitely be more generally useful and also still meet the need stated on comment 52 of this thread.

UPDATE: Except, the hook would have to duplicate the logic in lines 567-574 in 16953.2.diff​ when changing the path, so when the goal is to meet the need stated on comment 52 a 'pre_plugin_basename' would be a better choice because it would limit the potential for error on the part of the plugin author.