WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#6015 closed enhancement (fixed)

Allow plugin installations via web interface.

Reported by: DD32 Owned by: westi
Milestone: 2.7 Priority: normal
Severity: normal Version: 2.7
Component: Administration Keywords: plugin install blessed summerofcode
Focuses: Cc:

Description

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

Attachments (11)

6015.diff (19.4 KB) - added by DD32 6 years ago.
First (relitivly) quick scrape of integration.
plugin-install.diff (55.0 KB) - added by DD32 6 years ago.
GSOC work as of 3rd August
6015.2.diff (11.4 KB) - added by DD32 6 years ago.
6015.r8547.diff (909 bytes) - added by santosj 6 years ago.
Fixes double http_build_query() encoding in trunk
6015.3.diff (1.2 KB) - added by DD32 6 years ago.
[8540] broke the Tagcloud links
6015.4.diff (4.6 KB) - added by DD32 6 years ago.
Alternate upload plugin location/hide help screen
6015.tags.diff (3.4 KB) - added by DD32 6 years ago.
6015.tags.2.diff (3.8 KB) - added by DD32 6 years ago.
re-implements tag cloud changes. Orderby's working. Warning: $number is actually implemented now, Default tag cloud is set for 45-tags maximum
6015.patch (28.8 KB) - added by DD32 6 years ago.
6015.5.diff (2.1 KB) - added by DD32 6 years ago.
6015.6.diff (5.2 KB) - added by DD32 6 years ago.
Sanitize HTML & Error handling

Download all attachments as: .zip

Change History (60)

DD326 years ago

First (relitivly) quick scrape of integration.

comment:1 follow-up: DD326 years ago

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

comment:2 in reply to: ↑ 1 Viper007Bond6 years ago

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.

comment:3 DD326 years ago

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

comment:4 ryan6 years ago

  • Keywords blessed added

comment:6 DD326 years ago

blessed summerofcode.

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

comment:7 westi6 years ago

  • Owner changed from anonymous to westi
  • Status changed from new to assigned

DD326 years ago

GSOC work as of 3rd August

comment:8 DD326 years ago

  • Milestone changed from 2.9 to 2.7

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

comment:9 westi6 years ago

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

comment:10 westi6 years ago

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

comment:11 westi6 years ago

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

Think I may have broken the image.

comment:12 ryan6 years ago

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

comment:13 ryan6 years ago

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

comment:14 santosj6 years ago

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

comment:15 follow-up: santosj6 years ago

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:

comment:16 santosj6 years ago

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

comment:17 santosj6 years ago

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.

comment:18 santosj6 years ago

WP Super Cache 0.6.6 featured plugin also displays serialized data.

comment:19 santosj6 years ago

Installation of a plugin worked perfectly.

comment:20 ryan6 years ago

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

comment:21 DD326 years ago

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"

DD326 years ago

comment:22 DD326 years ago

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.

comment:23 in reply to: ↑ 15 ; follow-up: DD326 years ago

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.

comment:24 DD326 years ago

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.

comment:25 in reply to: ↑ 23 santosj6 years ago

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.

comment:26 santosj6 years ago

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

santosj6 years ago

Fixes double http_build_query() encoding in trunk

comment:27 santosj6 years ago

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.

comment:28 ryan6 years ago

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

comment:29 Viper007Bond6 years ago

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

comment:30 follow-up: DD326 years ago

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?

comment:31 in reply to: ↑ 30 Viper007Bond6 years ago

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.

comment:32 DD326 years ago

"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

DD326 years ago

[8540] broke the Tagcloud links

DD326 years ago

Alternate upload plugin location/hide help screen

comment:33 DD326 years ago

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

comment:34 ryan6 years ago

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

comment:35 ryan6 years ago

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

comment:36 ryan6 years ago

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

DD326 years ago

DD326 years ago

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

comment:37 DD326 years ago

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

comment:38 ryan6 years ago

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

comment:39 DD326 years ago

  • Version set to 2.7

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

comment:40 Otto426 years ago

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.

comment:41 Utkarsh Kukreti6 years ago

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.

DD326 years ago

comment:42 DD326 years ago

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

comment:43 ryan6 years ago

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

DD326 years ago

comment:44 ryan6 years ago

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

DD326 years ago

Sanitize HTML & Error handling

comment:45 DD326 years ago

attachment 6015.6.diff added.

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

comment:46 ryan6 years ago

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

comment:47 ryan6 years ago

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

comment:48 ryan6 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

Marking fixed. Bugs should go in new tickets.

comment:49 sussane3 years ago

[spam comment removed]

Last edited 3 years ago by SergeyBiryukov (previous) (diff)
Note: See TracTickets for help on using tickets.