Favorite plugins in the plugin installer

[Otto42]

Show a new Favorites tab in the plugin installer, to allow users to put in a WordPress.org username and see the Favorites of that user, and install them.

API change has been made. Patch to use API change is attached.

Add favorites to plugin installer

Cool! Surprise: it works. :)

Seems like it returns all plugins if a user exists but has no favorites.

Fixed. That's on the API side. BB_Query has this disconcerting habit of returning all possible results when there are no matches for the given data.

Very cool.

Updated the patch with typo fixes and a little more relevant documenting for the $page param.

+1. Without this, favorite plugins are little more than bookmarks.

+eleventy

I have included a suggested change in my ​Favorite Plugins plugin which utilises this new API, that is remembering the user. Though perhaps for core, we could do this with a transient?

apologies - malformed diff file for first upload

Japh: If I was going to do that, I'd probably want it to use a cookie or something instead, to keep it browser/user specific instead of storing it on the server-side. Could be weird if you have multiple admins browsing that page.

Ok, ignore my patches until I get my trunk install corrected. x.x

Otto42: Yes, I was thinking either cookie or session.

No sessions. Bad mojo with sessions. You'd be downright shocked at the number of hosting setups out there which will break painfully when you even try to use sessions.

Replying to Japh:

I have included a suggested change in my ​Favorite Plugins plugin which utilises this new API, that is remembering the user. Though perhaps for core, we could do this with a transient?

This is a worthy addition to this — but simply as a user option (global usermeta) rather than a site option.

Getting a fatal error Cannot redeclare install_plugins_favorites() clicking 'Add New' from a site's Plugins menu on Multisite:

Fatal error: Cannot redeclare install_plugins_favories() (previously declared in /Users/Drew/Sites/mutrunk/wp-admin/includes/plugin-install.php:183) in /Users/Drew/Sites/mutrunk/wp-admin/includes/plugin-install.php on line 212

EDIT: Applies to favorites-updates.2.diff

Oh, and by the way ... ooooh ahhhh, impressive.

DrewAPicture: Use my patch, not the two broken ones after that. See if that is the problem.

Make that fatal error on 'Add New' from any plugins screen in Multisite including Network Admin with favorites-updated.2.diff​

Replying to Otto42:

DrewAPicture: Use my patch, not the two broken ones after that. See if that is the problem.

favorites.diff​ works for me on Multisite. Spiffy.

Yes, both the "updated" patches from griffinjt are broken, as he pointed out earlier. The original patch is currently the correct one, for now.

Paired with this, it sure would be nice to be able to install multiple plugins at once though. There's a ticket for that somewhere around here (unless I'm missing something).

Interesting idea, but separate. Anyway, this new screen uses the same listing methodology as all the other pages do (same function calls) so a patch to do multiple installs should affect this in an identical fashion.

Some fixed typos, and implemented usermeta feature

I implemented at least a preliminary version of username remembrance with usermeta in 22002.diff​. Also fixed favories -> favorites typo.

Updated to user get_user_option and update_user_meta as per @nacin's advice

Update wording of user field, eliminate extra space and ugly header

Move form into the correct position to match the search form display, so it doesn't push down the results table needlessly

Adds help text for the Favorites link, fixes a couple of help-text typos

22002.5.diff​ Adds help text and fixes a couple of typos.

Switched input field type to 'search'

For the sake of consistency and friendliness to touch devices, 22002.6.diff​ changes the favourites input field type to 'search'.

enctype="multipart/form-data" appears to be copied-pasted from the upload form. This form isn't uploading data, so it can go.

Removed enctype attribute from the form, as per @nacin's recommendation

Patch 22002.7.diff​ removes the extra attribute @nacin pointed out.

22002.8.diff​ hides the list table before the initial search and moves to method="get" action="".

Some spaces.

After a bit of back and forth with @japh seems like searches are only case-insensitive if the username is all lowercase to start with.

For instance, 'markjaquith' works, but 'MarkJaquith' doesn't. 'matt' works but 'Matt' doesn't.

But DrewAPicture and drewapicture both work (username:DrewAPicture).

Consensus seems to be this should be looked at on the API side.

Yes, this is just an API thing. Otto42 and I should be able to straighten it out.

This is a great enhancement and great use of the WP.org favs

For

$user = isset( $_REQUEST['user'] ) ? stripslashes( $_REQUEST['user'] ) : get_user_option( 'wporg_favorites' );

should we be explicitly checking $_GET instead of $_REQUEST? The form's a get form anyways.

User name search is now case-insensitive.

In [22026]:

Browse and install your wordpress.org plugin favorites from the plugin installer. props Otto42, Japh, DrewAPicture. fixes #22002.