[wp-hackers] Table prefix with captial letters

Eric Mann eric at eamann.com
Mon Sep 27 14:41:50 UTC 2010

I follow the same setup WordPress uses to update its own database.  I store a
database version number in the options table and key my installations/updates on
that value.  If it's missing, I assume a new installation and create my tables.
 If it's there but out of date, I use a switch statement to select the
appropriate update scripts and run it to bring my tables up to date with the
current spec.
It's not foolproof, because the user could delete the value I'm storing in the
options table.  But when you start down the road of "how could the user
intentionally break my script?" there's no real way to make an update/install
routine *that* foolproof.

On September 27, 2010 at 2:32 PM Alex Rabe <alex.cologne at googlemail.com> wrote:

> After a very long time I found the reason why some user can't upgrade
> or install my plugin. Initially I followed the  Codex
> recommendation( http://codex.wordpress.org/Creating_Tables_with_Plugins
> ) if a table is already installed or not :
> if($wpdb->get_var("SHOW TABLES LIKE '$table_name'") != $table_name)
> The problem with this check is when the table prefix contain a captial
> letter (ie "WP_"), the check will failed as it's case sensitve (The
> MySQL System variable 'lower_case_table_names' force a lower case
> table name).
> Of course it's simple to check in this case for :
> if( strcasecmp ( $wpdb->get_var("show tables like '$table_name"),
> $table_name) != 0 )
> But I would like to know if someone knows a better or more foolproof
> check for upgrade & install routines
> _______________________________________________
> 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