[wp-hackers] readme.txt: "Requires PHP 5 tag"

Will Anderson wp-hackers at itsananderson.com
Thu Jul 16 18:31:22 UTC 2009


While it would be convenient to have an extra parameter or something, I
think the idea was to simulate the "correct" manual upgrade procedure. That
is, disable the plugin, upload the update, then enable it again. This is
essentially what happens when you use the auto-upgrader, except that you
don't have to do any of it manually.
One possible way to keep track of updates, first time installs, and simple
disable/enable actions is to use an option that contains the current version
number. Then when the plugin is enabled you check the version in the
database. If the option doesn't exist, the plugin has most likely just been
installed. If it exists, but is an older version, an update has most likely
been done. If it's the same version, then the user probably just disabled
the plugin and then enabled it again without making any changes.
I can't see any issues with what I just described, but if I'm off base in
any way, by all means, fire away!


-- 
Will Anderson
http://www.itsananderson.com/



On Thu, Jul 16, 2009 at 12:11 PM, Aaron D. Campbell <aaron at xavisys.com>wrote:

> I think it would be nice to know if it's an upgrade (maybe an extra
> parameter to the activation hook), but it's definitely nice that it runs.
>  Especially for plugins that have database tables and may want to adjust
> those tables for the new version.
>
> scribu wrote:
>
>> On Thu, Jul 16, 2009 at 11:46 AM, Joost de Valk <joost at yoast.com> wrote:
>>
>>
>>
>>> Ehm, dare I say that if it's called "activation" hook, it should not be
>>> run
>>> during upgrades?
>>>
>>>
>>
>>
>> During an upgrade, the plugin is deactivated and then reactivated, so it
>> makes sense.
>>
>>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>


More information about the wp-hackers mailing list