Коли ви сумніваєтесь, подивіться на вихідний код.
Покопившись get_option()
, ви побачите (скорочено):
$value = wp_cache_get( $option, 'options' );
if ( false === $value ) {
$row = $wpdb->get_row( $wpdb->prepare( "SELECT option_value FROM $wpdb->options WHERE option_name = %s LIMIT 1", $option ) );
// Has to be get_row instead of get_var because of funkiness with 0, false, null values
if ( is_object( $row ) ) {
$value = $row->option_value;
wp_cache_add( $option, $value, 'options' );
} else { // option does not exist, so we must cache its non-existence
$notoptions[$option] = true;
wp_cache_set( 'notoptions', $notoptions, 'options' );
return apply_filters( 'default_option_' . $option, $default );
}
}
По-перше, WordPress перевіряє, чи є в ньому вже опція в пам'яті. За замовчуванням wp_cache_get()
отримає значення із сховища даних в пам'яті (зазвичай це лише змінна PHP). Але деякі установки використовують більш досконалий об'єкт-кеш, який зберігає дані в іншому місці.
У будь-якому випадку wp_cache_get()
поверне ваше значення параметра, якщо WordPress це вже знає.
Якщо ні, то WordPress спробує захопити його з бази даних. Якщо опція існує в БД, то WordPress буде кешувати її в пам’яті, а потім повертати її назад, роблячи наступні пошуки швидшими.
Якщо опція не існує в базі даних, то WordPress позначає її у внутрішньому масиві "цих параметрів не існує", тому він не намагається шукати її пізніше і замість цього повертає якесь значення за замовчуванням.
Отже, щоб відповісти на ваше первісне запитання:
Якщо я використовую це 10 разів у різних функціях мого плагіна, чи WordPress робить 10 запитів до бази даних, чи робить він лише 1 виклик бази даних на запит HTTP та кешує результати?
WordPress здійснить 1 дзвінок до бази даних на запит HTTP і кешуватиме результати.