[wp-trac] [WordPress Trac] #45178: 5.0 About Page

[WordPress Trac]

#45178: 5.0 About Page
----------------------------+--------------------------
 Reporter:  pixelverbieger  |       Owner:  lonelyvegan
     Type:  task (blessed)  |      Status:  reopened
 Priority:  normal          |   Milestone:  5.0
Component:  Help/About      |     Version:  5.0
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:
----------------------------+--------------------------

Comment (by Otto42):

 Replying to [comment:42 afercia]:
 > Thanks @melchoyce @lonelyvegan
 >
 > > I'm thinking of making a Classic Editor section that could elaborate,
 as well.
 >
 > I'd definitely second it. Not sure about the modal as first (and unique)
 source of information about Classic Editor. In all the other pages in
 core, the modal usually opens by clicking on a "more details" link. Before
 this link all the main information about a plugin is available, including
 the ability to install and activate. That's why I'd prefer to link to the
 plugins screen.
 >
 > Any smart way to get a link to the featured or search tab that shows
 only the Classic Editor plugin?

 After looking through all this, it would take a fair amount of work to do
 it this way.

 There's two ways to look at the plugin install screen there: The multiple
 view of search results of whatever type, and the modal popup iframe which
 shows detailed plugin information.

 The first shows multiple items, the second shows info about one item, and
 these are fully separate in all places in both the core code and the API
 on w.org which supports it. The "query_plugins" endpoint has no way to
 pull a specific single result, say by slug, and the view of multiple
 results has no other way to do the query than query_plugins.

 So, while it would be possible, you would need to change the API to
 support it and the core code to be able to search for a slug instead of
 keywords, tags, etc. Any other way, like using a special tag or hidden
 entry point or whatever would essentially be an identical amount of work,
 requiring both core and API changes. They're relatively easy changes, but
 they would need to be made nonetheless, so you might as well just add a
 query_plugins parameter to accept "slug" for specific items.

 My suggestion would be to just have the plugin-information modal popup.
 It's better results for one plugin anyway. It looks prettier. It doesn't
 have an unnecessary interim screen.

 But if you really want it, and if a workaround is acceptable, then I've
 made the Classic Editor a favorite plugin of the "wordpressdotorg"
 account. You can make a link like so to have a link to that in a WordPress
 install screen:

 {{{
 wp_nonce_url(admin_url('plugin-
 install.php?tab=favorites&user=wordpressdotorg'), 'save_wporg_username_' .
 get_current_user_id())
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45178#comment:67>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform