Make WordPress Core

Opened 13 years ago

Closed 10 years ago

Last modified 9 years ago

#17902 closed task (blessed) (fixed)

Add a "Plugin Details" link to installed plugins.

Reported by: trusktr's profile trusktr Owned by: johnbillion's profile 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 13 years ago.
markdown.php (81.5 KB) - added by kurtpayne 12 years ago.
Markdown Extra v1.2.5 - put in wp-admin/includes
17902.patch (30.0 KB) - added by kurtpayne 12 years ago.
Display local information about plugins from readme.txt and plugin headers
17902.2.patch (16.5 KB) - added by kurtpayne 12 years ago.
Fixed patch, removed EOL property changes
17902.3.patch (30.6 KB) - added by kurtpayne 12 years ago.
Updated for 3.5
17902-plugin-details-link.diff (3.8 KB) - added by tellyworth 10 years ago.
17902-plugin-details-link-2.diff (5.7 KB) - added by tellyworth 10 years ago.
Refresh of prior patch
17902-plugin-details-link-3.diff (5.9 KB) - added by tellyworth 10 years ago.
Fix broken/missing Detail links in multisite

Download all attachments as: .zip

Change History (42)

#1 @scribu
13 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.

#2 follow-up: @chsxf
13 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.

#3 in reply to: ↑ 2 ; follow-up: @kurtpayne
12 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?

#4 in reply to: ↑ 3 ; follow-up: @scribu
12 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).

#5 in reply to: ↑ 4 @kurtpayne
12 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.

#6 @scribu
12 years ago

Yeah, we can worry about screenshots later.

@kurtpayne
12 years ago

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

@kurtpayne
12 years ago

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

#7 @kurtpayne
12 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.

#8 follow-up: @scribu
12 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.

#9 in reply to: ↑ 8 @kurtpayne
12 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?

#10 @scribu
12 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

#11 @scribu
12 years ago

So, it seems the "don't JOIN global tables with non-global tables" rule can be broken in the following case:

if ( !wp_is_large_network( 'users' ) && !defined( 'CUSTOM_USER_TABLE' ) && !file_exists( WP_CONTENT_DIR . '/db.php' ) )
Version 0, edited 12 years ago by scribu (next)

#12 follow-up: @kurtpayne
12 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?

#13 in reply to: ↑ 12 @scribu
12 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.

#14 @scribu
12 years ago

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

@kurtpayne
12 years ago

Fixed patch, removed EOL property changes

@kurtpayne
12 years ago

Updated for 3.5

#15 @kurtpayne
12 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.

#16 @johnbillion
10 years 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.

#17 @johnbillion
10 years ago

  • Keywords needs-patch added; needs-refresh removed

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


10 years ago

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


10 years ago

#20 @tellyworth
10 years 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.

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


10 years ago

@tellyworth
10 years ago

Refresh of prior patch

#22 @tellyworth
10 years 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.

@tellyworth
10 years ago

Fix broken/missing Detail links in multisite

#23 @nacin
10 years ago

In 29227:

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

props tellyworth.
see #17902.

#24 @nacin
10 years 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.

#25 @nacin
10 years 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?

#26 @SergeyBiryukov
10 years 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.

#27 @celloexpressions
10 years 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.

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


10 years ago

#29 @DrewAPicture
10 years ago

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

#30 @shedonist
10 years ago

#29179 was marked as a duplicate.

#31 @wpdavis
10 years 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?

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


10 years ago

#33 @nacin
10 years 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.

This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.


9 years ago

Note: See TracTickets for help on using tickets.