[wp-soc-08] Plugin Installer first thoughts

0 views
Skip to first unread message

DD32 / Dion Hulse

unread,
May 20, 2008, 4:37:12 AM5/20/08
to WordPress Summer of Code 2008
Good Evening/Morning/Midday/Afternoon everyone

First of all, A Big thanks to Westi for mentoring me this year, Thanks
to all the other mentors as well for making it possible in the first
place.

Today was the first time i have had a really good look into the ways
to go forward for my project, And as such, Whipped up a fast first
run.
http://dd32.id.au/files/soc2008/pi1.png

Data Access:
* Proper API: api.wordpress.org
* RSS: http://wordpress.org/extend/plugins/rss/

Proper API:
Would probably be the best way forward, and will give the most
flexibility in both the current need, Allow others access to the
Plugin data on WordPress.org, etc, Will need to be written up from
scratch.

RSS:
Currently *most* of the data on http://wordpress.org/extend/plugins/
can be acessed via RSS; Eg:
http://wordpress.org/extend/plugins/rss/browse/updated/ => Updated
plugins
http://wordpress.org/extend/plugins/rss/tag/admin/ => Plugins tagged
admin
http://wordpress.org/extend/plugins/rss/tag/admin/page/14/ => Plugins
tagged admin, Viewing page 14 of the results

The above image simply uses those RSS feeds, However, The returned
data is limited:
* Unknown how many pages are available (Its just a random value
selected for that mockup, just to get the links to show)
* Data is only URL, Short description, and Author(WordPress.org
username). Author URL(wordpress.org/extend/plugins/ profile) can be
generated from that, as well as its slug, However, No information on
version, or required WP version is mentioned there.

One positive of RSS is that client side, the fetch_rss() caching can
be relied upon (Note: That needs to actually delete old rss items from
the database now and then..), Server side, I have a feeling that the
bbpress install has some kind of caching solution allready in place.

The downside of writing an API, is that it needs to be decided what
information should be returned, and in what format, Which is not a
problem.
My first example of what a return value would be:
http://dd32.id.au/files/soc2008/pi_api_test.html
($object->info['request'] would be what was originally sent to the
server)


Any thoughts from anyone on what needs to be included? What doesnt,
Etc? Should the Installation tab from wordpress.org/extend/plugins/ be
available on the page? etc

Also, the tabs there are filterable, and hookable, So another plugin
can come along and remove a page, or add another one, etc.


Next, There was a comment left on my application:
> I would like to see it including extra filesystem abstraction classes to cover more use cases.
Does anyone have any suggestions for any methods *which PHP can
support* and people actually use? Are there any abstraction problems
with server setups which have not allready been raised as bug
reports?

> Allowing for plugin install from an uploaded zip file would be good too.
I'm all for this one, However, What level can wordpress safely assume
when it comes to the zip file, Can it be assumed it will be in a Sane
format? (as in a wordpress.org/ plugin zip), Should it search out to
actually locate the plugin in the zip? etc.

Anything i've missed?
Any questions anyone wants to ask?
Any feedback no matter how large or small that you'd like to mention?

Should upon clicking install, A dialogue open like the media
manager(in thickbox) asking with "Are you sure you wish to install
this plugin? blah blah, Description, Blah blah, Installation notes,
Blah blah" with "WARNING: this plugin has only been tested up to
WordPress 2.5", Or should it simply install straight away after asking
for ftp details(if needed) and proceed to install straight away, Like
the plugin upgrader.

What functionalities should the search offer?
* By Term
* By Tag (Allow selection of the major tags, or specify own)
* What about multiple tags?
* Combination of Term and Tag?
* Search title AND description for Term, Or select either

Should the number of plugins returned per page be user defineable? I
personally like softing through 100+ results and not having to load
extra pages, Some people prefer it to be limited to a low number, Or
should it just follow what WordPress.org gives it?

If you are not a member of this Google group, You may also email me
off-list with comments, I'll post them up here(Anonymously if you
prefer): word...@dd32.id.au
Reply all
Reply to author
Forward
0 new messages