WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 8 months ago

#17902 closed task (blessed) (fixed)

Add a "Plugin Details" link to installed plugins.

Reported by: trusktr Owned by: johnbillion
Milestone: 4.0 Priority: normal
Severity: normal Version: 2.7
Component: Plugins Keywords: needs-patch
Focuses: administration Cc:

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)

Attachments (8)

patch-plugin-details-link.diff (1.8 KB) - added by chsxf 4 years ago.
markdown.php (81.5 KB) - added by kurtpayne 3 years ago.
Markdown Extra v1.2.5 - put in wp-admin/includes
17902.patch (30.0 KB) - added by kurtpayne 3 years ago.
Display local information about plugins from readme.txt and plugin headers
17902.2.patch (16.5 KB) - added by kurtpayne 3 years ago.
Fixed patch, removed EOL property changes
17902.3.patch (30.6 KB) - added by kurtpayne 3 years ago.
Updated for 3.5
17902-plugin-details-link.diff (3.8 KB) - added by tellyworth 10 months ago.
17902-plugin-details-link-2.diff (5.7 KB) - added by tellyworth 10 months ago.
Refresh of prior patch
17902-plugin-details-link-3.diff (5.9 KB) - added by tellyworth 10 months ago.
Fix broken/missing Detail links in multisite

Download all attachments as: .zip

Change History (41)

comment:1 @scribu4 years ago

At the moment, there's no easy way to see the plugin's readme, so I agree that a details link would be useful.

comment:2 follow-up: @chsxf4 years ago

  • Cc christophe@… added
  • Keywords has-patch needs-testing added; needs-patch removed
  • Owner set to chsxf
  • Status changed from new to assigned

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

comment:3 in reply to: ↑ 2 ; follow-up: @kurtpayne3 years ago

  • Cc kpayne@… added
  • Severity changed from major to normal

Replying to chsxf:

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.

So I should probably propose a solution at this point:

Replying to scribu:

At the moment, there's no easy way to see the plugin's readme, so I agree that a details link would be useful.

scribu and chsxf, what are your thoughts on including PHP Markdown and rendering a plugin's readme.txt file, pulling screenshots from plugins.svn.wordpress.org?

comment:4 in reply to: ↑ 3 ; follow-up: @scribu3 years ago

Replying to kurtpayne:

scribu and chsxf, what are your thoughts on including PHP Markdown and rendering a plugin's readme.txt file, pulling screenshots from plugins.svn.wordpress.org?

Yeah, that seems like the most resilient way (sans the screenshots).

comment:5 in reply to: ↑ 4 @kurtpayne3 years ago

Replying to scribu:

Yeah, that seems like the most resilient way (sans the screenshots).

Should screenshots just be skipped?

Currently, they could be pulled from the plugin's folder, but there was talk about removing the screenshots from the plugin zip files.

comment:6 @scribu3 years ago

Yeah, we can worry about screenshots later.

@kurtpayne3 years ago

Markdown Extra v1.2.5 - put in wp-admin/includes

@kurtpayne3 years ago

Display local information about plugins from readme.txt and plugin headers

comment:7 @kurtpayne3 years ago

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

  1. Create a new tab and duplicate the existing CSS rules
  2. Genericize the rules to classes and edit the existing markup (and risk a regression)
  3. Hijack install_plugin_information() with if ($local) {...} else {...} logic.

The first option seemed the cleanest to me, but I welcome feedback.

Per discussion, no screenshots at this point. The entire section is removed.

comment:8 follow-up: @scribu3 years ago

Your patch has a property change on the class-wp-plugins-list-table.php file.

  1. 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.

comment:9 in reply to: ↑ 8 @kurtpayne3 years ago

Replying to scribu:

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?

Or did I completely misunderstand what you said?

comment:10 @scribu3 years ago

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).

Sort of related to the screenshot issue: #19816

comment:11 @scribu3 years ago

[wrong ticket]

Last edited 3 years ago by scribu (previous) (diff)

comment:12 follow-up: @kurtpayne3 years ago

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.

Thoughts?

comment:13 in reply to: ↑ 12 @scribu3 years ago

Replying to kurtpayne:

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.

comment:14 @scribu3 years ago

So, instead of #plugin-information pre, we would use .plugin-info pre etc.

@kurtpayne3 years ago

Fixed patch, removed EOL property changes

@kurtpayne3 years ago

Updated for 3.5

comment:15 @kurtpayne3 years ago

Updated patch for 3.5 17902.3.patch. This still requires a separate download of markdown.php to be placed in wp-admin/includes.

comment:16 @johnbillion13 months ago

  • Focuses administration added
  • Keywords needs-refresh added; has-patch needs-testing removed
  • Owner changed from chsxf to johnbillion
  • 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.

comment:17 @johnbillion13 months ago

  • Keywords needs-patch added; needs-refresh removed

comment:18 @ircbot10 months ago

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

comment:19 @ircbot10 months ago

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

comment:20 @tellyworth10 months ago

I attached a new patch that takes a totally different approach.

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.

comment:21 @ircbot10 months ago

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

@tellyworth10 months ago

Refresh of prior patch

comment:22 @tellyworth10 months ago

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.

I've also deployed the API side of this so anyone can test.

@tellyworth10 months ago

Fix broken/missing Detail links in multisite

comment:23 @nacin10 months ago

In 29227:

Plugin Install screens: Pass locale and installed plugins to the API, for context.

props tellyworth.
see #17902.

comment:24 @nacin10 months ago

In [29226]:

Add 'Details' links to installed plugins.

Installed plugins that are up to date are now returned in the update-check API response.

props tellyworth.
see #17902.

comment:25 @nacin10 months ago

  • Milestone changed from Awaiting Review to 4.0
  • Type changed from enhancement to task (blessed)

I see two UI-related things that need studying here:

  • 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?

comment:26 @SergeyBiryukov10 months ago

I agree that the "Details" link makes more sense as a "View plugin site" link replacement (or we could probably have both) rather than an action link.

comment:27 @celloexpressions10 months ago

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.

comment:28 @ircbot9 months ago

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

comment:29 @DrewAPicture9 months ago

I think @nacin may have been working on a patch for the remaining concerns in comment:25 that should finish this up.

comment:30 @shedonist9 months ago

#29179 was marked as a duplicate.

comment:31 @wpdavis9 months ago

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?

comment:32 @ircbot9 months ago

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

comment:33 @nacin8 months ago

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

In 29595:

Plugins: Only show details link if user can install plugins.

fixes #17902.

Note: See TracTickets for help on using tickets.