[geeklog-devel] Plugin upgrade failure (was: More automation)

[cordiste]

Oups I discover that bug #1345 [1] was fixed yesterday.

Ben

[1] http://project.geeklog.net/tracking/view.php?id=1345

2011/5/22 cordiste <cordiste at free.fr>:
> This seems to be related to bug #1165 [1]
>
> Why not automatically disable plugin when the admin hit the upload
> button, then enable the plugin and lets the admin hit the upgrade
> button ?
>
> Ben
>
> [1] http://project.geeklog.net/tracking/view.php?id=1165
>
> 2011/5/21 Dirk Haun <dirk at haun-online.de>:
>> Rouslan Placella wrote:
>>
>>> * install plugin v1.0.0
>>> * upload version 1.1.0
>>> * autoupdate takes place
>>> * Geeklog reports that version 1.1.0 is installed, but it's not true.
>>> plugin_upgrade_foobar() was never called. So the files are up to date,
>>> but the database as well as the configuration settings are from version
>>> 1.0.0
>>
>> Nice fine. Looks like this case never worked correctly in the first place.
>>
>> The problem was that while we replaced the plugin's functions.inc, we were still calling the upgrade function from the old copy, which was still in memory at this point.
>>
>> I've fixed this by splitting the upgrade in two parts now: When all the files have been replaced and we've confirmed that we do need to call PLG_upgrade, it does a COM_refresh on itself now to force a (re)load of the (new) functions.inc.
>>
>> One implementation detail that I'm not happy with: This refresh happens without a security token, since COM_refresh doesn't cause a referrer to be set. I've tried to be extra thorough with the sanity checks but wouldn't mind another pair of eyes to have a look:
>>
>> http://project.geeklog.net/cgi-bin/hgwebdir.cgi/geeklog/rev/ce9647bd2310
>>
>> bye, Dirk
>>
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>>
>>
>