[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