[wp-hackers] Auto Update Plugins

Chris Williams chris at clwill.com
Thu Feb 19 15:48:03 GMT 2009


Embedded responses:

> From: Peter Westwood <peter.westwood at ftwr.co.uk>
> Reply-To: <wp-hackers at lists.automattic.com>
> Date: Thu, 19 Feb 2009 07:48:13 +0000
> To: "wp-hackers at lists.automattic.com" <wp-hackers at lists.automattic.com>
> Subject: Re: [wp-hackers] Auto Update Plugins
> 
> So when a security issue is fixed in a plugin which doesn't support
> you mechanism and the fix involved deleting a file - the update leaves
> the security hole behind.

If I'm a plugin writer, and I'm fixing security issues, am I not likely to
be up to speed on the latest plugin technology?  What percentage of plugins
does this really effect?  How many bug fixes involve removing files?

> Plugins shouldn't be expecting to store user confit in the plugin
> directory.

It's just not clear to me why?  Why shouldn't all things related to a plugin
be in one place?  Doesn't the problem of plugins scattering stuff hither and
yon bother anyone but me?

> It is seperate info - if you want to make it easy for people to style
> you plugin output in the front end then you should be making it easy
> for a theme to do that not encouraging users to store that styling in
> the plugin dir.

So make the whole plugin system more complex and confusing for the small
number of plugins that can't/don't store their info in the database either
as an option or in their own tables, _and_ that feel they need to write
files somewhere other than in the plugin directory.  Ugh.

> 
> Westi
> --
> Peter Westwood
> http://peter.Westwood.name
> 
> On 19 Feb 2009, at 03:36, Chris Williams <chris at clwill.com> wrote:
> 
>> You're making this too complicated.
>> 
>> Plugin is in a zip, with whatever file structure it wants.  The zip
>> gets
>> blasted out there, overwriting old files, creating new ones.  If the
>> zip
>> includes a file called "deprecated.fil" (or something) in the root
>> directory
>> of the plugin, the updater goes through it and deletes any files
>> named in
>> there.  Then the updater deletes "deprecated.fil".  Period.
>> 
>> Accomplishes:
>> - Old files overwritten/updated.
>> - New files added.
>> - Deprecated files removed.
>> - All other files (regardless of how they got there) retained.
>> - Old plugins w/o a "deprecated.fil" file behave as today.
>> 
>> Easy-squeezy.
>> 
>>> From: Stephen Rider <wp-hackers at striderweb.com>
>>> Reply-To: <wp-hackers at lists.automattic.com>
>>> Date: Wed, 18 Feb 2009 21:19:37 -0600
>>> To: <wp-hackers at lists.automattic.com>
>>> Subject: Re: [wp-hackers] Auto Update Plugins
>>> 
>>> On Feb 18, 2009, at 6:11 PM, Chris Williams wrote:
>>> 
>>>> Which seems to me to be exactly how plugin upgrades should work,
>>>> then this
>>>> entire discussion is obviated :)
>>>> 
>>>>> From: Otto <otto at ottodestruct.com>
>>>>> 
>>>>> On Wed, Feb 18, 2009 at 1:04 PM, scribu <scribu at gmail.com> wrote:
>>>>>> BTW, when core-upgrade is called, isn't the entire wp-content
>>>>>> folder
>>>>>> preserved? Or just the themes, plugins and uploads folders?
>>>>> 
>>>>> A core upgrade basically copies all the new files from the
>>>>> distribution over the old ones. Then it goes through a list of "old
>>>>> files" (defined in wp-admin/includes/update-core.php" and deletes
>>>>> any
>>>>> files on that list. So any files not on the list and not in the
>>>>> distribution are preserved.
>>> 
>>> 
>>> No it isn't.  A lot of plugins use add-on files that a user can
>>> simply
>>> upload.  Requiring the plugin to register them somehow requires a lot
>>> of coding for plugins to ID and register files that are uploaded.
>>> Code that is completely unnecessary.  It's a folder, folks.  Again,
>>> it
>>> isn't anything a plugin author can't do already, it's just a question
>>> of creating some sort of standard to follow so such files aren't
>>> scattered all over the place.
>>> 
>>> Adding some registration scheme to WP core is a lot of coding that
>>> isn't needed, and qould require extra code from plugin authors.
>>> 
>>> Just putting it all in /uploads/ dumps a lot of different types of
>>> files -- different as in *use*.  Think about your desktop computer --
>>> this is essentially the difference between Application Support files
>>> and Documents.  They both are used by the apps, but they are
>>> different
>>> things.
>>> 
>>> On Mac OS X, application support files should go in /Library/
>>> Application Support/.  There's nothing particularly special about
>>> that
>>> folder, except that it's the standard place that Apple said should be
>>> the home for such files -- but it does prevent a lot of such files
>>> being scattered all over the hard drive, and makes the folder
>>> structure a LOT cleaner than some other major OSes I could name.
>>> That's basically what I'm asking for here.
>>> 
>>> Stephen
>>> 
>>> 
>>> -- 
>>> Stephen Rider
>>> http://striderweb.com/
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> wp-hackers mailing list
>>> wp-hackers at lists.automattic.com
>>> http://lists.automattic.com/mailman/listinfo/wp-hackers
>> 
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers



More information about the wp-hackers mailing list