Make WordPress Core

Opened 11 years ago

Closed 13 months ago

Last modified 13 months ago

#27806 closed defect (bug) (invalid)

Link formatting for Plugins incorrect if defining WP_PLUGIN_URL

Reported by: mamborambo's profile mamborambo Owned by: rmccue's profile rmccue
Milestone: Priority: normal
Severity: normal Version: 2.7
Component: Plugins Keywords: needs-patch reporter-feedback close
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 (14)

#1 @rmccue
11 years ago

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

I'll look into this.

#2 follow-up: @jeremyfelt
11 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
11 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.


11 years ago

#5 in reply to: ↑ description @jeremyfelt
11 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
11 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
11 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
11 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 11 years ago by mamborambo (previous) (diff)

#9 @jeremyfelt
11 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
9 years ago

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

#11 @Presskopp
8 years ago

  • Keywords reporter-feedback added

#12 @rodrigosprimo
14 months ago

  • Keywords close added

As there has been no reply in 7 years, I am marking this as a candidate for closure.

If there is no response in the next 30 days, this ticket will be closed. It can be reopened at any time in the future if needed.

#13 @rodrigosprimo
13 months ago

  • Resolution set to invalid
  • Status changed from assigned to closed

Closing due to lack of feedback.

#14 @swissspidy
13 months ago

  • Milestone Future Release deleted
Note: See TracTickets for help on using tickets.