[wp-testers] plugin updating...

Andy Staines andy at yellowswordfish.com
Wed Jun 4 08:21:07 GMT 2008 

You should tell me to read the instructions!!!!
I am being guilty of something I tell others of for. ... laziness!


On 4 Jun 2008, at 06:11AM, deliciousdays wrote:

> 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
>>>
>>
> _______________________________________________
> wp-testers mailing list
> wp-testers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-testers

More information about the wp-testers mailing list