[wp-testers] plugin updating...

[deliciousdays]

For the time being I simply offer users of cforms the option to store 
all customized files (CSS, fonts, images) in a separate folder, e.g.

plugins/
    cforms/                    <-- plugin folder
    cforms-custom/         <-- custom folder

Of course this is optional. Not a perfect way, but one that works well.

***
deliciousdays.com / cforms <http://www.deliciousdays.com/cforms-plugin>



DD32 wrote:
> 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
>>
>