View Details links for plugins on individual sites on a Multisite Network use the network admin URL

[Ipstenu]

To duplicate, make sure you allow the plugins.php page to show on subites. Have (at least) one plugin that is not network activate and go to an individual site's plugin.php page.

The URL for "View details" will be for the network admin, not the site. With WP installed at example.com:

example.com/subsite/wp-admin/plugins.php links to example.com/wp-admin...
subsite.example.com/wp-admin/plugins.php links to example.com/wp-admin...
mappeddomain.com/wp-admin/plugins.php links to example.com/wp-admin...

This is problematic when you have admin over HTTPS and the cross-site-scripting sanity check stops the view-details page from loading.

/wp-admin/includes/class-wp-plugins-list-table.php line 628 has network_admin_url() in there, which is why it's defaulting to the network domain.

https://core.trac.wordpress.org/ticket/17902#comment:31 and https://core.trac.wordpress.org/changeset/29595 appear to be where this issue stems from.

To quote @jjj "It probably just needs a series of is_multisite() and is_plugin_active_for_network() checks."

The URL should probably just default to whatever the URL of the current site is, to prevent cross-site shenanigans.

[jeremyfelt]

Good catch. The cross domain issue triggers this in Chrome (maybe others) even without HTTPS configured.

Thinking out loud... The issue lies in wp-admin/plugin-install.php which has a primary purpose to display the full Add Plugins screen and a secondary purpose to provide plugin details for an iframe request when requested either in Add Plugins or in the standard plugin list table.

The redirect to network_admin_url() makes sense if the page is directly accessed at wp-admin/plugin-install.php, because plugins in multisite should be installed at the network level. It does not make sense when plugin information is requested.

The attached 32602.diff is a first attempt. It makes sure the admin URL is used at all times, which, now that I type this out, is wrong for the network admin—should be self_admin_url(). :) It also avoids the redirect to the network admin if an iframe is being requested. This *could* be a fix for now, but I'm sure there are other parts of the workflow that will need to be tweaked.

There's a nice todo - // TODO route this pages via a specific iframe handler instead of the do_action below - in wp-admin/plugin-install.php that makes sense. We should have something else handling this iframe so that the plugin install screen can live on its own.

I'm not sure if it was [29595] or [16747] or a combination that introduced this.