[wp-hackers] Auto Update Plugins

[mikeschinkel at newclarity.net]

Once again +1 to this.

Chris' suggestion would solve the problem I had where using Subversion  
on the entire install (plugins and all) breaks the plugin updater (it  
currently deletes the existing plugin version but won't install the  
new version when a read-only .svn directory exists in the plugin  
directory.)

-Mike

Sent from my iPhone

On Feb 18, 2009, at 10:40 PM, Chris Williams <chris at clwill.com> wrote:

> And one more advantage.  If I want to delete a plugin, I remove the
> directory. That's it.  No turds left scattered all over the place, in
> "bucket" directories that gather all kinds of turds of unknown  
> origin.  All
> plugin files live in the plugin's directory or its children.
>
> What could be simpler?
>
>
>> From: Chris Williams <chris at clwill.com>
>> Date: Wed, 18 Feb 2009 19:36:58 -0800
>> To: <wp-hackers at lists.automattic.com>
>> Conversation: [wp-hackers] Auto Update Plugins
>> Subject: Re: [wp-hackers] Auto Update Plugins
>>
>> 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