WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 14 months ago

#27806 assigned defect (bug)

Link formatting for Plugins incorrect if defining WP_PLUGIN_URL

Reported by: mamborambo Owned by: rmccue
Milestone: Future Release Priority: normal
Severity: normal Version: 2.7
Component: Plugins Keywords: needs-patch reporter-feedback
Focuses: Cc:

Description

Because I am sharing a large repository of plugins between several WP installations, I defined WP_PLUGIN_URL and WPMU_PLUGIN_URL to point to a different host, say http://wpplugs.mydomain

When a plugin author uses plugins_url() to get a link to a deeper component, say a css style, plugins_url() resolves the link by expanding the basename of that plugin/component, and attach it between WP_PLUGIN_URL and path.

This algorithm is correct if plugin files live below Wordpress installation, *BUT IS INCORRECT* if plugin files live on different file system --- as intended by the explicit use of WP_PLUGIN_URL.

Change History (11)

#1 @rmccue
4 years ago

  • Owner set to rmccue
  • Status changed from new to assigned

I'll look into this.

#2 follow-up: @jeremyfelt
4 years ago

  • Version changed from trunk to 2.7

Thanks for the ticket, @mamborambo.

I'm moving the version to 2.7. The additional parameter to find the relative path for a specific plugin was introduced in [10578] via #6341

#3 in reply to: ↑ 2 @rmccue
4 years ago

Replying to jeremyfelt:

I'm moving the version to 2.7. The additional parameter to find the relative path for a specific plugin was introduced in [10578] via #6341

I suspect this was broken as part of #16953, but not sure.

This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.


4 years ago

#5 in reply to: ↑ description @jeremyfelt
4 years ago

Replying to mamborambo:

This algorithm is correct if plugin files live below Wordpress installation, *BUT IS INCORRECT* if plugin files live on different file system --- as intended by the explicit use of WP_PLUGIN_URL.

@mamborambo - can you provide details on your file structure here? Also, do you have WP_PLUGIN_DIR defined as well?

#6 @jeremyfelt
4 years ago

As an initial example, I set the following:

define( 'WPMU_PLUGIN_URL', 'http://foo.bar/wp-content/mu-plugins' );
define( 'WPMU_PLUGIN_DIR', '/tmp/mapped/drive' );

In /tmp/mapped/drive/index.php, I have:

add_action( 'init', 'myplugins' );
function myplugins() {
        echo plugins_url( '/mu-images/image.png', __FILE__ );
        die();
}

This returns http://foo.bar/wp-content/mu-plugins/mu-images/image.png as expected.

#7 @jeremyfelt
4 years ago

If I symlink /tmp/mapped/drive/index.php to /var/www/myplugin.php, I get http://foo.bar/wp-content/plugins/var/www/mu-images/image.png, which is likely not expected.

#8 @mamborambo
4 years ago

Yes @jeremyfelt the symlink problem is essentially the same as this issue. By design any wordpress installation cannot really be stored separately from its plugins, so it is all symlinked under the surface.

What I have done is to use NGINX to deliver the part of the file system containing plugins, since they are called from browser to fetch extra js and css for each plugin.

That is why I define WP_PLUGIN_URL and WP_PLUGIN_DIR constants. The rest of WP run through APACHE.

My solution so far is to modify insert line 2165 of link-template.php

  $folder = str_replace(realpath(WP_PLUGIN_DIR), '' , '/'.$folder);

This takes the decoded directory path of the plugin, remove the part defined in WP_PLUGIN_DIR, and use that to form the URL of the plugin component.

(The most correct solution is to use WPMU_PLUGIN_DIR if the function plugins_url is called from a WPMU plugin, and WP_PLUGIN_DIR if called from WP plugin).

Last edited 4 years ago by mamborambo (previous) (diff)

#9 @jeremyfelt
4 years ago

Thanks for the detail, that definitely helps. I'm assuming from the line number being modified that you are using 3.8.x.

Are you able to test in current trunk to see if any behavior changes? It sounds like this is not a regression, but pieces may be getting better due to the work done in #16953. @rmccue will have a much better idea of that.

#10 @wonderboymusic
3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release

#11 @Presskopp
14 months ago

  • Keywords reporter-feedback added
Note: See TracTickets for help on using tickets.