Allow plugin installations via web interface.

[DD32]

Follow-on from: ​http://trac.wordpress.org/ticket/5586#comment:30

As a natural extension from the plugin-upgrade code, I've written up a plugin-installer, It currently allows the installation of plugins from WordPress.org which are available via the RSS feeds.

It needs a fair bit of work i'll admit, This is simply a first scrape, I'd have loved to have posted this in time for 2.5, But I feel it might be cutting it too close. (Have to respect the feature freeze :))

I'll be following this up with a Diff of trunk shortly, the diff code will be newer than whats available as the plugin in the before linked ticket. (Fiddling with a few things i thought of as i integrate it in).

[DD32]

First (relitivly) quick scrape of integration.

[DD32]

Closed #6359 as a dupe of this.

It'd be cool if next to the "Download" links on the dashboard were "Install" links that installed the plugin much like an update would do.

The attached diff didnt doesnt do that, But i had changed the download link to "View Page | Install"

Perhaps even an option at WordPress.org to specify the URL to your WordPress install which would enable an "Install" button that would take you to your blog, confirm (to avoid exploiting), and then install the plugin.

Thats a nice thought, that'd be a bit more of an integration between .com, .org, and self-hosted blogs though i'd think (as most people have a .com account which is registered to a self-hosted blog for use with akismet/wp stats)

I've been contemplating suggesting implementing this ticket as a gsoc proposal. but considering it was similar last year.. (Ok, i learnt a lot last year and since then).

[Viper007Bond]

Replying to DD32:

Thats a nice thought, that'd be a bit more of an integration between .com, .org, and self-hosted blogs though i'd think (as most people have a .com account which is registered to a self-hosted blog for use with akismet/wp stats)

True, but the integration wouldn't have to be as in-depth as one might think. Just a URL to the WordPress install and then .org tags like /wp-admin/plugin-install.php?plugin=the-slug-here and bam, done.

[DD32]

True, but the integration wouldn't have to be as in-depth as one might think. Just a URL to the WordPress install and then .org tags

I do agree with you, It would be simple, and could possibly be very beneficial to the general users. See what comes up i guess in the final interfaces :)

[matt]

Linking the SoC project:

​http://code.google.com/soc/2008/wordpress/appinfo.html?csaid=51D2766AD87F1901

[DD32]

blessed summerofcode.

Cheers :) I was just coming over to post that.

[DD32]

GSOC work as of 3rd August

[DD32]

attachment plugin-install.diff added.
GSOC work as of 3rd August

Aand of course the HTML preview doesnt show up :)

Note that there are ~5 new files with this patch, The diff can be downloaded directly from ​http://wordpress-soc-2008.googlecode.com/svn/trunk/dion/ as well.

An extra image is needed, /wp-admin/images/star.gif which is available from ​http://wordpress-soc-2008.googlecode.com/svn/trunk/dion/wpadmin-images-star.gif

There'll be more patches coming the next few weeks as the rest of the code recieves its tidying up.

Notes:

• All JS'ified functions work without javasscript(eg, changing tabs in plugin information dialogue)
• There are a few TODO's mentioned in comments in the code, Most will receive attention shortly, There are a few which i'm not sure how to handle yet.
• The installer code needs some error conditions to be checked, Its still nearly a exact replica of the upgrade code with a single block removed.
• If the Plugin information dialogue detects the plugin is installed, and needs an upgrade, it'll offer to upgrade (instead of Install), If it detects it installed and doesnt see an update available, it assumes its at the latest version allready. (This is a TODO, Detecting if the plugin is installed currently checks for a folder/file of the plugin slug in the plugins folder)
• A database Upgrade will be required after patching to add the install_plugins capability to the Admin role. (Db version 8530 was used from memory)
• The API is finally live on api.wordpress.org so this code is now being released - I plan on writing a crude API documentation at some stage, to replace that message ;)
  • Warning: The API may change if its determined something isnt working right, However it all seems to be running *very* nicely right now. (Directed at people who want to use it for something else)
  • The API currently only returns 6 plugins per page, I feel it'd be nicer for more to be returned. Note that the views also have the paging removed, This is something that needs to change on the API side - I'll look into it, I originally included a per_page arg in the API, but it has been pretty much removed upon the move to use more BBPress internal Functions rather than my own hacked up mess :)
