[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

>

>