Add a "Plugin Details" link to installed plugins.

Description

The link would make a pop-up appear with the plugin details as if you are viewing the plugin details when you search for plugins.

CUrrently, plugins that have available updates have a link to view details...

It'd be SUPER convenient to have a link to view details at all times. Sometimes you have to recall these details when you haven't been to your blog in a while, and its a hassle just to search for it in the "Add New Plugin" page or on wordpress.org (a waste of time compared to having a "plugin details" link)

This patch assumes that $plugin_data['Title'] used with sanitize_title() gives the good plugin slug.

This patch does not work. This is a bad assumption. Jetpack, for example, has a slug of "jetpack" but a name of "Jetpack by WordPress.com." For future reference, I'd recommend code like this:

$slug = basename( $plugin_file, '.php' );

I was attempting to fix this patch, though, when I came across a deeper problem with referencing the central wordpress.org repository for all plugins: Not all plugins are listed in the central wordpress.org repository. That's actually a difficult problem to deal with.

Option 1 - Always show the details link no matter what.

Scenario 1 - Plugin is in the repository, good.

Scenario 2 - Plugin is not in the repository, the API returns an error or empty response, bad.

Option 2 - Check the repository for the slug first, then decide whether or not to show the details link

This could be a pretty tough sell. A site with 30+ plugins would result in 30+ requests and would result in a slow loading plugins page. You could implement caching, but this means the plugin page would still load slowly the first time.

You could ask the core team to rewrite the API on wordpress.org to accept multiple plugin slugs in a single request (maintaining backwards compatibility). I'm not sure how much change this would require in the core to enable your patch. I also have no idea how much work it is to add this feature to api.wordpress.org.

Either way, there's still a problem:

Scenario 1 - Plugin has a unique slug, good.

Scenario 2 - Plugin slug is not unique, bad. For example, two different developers could both release plugins with a slug of "super-duper-seo-mega-plugin." One is listed in the repository, one is released privately (perhaps a premium plugin), but they have the same slug. There are no controls in place to prevent this (that I know of). A user could install the premium plugin, then click details, and get information on the repository plugin of the same slug name.

The patch on this is broken into two parts. markdown.php​ is the latest version of Markdown Extra. This should be placed in wp-admin/includes. 17902.patch​ are the WordPress modifications.

Let me explain real quick why this patch is big:

class-wp-plugin-readme-parser.php:
This parses a plugin's readme.txt file into a data structure (associative array).

The readme.txt format is not stock markdown. There is a WordPress spin to it, to enhance any backtick code sections. I opted not to use the ​existing parser because it had a few references to bbPress and was calling deprecated functions (e.g. clean_url).

wp-admin/includes/plugin-install.php:
This gets the plugin info based on a slug and renders the page. The changes here should look really similar to install_plugin_information().