• The code does not yet have the ability to accept an uploaded .zip file, However that functionality is planned.
  • The code needs to be changed to work with #7395, So i'll probably merge that in with this code too (To move the correct folder)
    • That should also stop zips like this one causing an issue: (ie. do not install if zip does not contain legit plugins) ​http://wordpress.org/extend/plugins/accelerate-your-advertising/
• Plugins which have "Plugin Name:" in the Title are *not* worked around by the code, If the readme.txt file has odd data, odd data is displayed in the browser(sanitized of course :))
• The API uses the new HTTP classes

I cant think of much more right now, Other than that testers are needed & that i'm happy for this to be commited and worked on from there

[westi]

I will get this in trunk later today for people to play with :-)

[westi]

(In [8540]) Plugin Install GSOC project first code drop. Props DD32 see #6015.

[westi]

Thats in. Small patches for any bugs please :-)

Think I may have broken the image.

[ryan]

(In [8541]) Set eol-style. see #6015

[ryan]

(In [8542]) Fix star.gif. see #6015

[santosj]

I'm so totally going to svn up tonight to test it.

[santosj]

The start install plugins page displays serialized array of popular tags:

Example:
1000 a:100:{s:4:"post";a:3:{s:4:"name";s:4:"Post";s:4:"slug";s:4:"post";s:5:"count";s:3:"360";}s:6:"widget";a:3:{s:4:"name";s:6:"widget";s:4:"slug";s:6:"widget";s:5:"count";s:3:"334";}s:5:"admin";a:3:{s:4:"name";s:5:"admin";s:4:"slug";s:5:"admin";s:5:"count";s:3:"260";}s:5:"posts";a:3:{s:4:"name";s:5:"posts";s:4:"slug";s:5:"posts";s:5:"count";s:3:"223";}s:8:"comments";a:3:{s:4:"name";s:8:"comments";s:4:"slug";s:8:"comments";s:5:"count";s:3:"211";}s:7:"sidebar";a:3:{s:4:"name";s:7:"sidebar";s:4:"slug";s:7:"sidebar";s:5:"count";s:3:"195";}s:6:"plugin";a:3:{s:4:"name";s:6:"plugin";s:4:"slug";s:6:"plugin";s:5:"count";s:3:"183";}s:6:"images";a:3:

[santosj]

Oops. I didn't think it would do that. Sorry.

[santosj]

Some other suggestions:

1. Featured Plugins only lists 3 plugins and only displays the same three. Expected to display full list of 6 that randomizes or multiple pages of all featured.
2. Popular Plugins only lists 6 plugins and displays the same 6. Expected to either display random plugins each page load or multiple pages of all popular.

[santosj]

WP Super Cache 0.6.6 featured plugin also displays serialized data.

[santosj]

Installation of a plugin worked perfectly.

[ryan]

After install, offer to activate the plugin or dismiss dialog.

[DD32]

The start install plugins page displays serialized array of popular tags:

Hm, the API currently wp_die()'s the content it recieves if it cannot unserialize() it.. It appears to be working as expected for me, It might fail to unserialize it if it contains some UTF-8 characters though or something that confuses unserialize() - i'll look into it.

Featured Plugins only lists 3 plugins and only displays the same three. Expected to display full list of 6 that randomizes or multiple pages of all featured.
Popular Plugins only lists 6 plugins and displays the same 6. Expected to either display random plugins each page load or multiple pages of all popular.

The API doesnt return the same data now that its on api.wordpress.org as it did on my test install :P I'll have to get someone to look into the bbPress views on the wordpress.org/extend/plugins/ install to see if it can be set to return more of a variety

After install, offer to activate the plugin or dismiss dialog.

Yep, Some other stylings need to be applied to that too, I was intending on having it have something like "Activate Now | Go to Plugins page | Dismiss dialogue"

[DD32]

attachment 6015.2.diff added.

Patch implements:

• Actions on plugin install completion
• uses wp_cache_*() on the hot tags as well as a database option (Maybe move wp_cache_*() upstream to plugins_api() instead?
• Better detection/selection if a plugin update is available
• Fixes plugin install via dashboard
• Various small changes (Passing more args to filters, few random code cleanups and reformatting)
• NOTE: API will not work as intended unless ​http://trac.wordpress.org/attachment/ticket/4779/4779.fix.reversed.encode.diff is applied.

[DD32]

Replying to santosj:

The start install plugins page displays serialized array of popular tags:

Example:
1000 a:100:{s:4:...<snip>

That '1000' shouldnt be there, And appears to be preventing it from deserializing.

I believe that may be returned from the HTTP functions, So i'll throw the blame over to #4779 returning more than just the body. Not sure where its coming from, I cant reproduce it.

[DD32]

NOTE: API will not work as intended unless ​http://trac.wordpress.org/attachment/ticket/4779/4779.fix.reversed.encode.diff is applied.

Oh.. It has been commited allready, I forgot to SVN UP before creating the patch :) Patch should be fine applied to a current trunk checkout.

[santosj]

Replying to DD32:

Replying to santosj:

The start install plugins page displays serialized array of popular tags:

Example:
1000 a:100:{s:4:...<snip>

That '1000' shouldnt be there, And appears to be preventing it from deserializing.

My guess is that it is the chunk length. I'm going to svn up and try again.

[santosj]

It is, this is a good time to fix some more problems with #4779.

[santosj]

Fixes double http_build_query() encoding in trunk

[santosj]

Patch in #4779 fixes chunk encoding problem I was having. Patch in this ticket fixes the double encoding problem which would throw an error. It displays the BBPress Error Page, which is kind of not cool.

[ryan]

(In [8550]) Plugin install fixes from DD32. see #6015

[Viper007Bond]

Looking good from a code standpoint, but it needs some serious UI work. It looks like it was just dropped in via a plugin.

I propose we implement a third row of menu items (which has been needed for a very long time) and do other things like rename the "Upload a Plugin". I read that as "upload a plugin to the WordPress.org repository" rather than "install a plugin by uploading a ZIP file".

So yeah, good code, marginal UI (sorry).

[DD32]

So yeah, good code, marginal UI (sorry).

Word choices and UI design are not my strong point :)

do other things like rename the "Upload a Plugin". I read that as "upload a plugin to the WordPress.org repository"

Yeah, I was unsure of what to call that, I thought the "search plugins" page could be renamed to Search or Main, or something, and compress the text there down a bit, its not all needed IMO - an upload field there would suit maybe. General users are not going to reconise that as a "upload to wordpress.org" link though.

I propose we implement a third row of menu items

That has basically been done on many pages allready, using a <ul class="subsub"> Its the list of menu items used on most of the manage pages, ie: "All Posts |Published (1)" they're all the same styled lists.

Can you, or anyone else, Think of some better naming for manually uploading a non-wordpress.org plugin?

[Viper007Bond]

Replying to DD32:

So yeah, good code, marginal UI (sorry).

Word choices and UI design are not my strong point :)

Nor mine. :)

