Long option names fail silently?

This was really driving me crazy. I was debugging some code with code-generated transient names and they were failing like crazy for no apparent reason.

After much much pain and experimentation I figured out that it fails when over certain key length:

$key = '1234567890';
var_dump( get_transient($key) ); // works just fine
var_dump( set_transient( $key, $key, 10) ); // false when not expired


$key = '1234567890123456789012345678901234567890123456';
var_dump( get_transient($key) ); // always returns false
var_dump( set_transient( $key, $key, 10) ); // always true

Apparently option_name field in database is varchar(64).

However I absolutely can’t figure out why this doesn’t produce any database errors and all returns and hooks on setting transient work just fine… Except that in reality timeout option doesn’t get written and it all fails miserably.

I suspect this query in add_option():

$result = $wpdb->query( $wpdb->prepare( "INSERT INTO `$wpdb->options` (`option_name`, `option_value`, `autoload`) VALUES (%s, %s, %s) ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`)", $option, $value, $autoload ) );

Can anyone help figure out what it should do when option’s name passed is too long and why it doesn’t produce errors or anything?

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

You don’t get an error because WordPress does not check for the length, and MySQL silently truncates it (giving a warning, not an error), unless you enable the STRICT_ALL_TABLES option (which will change the warning into an error).

Even more confusing, when you enable multisite the options are saved in the sitemeta table with a maximum key length of 255, but without multisite they go to options where the maximum key length is 64. Have fun debugging that in your plugin!

Method 2

I ran into this exact issue and proposed extending the column length:

http://core.trac.wordpress.org/ticket/13310

Method 3

Very weird behavior. I’m guessing that the option is being added, but its name is truncated to 64 characters? That way $wpdb->rows_affected returns 1, as it should for this check to pass at the end of update_option:

$wpdb->update($wpdb->options, array('option_value' => $newvalue), array('option_name' => $option_name) );

if ( $wpdb->rows_affected == 1 ) {
   do_action( "update_option_{$option_name}", $oldvalue, $_newvalue );
   do_action( 'updated_option', $option_name, $oldvalue, $_newvalue );
   return true;
}

But the option isn’t accessible through get_option because the option_name field is not equal to $key.

Extending the column length is one solution, but it seems that there should be an additional check at the end of update_option that the row affected matches the key provided. And possibly the same with other update functions like update_post_meta, although the 255 char limit there is much more reasonable.

Method 4

You can update the table and increase the row size?

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0