这真让我抓狂。我用代码生成的临时名称调试了一些代码,但它们毫无理由地疯狂地失败了。
在经历了很多痛苦和实验之后,我发现当超过某个密钥长度时,它会失败:
$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
显然
option_name
数据库中的字段为
varchar(64)
.
然而,我绝对不明白为什么这不会产生任何数据库错误,以及设置瞬态工作的所有返回和挂钩都很好。。。但事实上,超时选项并没有被写入,而且都失败得很惨。
我怀疑这个问题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 ) );
有人能帮我弄清楚当传递的选项名称太长时它应该怎么做,以及为什么它不会产生错误或任何东西吗?
SO网友:goldenapples
非常奇怪的行为。我猜该选项正在添加,但其名称被截断为64个字符?那样的话$wpdb->rows_affected
返回1,因为此检查应该在结束时通过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;
}
但该选项无法通过访问
get_option 因为option\\u name字段不等于$key。
扩展列长度是一种解决方案,但似乎应该在update\\u选项的末尾额外检查受影响的行是否与提供的键匹配。可能与其他更新函数相同,如update_post_meta, 虽然255个字符的限制更为合理。