Can you, or anyone else, Think of some better naming for manually uploading a non-wordpress.org plugin?

"Manual Install" or something perhaps.

[DD32]

"Manual Install" or something perhaps.

"Manual Install" to me means to upload the files manually to the folder via ftp or shell or something..

Hmm.. I'll think about it more

[DD32]

[8540] broke the Tagcloud links

[DD32]

Alternate upload plugin location/hide help screen

[DD32]

attachment 6015.3.diff added.
[8540] broke the Tagcloud links

oops.

attachment 6015.4.diff added.
Alternate upload plugin location/hide help screen

How about this? It needs a bit more styling & the use of Swfupload instead of a browser upload bar (Need to work out how to embed swfuplaod :)) - Oh, and it doesnt actually do anything right now, just playing with the UI

[ryan]

(In [8569]) Fix tag cloud links. Props DD32. see #6015

[ryan]

(In [8666]) Revert tag cloud changes in 8540 and 8569. They broke tag sorting. see #6015

[ryan]

Reverted the tag cloud changes. Tags no longer sorted by name. Instead they sorted by count.

[DD32]

re-implements tag cloud changes. Orderby's working. Warning: $number is actually implemented now, Default tag cloud is set for 45-tags maximum

[DD32]

File 6015.tags.2.diff, 3.8 kB (added by DD32, 2 seconds ago)
re-implements tag cloud changes. Orderby's working. Warning: $number is actually implemented now, Default tag cloud is set for 45-tags maximum

