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

[cordiste]

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
>
>