The local_plugin_api() function will combine the plugin header with the readme.txt file to generate an object similar to the remote API. The readme.txt file is missing some information that is contained in the plugin header (like the author's name and plugin home page). Also, if the readme.txt file is not available (in the case of Hello Dolly) then the only information available will be in the plugin header.

class-wp-plugins-list-table.php:
Insert the "Details" link into the plugins table

plugin-install.php:
Ensure that the plugin-readme page is an iframe and not thickbox

colors-class.dev.css, colors-fresh.dev.css, wp-admin.dev.css, wp-admin-rtl.dev.css
The #plugin-information and #plugin-information-header containers were styled in a lot of places. The three options I saw were

Create a new tab and duplicate the existing CSS rules

Genericize the rules to classes and edit the existing markup (and risk a regression)

I don't see why extensive editing of the existing markup would be necessary. Just use the same markup everywhere, since it shouldn't matter if the info comes from the readme file or from wp.org.

The rules are tied to specific element IDs which are written out by the plugin_readme_information() and install_plugin_information() functions.

The plugin_readme_information() function writes out the markup the same way as install_plugin_information() does. The element IDs are based on a query string variable (&tab=...).

It would be possible to have the new function (plugin_readme_information()) to ignore the query string and force the same id as install_plugin_information(). Do you think this would be confusing for future developers?

It would be possible to have the new function (plugin_readme_information()) to ignore the query string and force the same id as install_plugin_information(). Do you think this would be confusing for future developers?

No, it's ok to have different IDs. I was referring to classes (which is what the common CSS should target).

scribu, I'd like to talk about this one a bit more interactively, but I haven't seen you on IRC.

The markup between the readme display and the api display varies quite a bit. The API has screenshots, download stats, rating stats, compatibility info, last updated, date added, download link, and author profile link. These won't be contained in the readme / plugin header information.

I'm not sure how to combine these together.

I can't really change the element id that necessitates the CSS changes. It cascades from the query string to wp-admin\plugin-install.php and is set as $body_id where it's used in iframe_header to set the body id, then $tab is used to control which hook gets called.

I'm not sure how to cleanly break all of these apart. It seems like it would cause a regression somewhere.

scribu, I'd like to talk about this one a bit more interactively, but I haven't seen you on IRC.

I'll try to be online more often, but it would probably be easier if we attempted to set a meeting point.

The markup between the readme display and the api display varies quite a bit. The API has screenshots, download stats, rating stats, compatibility info, last updated, date added, download link, and author profile link. These won't be contained in the readme / plugin header information.

No, but the general layout should be the same, so the CSS shouldn't differ much.

I can't really change the element id that necessitates the CSS changes. It cascades from the query string to wp-admin\plugin-install.php and is set as $body_id where it's used in iframe_header to set the body id, then $tab is used to control which hook gets called.

Like I said previously, forget about the id. We should change the CSS and markup so that we end up with re-usable classes.

Summary
changed from You guys should add a "Plugin Details" pop-up link to installed plugins. to Add a "Plugin Details" link to installed plugins.

Version
changed from 3.1.3 to 2.7

I think it's about time we started exposing the data in plugin readme files in the admin area.

Rather than the small popup that's used when installing plugins, we could have a separate admin screen for each plugin, with tabs for each section in the readme. The main benefit I see is being able to view a plugin's FAQ from within the admin area rather than having to find your way to the plugin's FAQ in the plugin directory.

I built a plugin a while ago which provides this functionality, but it needs an update. I'll get it updated and link to it here once I do.

Basically it requests info about all plugins when using the update-check API. This is not yet supported by the API, but if consensus is positive then I have an API-side patch to handle it. The extra info is returned as a separate list - one list of plugins needing an update, one for everything else.

This gives WP a canonical slug for all plugins that exist in the wp.org directory. Given that it's a simple matter of using the existing plugin details modal.

I don't think this necessarily replaces the other ideas mentioned in this thread - it might make sense to do it this way for plugins hosted in the directory, and use readme data for those sourced elsewhere. Either way I think it'd be helpful to request and store this data, as having the canonical slug for installed plugins (where applicable) will be useful for other things. This might help satisfy #20002.

The newer patch 17902-plugin-details-link-2.diff follows the same idea as the prior and cleans it up a bit.

It also updates WP_Plugin_Install_List_Table to pass the slugs of installed plugins (as collected from the updates API) to the plugins API when querying the API for featured plugins etc. The API will eventually use that data to provide context-sensitive recommendations.

Whether the "Details" link is good as an action link. I don't like it there, and think it should replace "View plugin site" instead, as it is informational rather than an action. But I wanted to leave it where it was for now so we can refine.

How this works with updates. Update notices have a details link as well. Does the double-link hold up well?

Details should be next to or instead of view plugin site. I think a lot of plugins (even Hello Dolly) use the repo listing for the plugin site, maybe replace it if it's a wp.org URL since the details modal duplicates that information?

Double-link on updates seems fine to me, since the "version x details" link takes you right to the changelog.

Re #29179: The code right now won't show any link (either View details or Visit plugin site) if it's multisite and the current page is not in the network admin. I don't imagine there's anything wrong with showing the details page to non-network admins (and indeed it could be helpful to people trying to figure out how a plugin works), except that in multisite the details page is also under the network admin, so non-network admins get an access denied page. The alternative is to just show the Visit plugin site to non-network admins. Thoughts?