WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 22 months ago

#17902 assigned enhancement

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

Reported by: trusktr Owned by: chsxf
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.1.3
Component: Plugins Keywords: has-patch needs-testing
Focuses: 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 (5)

patch-plugin-details-link.diff (1.8 KB) - added by chsxf 3 years ago.
markdown.php (81.5 KB) - added by kurtpayne 2 years ago.
Markdown Extra v1.2.5 - put in wp-admin/includes
17902.patch (30.0 KB) - added by kurtpayne 2 years ago.
Display local information about plugins from readme.txt and plugin headers
17902.2.patch (16.5 KB) - added by kurtpayne 2 years ago.
Fixed patch, removed EOL property changes
17902.3.patch (30.6 KB) - added by kurtpayne 22 months ago.
Updated for 3.5

Download all attachments as: .zip

Change History (20)

comment:1 scribu3 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: chsxf3 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: kurtpayne2 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: scribu2 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 kurtpayne2 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 scribu2 years ago

Yeah, we can worry about screenshots later.

kurtpayne2 years ago

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

kurtpayne2 years ago

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

comment:7 kurtpayne2 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: scribu2 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 kurtpayne2 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 scribu2 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 scribu2 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 2 years ago by scribu (next)

comment:12 follow-up: kurtpayne2 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 scribu2 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 scribu2 years ago

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

kurtpayne2 years ago

Fixed patch, removed EOL property changes

kurtpayne22 months ago

Updated for 3.5

comment:15 kurtpayne22 months 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.

Note: See TracTickets for help on using tickets.