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.

[Otto42]

Add favorites to plugin installer

[helenyhou]

Cool! Surprise: it works. :)

[ocean90]

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

[Otto42]

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.

[mordauk]

Very cool.

[griffinjt]

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

[scribu]

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

[sabreuse]

+eleventy

[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?

[griffinjt]

apologies - malformed diff file for first upload

[Otto42]

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.

[griffinjt]

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

[Japh]

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

[Otto42]

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.

[nacin]

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.

[DrewAPicture]

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.

[Otto42]

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

[DrewAPicture]

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.

[Otto42]

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

[DrewAPicture]

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).

[Otto42]

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.

[Japh]

Some fixed typos, and implemented usermeta feature

[Japh]

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

[Japh]

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

[Otto42]

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

[Otto42]

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

[DrewAPicture]

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

[DrewAPicture]

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

[Japh]

Switched input field type to 'search'

[Japh]

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

[nacin]

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

[Japh]

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

[Japh]

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

[nacin]

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

[DrewAPicture]

Some spaces.

[DrewAPicture]

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.

[nacin]

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

[westi]

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

[georgestephanis]

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.

[Otto42]

User name search is now case-insensitive.

[nacin]

In [22026]:

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