WordPress Update Plugin Discussion.
Dion Hulse / DD32
me about my Proposal, any questions, suggestions, and even negitive
comments, are welcome from all.
I've got a few questions though to start off this discussion with
though.
1. Who would i contact with regard to themes.wordpress.org, and
wordpress.org/extend/plugins/ ?(i've taken a look around, and havnt
spotted anyone who keeps either maintained yet -- probably missed it)
2. with the SVN hosting, As far as i can see, Google only require code
uploaded at mid, and final points. I'd prefer to host my development
on dev.wp-plugins.org, Simply due to wanting to retain the same
repository location/bug tracker/etc for during, and after SoC. I'm
unsure if SVN:External can be used to redirect repositories(I only
know how to use them from the point of a comitter); But would be
hosting it on dev.wp-plugins.org be OK? I'll do a SVN copy to
code.google.com for the mid/final though in order to keep Google
happy.
I had some others that were in my mind, however cant quite think of
them right now (Long day!).
http://groups.google.com/group/wordpress-soc-2007/web/wordpress-update-plugin?hl=en
D
Lloyd Budd
>
> Heres a thread for any questions that people would like to direct at
> me about my Proposal, any questions, suggestions, and even negitive
> comments, are welcome from all.
>
> I've got a few questions though to start off this discussion with
> though.
> 1. Who would i contact with regard to themes.wordpress.org, and
> wordpress.org/extend/plugins/ ?(i've taken a look around, and havnt
> spotted anyone who keeps either maintained yet -- probably missed it)
themes.wordpress.net ? Is an independent fantastic project (but
Automattic servers) by Thomas Silkjær (theundersigned).
wordpress.org/extend/plugins/ is Michael Adams (mdawaffe).
> 2. with the SVN hosting, As far as i can see, Google only require code
> uploaded at mid, and final points.
My preference is for the duration of the summer of code that the
code.Google.com repository be used for all the projects. That makes it
easiest for community members to see the progress and participate. If
your mentor prefers otherwise, that is fine.
> I had some others that were in my mind, however cant quite think of
> them right now (Long day!).
>
> http://groups.google.com/group/wordpress-soc-2007/web/wordpress-update-plugin?hl=en
Possibly the first item is to participate in:
WordPress Update Notification
http://trac.wordpress.org/ticket/1476
As there is not yet "one click" update of WordPress, as you describe
it will be very important to check for the version of a plugin being
compatible with the version of WordPress being run.
I would recommend ignoring themes until after you develop a solution
for plugins. I would work through the problem:
1. Notification
2. Assist Updating?
(3. Searching)
4. Notification of Themes
5. Updating
# Installing new plugins or themes
# "One click" update/install of plugins
# "One click" update/install of themes
I would recommend working with wordpress.org/extend/plugins first, and
then look to include other / independent repositories. I am not
familar with theme repositories.
Cheers,
Lloyd
Robert Deaton
I'll be sure to reply to this mail later tonight once I get home, I'm
about to head out on the road.
I'm not ignoring you I swear! :)
--
--Robert Deaton
Dion Hulse / DD32
> themes.wordpress.net ? Is an independent fantastic project (but
> Automattic servers) by Thomas Silkjær (theundersigned).
>
> wordpress.org/extend/plugins/ is Michael Adams (mdawaffe).
Cheers, Looks like i got .net and .org mixed up while going through it
all :)
I should've noticed the "Maintained by..." mention on
themes.wordpress.net as well..
>
> > 2. with the SVN hosting, As far as i can see, Google only require code
> > uploaded at mid, and final points.
>
> My preference is for the duration of the summer of code that the
> code.Google.com repository be used for all the projects. That makes it
> easiest for community members to see the progress and participate. If
> your mentor prefers otherwise, that is fine.
>
Thats fine by me :) I've got a local SVN repos that i'll move onto the
Google Repos soon.
>
> Possibly the first item is to participate in:
> WordPress Update Notificationhttp://trac.wordpress.org/ticket/1476
Thanks, i didnt notice that ticket, i've taken a look at it later.
> As there is not yet "one click" update of WordPress, as you describe
> it will be very important to check for the version of a plugin being
> compatible with the version of WordPress being run.
Thats being checked allready, And the plugin sandbox(die on fatal
error) is really helpful there, if it is activated, it'll be prevented
from pulling the entire blog down..
>
> I would recommend ignoring themes until after you develop a solution
> for plugins. I would work through the problem:
> 1. Notification
> 2. Assist Updating?
> (3. Searching)
I've allready started work on it, and Notification is working for some
plugins (Mind you it'd be much easier once/if wordpress.org is extnded
to have a data interface -- which i'll work out with the parties
involved in that at a later stage soon)
> 4. Notification of Themes
> 5. Updating
Thats been moved to the end of the priority list really, Themes
updates are a lot less often, and sometimes will never happen for the
majority of themes, so its not going to be a huge priority, but i'll
still at least do some notifications (if posible) and updating them
will be most likely much similar to the plugin update.
> # Installing new plugins or themes
> # "One click" update/install of plugins
> # "One click" update/install of themes
If the plugin is set to assist in upgrading/installing for the user
the plugin, then these 2 items would come in tow with an additonal
menu item (which is in SVN, just not working since the underlying code
is so far unwritten)
>
> I would recommend working with wordpress.org/extend/plugins first, and
> then look to include other / independent repositories. I am not
> familar with theme repositories.
Wordpress.org/extend/plugins is my main priority, and more and more
items are being added..
The only problem i've seen so far which i'm yet to work around, is
that some plugins are listed under completely different names, ie. in
Wordpress it'll be called "WP-X Y Z" but in wordpress.org some items
are listed as "X Y Z" (ie. missing, or extra words) But I should be
able to work out something there once i look at that specific item a
bit more.
>
> Cheers,
> Lloyd
On May 16, 7:19 am, "Robert Deaton" <false.ho...@gmail.com> wrote:
> Geh, my apologies, I completely missed this mail the first time it hit my inbox.
Happens to the best ;)
> I'll be sure to reply to this mail later tonight once I get home, I'm
> about to head out on the road.
>
> I'm not ignoring you I swear! :)
Sure your not; Sure you not :P
I've got major assignment work which is going to take me upto the 1st
June to complete(Hopefully it wont take that long, but its the due
dates, and it may happen that i'll have to focus all my attention on
them), I've then got my final exams about the 20th of June as well, So
until after then, my tiem is going to be split between priorities, I
think i've got a fair amount of basic stuff done allready, which
should make the lack of time at the start of the program less of an
issue.
I also notice that plugin notification is something which people want
included in core 2.3 via the wp-hackers list, So i'm going to get my
SVN repos copied to the public section sometime in the next week i
hope(when i can afford to sit down and work out the SVN commands to do
such a thing), just so that others can see the work and direction i've
undertaken for it so far.
Cheers.
D
Dion Hulse / DD32
At present i'm using the WP Object cache to cache the update status
data for each plugin, however, as i found out after a bit of bug
hunting, it ignores the custom expire time, and all objects expire 900
seconds after being added.. so i did this: http://trac.wordpress.org/ticket/4179
I was thinking that i could use the Cache for short-term stuff, and
store the rest as an option in the database(ie. Get from cache, if not
in cache, check get_option, If the expire value stored with the data
in the option is expired, get a new set of information; Update option,
update cache).. Is that the best method for such data? keeping in mind
that i'd probably want to keep the data about the update object for
say, a week.
The only downside i could see of that would be storing an option for
each plugin (as it wouldnt be good to store them in the same key due
to reading from it while having it updated in another process..), But
thats probably not a big issue either, getting the options wouldnt be
a huge performance hit or anything...
On that note, I havnt looked at it yet, But i know its possible to
have options automatically loaded from the database in one swoop at WP
startup, Would it perhaps be an idea for having an option to
automatically load certain options from the database en-mass for the
Admin panel?
It seems a waste automatically loading options only the admin panel
needs for general blog views; but it also seems pointless having to go
back to the database continuously for the admin panel items.. then
again, It may only be a small performance hit, I havnt actually looked
into it; Just assumed and thinking out loud.
D
Michael D Adams
wrote:
> Wordpress.org/extend/plugins is my main priority, and more and more
> items are being added..
> The only problem i've seen so far which i'm yet to work around, is
> that some plugins are listed under completely different names, ie. in
> Wordpress it'll be called "WP-X Y Z" but in wordpress.org some items
> are listed as "X Y Z" (ie. missing, or extra words) But I should be
> able to work out something there once i look at that specific item a
> bit more.
I believe this is caused by a discrepancy between the readme.txt's
title and the meta data in the plugin file. That problem can be fixed
a few different ways on /extend/plugins' end, but notification based
only on Plugin Name will break anyway. Authors could (and have)
changed their plugin name from one release to the next. Abusers could
(and would) name their plugin "Akismet" or after some other popular
plugin so that their plugin info is sent instead of Akismet's
(protecting against this is trickier than first glance would
indicate).
If the notification/update data could be directly reached from the
plugin URL (or a new meta datum: Update URL) specified in the plugin
file we would mitigate that kind of problem.
There's all sorts of ways we could do that. Host some XML or
something at http://wordpress.org/extend/plugins/foo-bar/update/ (or
whatever), send the required info in the HTTP headers of
http://wordpress.org/extend/plugins/foo-bar/ and grab it with a HEAD
request, modify the pre-existing RSS feeds. I'm down with whatever
schema we want to use and can help implement it on extend/plugins/.
But, since I don't know how your code works, I have no idea if the
above is drivel :)
Mike
Dion Hulse / DD32
> I believe this is caused by a discrepancy between the readme.txt's
> title and the meta data in the plugin file. That problem can be fixed
> a few different ways on /extend/plugins' end, but notification based
> only on Plugin Name will break anyway. Authors could (and have)
> changed their plugin name from one release to the next. Abusers could
> (and would) name their plugin "Akismet" or after some other popular
> plugin so that their plugin info is sent instead of Akismet's
> (protecting against this is trickier than first glance would
> indicate).
I have to agree with that, And that was one of the first things i
thought of, plugin names change all the time.
The current state of checking is this:
- Check for an "Update URL:" in the plugin file
- (Not yet implemented, but an action of "pluginfile.php_updateurl" or
something)
- Do a search on wordpress.org/extend/plugins/ for the plugin title as
in WP
- if a Plugin Exact title match is there, Use that plugin
- else, look through the Suggested plugins for a plugin which seems to
match(Right now i cant remember exactly how i did that part)
- Then check any other plugin sites that may be defined. ( I'm
thinking of just havingthe wordpress.org repository built in, however,
allowing other plugins to load additional repositories to check them)
Right now its simply using a HTTP Scrape, but thats not prefered, it
was just a quick hack for while i wanted to see something working.
As for plugins taking someone elses plugin name.. Hopefully that isnt
possible at present, but, its possible it would happen..
The only way to avoid that would be for the plugin to specify its
update location, The downside of that however, is that not all plugin
authors are going to spend the time to add that detail, and that
doesnt help all those people using out of date plugins at the time of
installing this one... Searching for it seems the best idea, but at
the same time, there'll need to be some kind of protection there..
I'll have a think about it :)
>
> If the notification/update data could be directly reached from the
> plugin URL (or a new meta datum: Update URL) specified in the plugin
> file we would mitigate that kind of problem.
>
> There's all sorts of ways we could do that. Host some XML or
> something athttp://wordpress.org/extend/plugins/foo-bar/update/(or
> whatever), send the required info in the HTTP headers ofhttp://wordpress.org/extend/plugins/foo-bar/and grab it with a HEAD
> request, modify the pre-existing RSS feeds. I'm down with whatever
> schema we want to use and can help implement it on extend/plugins/.
I'm open to what to provide from wordpress.org really.. XML, RSS,
plain HTML, PHP Serialized value.
I'll also be making a plugin for Plugin Authors to host their own
update feed for the plugin, using a PHP Serialized value seems to be
the most lightweight option, And given that its only primarily geared
towards PHP clients, then the PHP Serialised method should be rather
lightweight in terms of processing it.
Just as long as i can access all the needed data (Which i'll pull up a
list of in the near future).
Matt Mullenweg
guaranteed unique within the wp.org world.
On May 17, 10:52 am, Michael D Adams <michael.d.ad...@gmail.com>
wrote:
> On May 16, 6:45 pm, "Dion Hulse / DD32" <dd32.crazy...@gmail.com>
> wrote:
>
> > Wordpress.org/extend/plugins is my main priority, and more and more
> > items are being added..
> > The only problem i've seen so far which i'm yet to work around, is
> > that some plugins are listed under completely different names, ie. in
> > Wordpress it'll be called "WP-X Y Z" but in wordpress.org some items
> > are listed as "X Y Z" (ie. missing, or extra words) But I should be
> > able to work out something there once i look at that specific item a
> > bit more.
>
> I believe this is caused by a discrepancy between the readme.txt's
> title and the meta data in the plugin file. That problem can be fixed
> a few different ways on /extend/plugins' end, but notification based
> only on Plugin Name will break anyway. Authors could (and have)
> changed their plugin name from one release to the next. Abusers could
> (and would) name their plugin "Akismet" or after some other popular
> plugin so that their plugin info is sent instead of Akismet's
> (protecting against this is trickier than first glance would
> indicate).
>
> If the notification/update data could be directly reached from the
> plugin URL (or a new meta datum: Update URL) specified in the plugin
> file we would mitigate that kind of problem.
>
> There's all sorts of ways we could do that. Host some XML or
> something athttp://wordpress.org/extend/plugins/foo-bar/update/(or
> whatever), send the required info in the HTTP headers ofhttp://wordpress.org/extend/plugins/foo-bar/and grab it with a HEAD
Dion Hulse / DD32
allthough plugin authors could make an effort to supply a unique slug,
that thats not going to help those people allreayd running out of date
plugins.
Eg. When i first ran it, i found that 3 plugins i use are out of
date, and have been superceeded by more secure versions... If i was to
rely on the plugins to supply the update details, then i wouldnt be
able to pick up on any of the currently running plugins (As at
present, theres probably only a small hanfdful which support an update
method).
In other news, I submitted my code to SVN;
http://wordpress-soc-2007.googlecode.com/svn/trunk/dd32.crazyman/trunk/
Sam Bauers
updates arrive would be lost, I think you should stick to the basics
first and just go query a file which the plugin developer specifies in
their plugin header as "Update URI"
If people don't want to add this information then so be it, but I
imagine it would become quite normal to do so.
Another thought. You might be able to make good use of a query to the
web interface for the subversion repository of wp.org/extend/plugins.
You could even keep track of the revision number of individual plugins
or the whole thing. The revision number is reported in the Etag http-
header, also the Last-Modified date appears to be effectively
reporting the last update of the plugin folders, so that could be used
in the case of older plugins. You could simply query the current date
against these Last-Modified headers. The svn is browse-able here.
You only need to fetch the headers to get the information you really
need.
Dion Hulse / DD32
wrote:
> Although the fun of working on the fuzzy logic of when and how plugin
> updates arrive would be lost
I'm working on that, I'm going to move it into more manageable function,
using filters/actions or something,
Searching the databases is the last option in the process of looking for
an update, however it was the first option implemented
> I think you should stick to the basics
> first and just go query a file which the plugin developer specifies in
> their plugin header as "Update URI"
> If people don't want to add this information then so be it, but I
> imagine it would become quite normal to do so.
Thats implemented, I've also just scratched up a wp-update-manager which
allows a plugin developer to host the plugin update check.
> Another thought. You might be able to make good use of a query to the
> web interface for the subversion repository of wp.org/extend/plugins.
> You could even keep track of the revision number of individual plugins
> or the whole thing. The revision number is reported in the Etag http-
> header, also the Last-Modified date appears to be effectively
> reporting the last update of the plugin folders, so that could be used
> in the case of older plugins. You could simply query the current date
> against these Last-Modified headers. The svn is browse-able here.
>
> http://svn.wp-plugins.org/
>
> You only need to fetch the headers to get the information you really
> need.
Didnt know about that interface, It'll be an idea, I'm intending on using
the wp.org/extend/plugin/ system to do most of that stuff, I'll be looking
at getting some form of API added into that as well to allow searching for
plugins.
I was also asked in an email is SFTP would be a possibility for the plugin.
Its possible it seems, the PHP FTP functions include SFTP support, so i'll
work that into the PHP-Ftp class at a later point.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/