[wp-testers] plugin updating...

DD32 wordpress at dd32.id.au
Wed Jun 4 05:01:32 GMT 2008


On Wed, 04 Jun 2008 14:41:18 +1000, Jacob Santos <wordpress at santosj.name>  
wrote:

> Might be time to revive the upgrade script idea (or am I thinking of
> plugin data discussion). Might be useful to have a file called
> upgrade.php (or whatever) which is called within the context of a class
> which gives it access to control the flow of the upgrade.

A combination i think :)

> Dan Milward wrote:
>> Hi Dion,
>>
>> Thanks for the email.
>>
>> If you could come up with a few hooks then that would be awesome. I'm
>> asking because we create plugins and I think it would be useful - the
>> problem we are having right now is that people can add additional php
>> files to our plugin to extend the core features.

Theres a few plugins which did that, At least one has moved to storing  
user content outside of the plugins folder.

>> So when the update the plugin from WordPress extend they loose their
>> work. If we were making a new plugin from scratch then this wouldn't
>> be a problem and we would do it differently but because we already
>> have lots of users I'm not sure we can do it.


A few items that come to mind:
  * Is what happens if the plugin is deactivated when the user upgrades?
  * What happens to current people who upgrade to the new plugin (before  
the deletion handling is added to your plugin)
    * The user will need to move their custom data before doing the  
upgrade, so the user is going to need to move the data regardless.
  * The plugin upgrader likes to install plugins into a folder based on  
their WordPress.org slug, Many older installations do not have this  
format, Which increased the complexity required by the upgrader, so a  
simpler approach was chosen to smooth out the directory names.

The main reason the updater simply deleted everything, Was, What is user  
data? What is plugin data? It has to be assumed its all plugin data, The  
current generation of plugins were *not* going to be able to take  
advantage of any hooks to filter it, In a way, It forces plugins to  
seperate user and program data.

However, Future plugins *will* be able to take care of it, So.. Thats a  
good enough reason i guess for something to happen, but how many  
plugins/users are going to benifit from it?
Its not going to be a change which makes it into 2.5, It'll be a 2.6 item(  
Whoa, Thats due in about a months time:  
http://wordpress.org/about/roadmap/ ).. I was hoping to avoid changing the  
updater code until morphing in a plugin installer.

I'm still going to suggest moving user data outside of the plugin data  
folder though..

>> As an interim what we're going to try and do is just disable auto
>> updates from happening but allow people to manually download updates
>> and do it themselves. For powerful plugins I think this would be
>> extremely cool.

I agree that there'll be some plugins which could take use of it, But i  
still do not think there'll be a great use for it.

As an intrim, My suggestion is to filter the pre_option_update or whatever  
it is to remove the download link from the update option, That'll have the  
effect of notifying that there is a update available, but as it will not  
have a URL to download the zip from, It'll not offer to automatically  
upgrade it.

>> Ciao,
>>
>> Dan
>>
>>
>> DD32 wrote:
>>> It is not currently possible to hook in to make changes to what
>>> is/isnt deleted.
>>>
>>> The plugin directory the files are stored in are often not the same
>>> as the plugin's slug, In order to keep simpler code, all plugins are
>>> stored into a folder based on their slug and the old plugin removed.
>>>
>>> If you have made changes to the core plugin, Consider submitting them
>>> as patches back to the author, or forking the plugn(at least for
>>> yourself = modify the plugin name and url)
>>> If the plugin stores files into its plugin folder, Consider asking
>>> the plugin maintainer to store the data outside of the plugins
>>> folder, Or in the database if its small enough. This has the benefit
>>> of also keeping the plugins folder manageable.
>>>
>>> It may be possible in 2.6 to filter what is/isnt
>>> deleted/removed/modified/etc, There have been 1 or 2 requests for it
>>> so far since 2.5 release :). I'm working on some changes which'll
>>> affect the upgraders code, so i may well try and write a few hooks or
>>> something in, But as it is, there is no list of files which you cna
>>> filter, it just says "Delete that folder and any files in it, i dont
>>> care what the files are, just get rid of them"
>>>
>>> Cheers,
>>> Dion
>>>
>>> On Wed, 04 Jun 2008 10:52:24 +1000, Dan Milward <dan at instinct.co.nz>
>>> wrote:
>>>
>>>> Hi Guys,
>>>>
>>>> How do we add custom code to the plugin updating system to preserve
>>>> files that people may have added to the plugin directory.
>>>>
>>>> Because by default it looks like it deletes the plugin directory and
>>>> replaces the all the files with the updated version - in the process
>>>> deleting any changes.
>>>>
>>>> Ciao,
>>>>
>>>> Dan
>>>>
>>>>
>>>> _______________________________________________
>>>> wp-testers mailing list
>>>> wp-testers at lists.automattic.com
>>>> http://lists.automattic.com/mailman/listinfo/wp-testers
>>>>
>>>
>> _______________________________________________
>> wp-testers mailing list
>> wp-testers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-testers
>
> _______________________________________________
> wp-testers mailing list
> wp-testers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-testers
>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/


More information about the wp-testers mailing list