It appears that $number wasnt actually implemented in the previous code.. I've added it in, If you want to keep the tag cloud displaying all by default, It may be best to change $number to 0 in the parent function by default.

I have another patch coming to clean up some more bugs & features sometime this week once i workout a strange oddity

[ryan]

(In [8668]) Tag cloud fixes from DD32. Implements number arg. see #6015

[DD32]

Todo:

• Do not trust data from api.wordpress.org, sanitize tags & ensure links are actually links.
• HTTP Error conditions not supported yet, If the connection times out, etc.
• Actually fully implement uploading of a plugin file
• #7395 will need to be implemented in order to fully appreciate the previous bullet
• api.wordpress.org is still missing a .html ;)

I'm a bit snowed under with University assignments, So the only changes i've got locally are half-complete & non-working(Aside from the small changes in 6015.4.diff), More patches will be forthcoming hopefully in a week or so..

[Otto42]

Change request: It would be extremely nice if the install process checked the version number against the "Tested up to:" version in the readme.txt file, and gave the user a warning before installation.

Downsides:

• After a release, more or less every plugin would be giving this warning until the plugin author updated the readme.txt (not the plugin version itself, mind you, upgrading would not necessarily be required via this change).
• In most cases, this warning would serve little purpose as the plugin would work just fine. Users might learn to ignore it.
• Some lazy plugin authors will inevitably set their readme's number quite high in order to make the message go away. This could be countered, but it's a losing game to play.

Upsides:

• It would encourage users to bug plugin authors to keep their plugins maintained. Somebody sees this sort of message, thinks the plugin might have problems or is old, and goes looking for an alternative. This gives plugins encouragement to die after they are no longer maintained.
• If the warning also gives a link to the plugin homepage, it encourages the users to go look there for updated plugins or what have you, instead of complaining at WordPress for the fact that their favorite plugin no longer works.
• It encourages plugin authors to TEST their plugins with newer versions of WordPress, and to update accordingly.

We have the information available, it would be nice to use it for something useful. A simple warning would be appropriate, as long as it doesn't actually interfere with installation of the plugin.

[Utkarsh Kukreti]

Hi,
I have made such a plugin, and it is in beta stage right now.
Please check ​http://www.drunkadmin.com/projects/plugin-manager/
Thanks.

[DD32]

attachment 6015.patch added.

• Plugin install from Uploaded file
• Action links after upgrade/install #7420
• Consolidated iframe code #7797
• Warns if the Plugin has not been tested with the current version of WordPress
• Various other fixes & changes

• Still needs api data run through kses
• Still needs Error conditions to be checked

[ryan]

(In [9141]) Plugin install from DD32. see #6015

[ryan]

(In [9144]) Plugin install updates from DD32. see #6015

[DD32]

Sanitize HTML & Error handling

[DD32]

attachment 6015.6.diff added.

• Sanitize API returned from HTML
• Error handling
• See also: #7807

[ryan]

(In [9163]) Sanitation and error handling for plugin install. Props DD32. see #6015

[ryan]

That changeset has an unrelated stowaway in wp-settings.php. Ignore it.

[ryan]

Marking fixed. Bugs should go in new tickets.

[sussane]

[spam comment removed]