W razie wątpliwości spójrz na kod źródłowy.
Zagłębiając się get_option()
, zobaczysz (w skrócie):
$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 );
}
}
Najpierw WordPress sprawdza, czy ma już opcję w pamięci. Domyślnie wp_cache_get()
pobierze wartości ze składnicy danych w pamięci (zwykle tylko zmiennej PHP). Ale niektóre instalacje używają bardziej zaawansowanej pamięci podręcznej obiektów, która przechowuje dane w innym miejscu.
W obu przypadkach wp_cache_get()
zwróci wartość opcji, jeśli WordPress już ją zna.
Jeśli nie, WordPress spróbuje pobrać go z bazy danych. Jeśli opcja istnieje w bazie danych, WordPress zapisze ją w pamięci podręcznej, a następnie zwróci - przyspieszając kolejne wyszukiwania.
Jeśli opcja nie istnieje w bazie danych, to WordPress oflaguje ją w wewnętrznej tablicy „te opcje nie istnieją”, więc nie próbuje później sprawdzić, a zamiast tego zwraca pewną wartość domyślną.
Tak więc, aby odpowiedzieć na twoje pierwotne pytanie:
Jeśli użyję tego 10 razy w różnych funkcjach mojej wtyczki, czy WordPress wykonuje 10 zapytań do bazy danych, czy może wykonuje tylko 1 wywołanie bazy danych na żądanie HTTP i buforuje wyniki?
WordPress wykona 1 wywołanie bazy danych na każde żądanie HTTP i buforuje wyniki.