[wp-trac] [WordPress Trac] #17902: You guys should add a "Plugin Details" pop-up link to installed plugins.

[WordPress Trac]

#17902: You guys should add a "Plugin Details" pop-up link to installed plugins.
-------------------------------------+------------------------------
 Reporter:  trusktr                  |       Owner:  chsxf
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Plugins                  |     Version:  3.1.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |
-------------------------------------+------------------------------
Changes (by kurtpayne):

 * cc: kpayne@… (added)
 * severity:  major => normal


Comment:

 Replying to [comment:2 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 [comment:1 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
 [http://michelf.com/projects/php-markdown/ PHP Markdown] and rendering a
 plugin's readme.txt file, pulling screenshots from
 plugins.svn.wordpress.org?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17902#comment:3>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software