[wp-hackers] Options table' varchar 64.

[J.D. Grimes]

Nacin and Nikola are right.

But I’d also like to add that I think you have a misconception about the plugin activation when WordPress is updated. I don’t think the activation hooks actually get fired, it is just a silent de/activation (someone correct me if I’m wrong). You are correct though, that you wouldn’t want to run this every time. You would ideally check the length of the column, and only change it if it wasn’t at the desired length already. Or, you could set an option in the database after the first time, and only run the update if it did not exist (this is how many plugins keep track of their database version).

Of course, you really shouldn’t try to do this anyway. :0)

-J.D.

On Jun 24, 2014, at 3:47 PM, Haluk Karamete <halukkaramete at gmail.com> wrote:

> Now giving it a second thought, and considering what Morgan has brought
> into the picture on this very quesition, doing this at a plug-in activation
> time does not sound to me as good of an idea as it did an hour ago.  :)
> 
> If it's gonna take that much of time, then every time WP updates, ( and as
> part of this update, all plugins are automatically deactivated and then
> re-activated ) a nd as a result of this, some users will experience such
> slowness, and my plug in would be the one causing that, it's hard for me to
> take that route... See what I mean?
> 
> I think if that code were to be planted in the wp-config.php file instead,
> then that would have been better.
> 
> At wp-config, and every time it runs ( meaning at each page load), a
> constant can be probed to see if it is defined or not.
> 
> If that constant is defined, I can drive the fact that the  option names
> has already been upped to varchar(128).
> 
> What say you?
>