Czy powinienem użyć przygotowania wpdb?

Jestem nowy w SQL i zastanawiam się, czy muszę użyć wpdb->prepareponiższego zapytania do utworzonej przeze mnie tabeli

global $wpdb;
$tablename = $wpdb->prefix . "my_custom_table";
$sql = "SELECT * FROM " . $tablename . " ORDER BY date_created DESC";
$resulst = $wpdb->get_results( $sql , ARRAY_A );

Czy muszę preparetutaj korzystać ? Jak mam to zrobić?

Twoje zdrowie

plugin-development mysql wpdb

— Richard Sweeney
źródło

Najlepszą praktyką jest zawsze używać, prepareale jej głównym zastosowaniem jest zapobieganie atakom typu SQL injection, a ponieważ nie ma danych wejściowych od użytkowników / gości lub nie mogą oni wykonać zapytania, nie jest to problem w twoim obecnym przykładzie.

Ale jak powiedziałem wcześniej, najlepszą praktyką jest używanie go, a kiedy zaczniesz go używać, nigdy nie przestajesz, więc w swoim przykładzie możesz użyć go w następujący sposób:

global $wpdb;
$tablename = $wpdb->prefix . "my_custom_table";
$sql = $wpdb->prepare( "SELECT * FROM %s ORDER BY date_created DESC",$tablename );
$results = $wpdb->get_results( $sql , ARRAY_A );

aby dowiedzieć się więcej o tym, jak go używać, przejdź do kodeksu

— Bainternet
źródło

Cześć @Bainternet, dziękuję za tak jasne wyjaśnienie - z jakiegoś powodu, gdy próbuję kodu, zwraca pustą tablicę. Sprawdziłem i podwoiłem liczbę literówek. Jeśli wykonam nieprzygotowane zapytanie, otrzymam tablicę. Nie rozumiem, dlaczego to nie działa ..!

— Richard Sweeney,

Dziwny. Próbowałem użyć tego samego kodu z innym zapytaniem:

$tablename = $wpdb->prefix . "my_custom_table"; $concert_id = 1;  $sql = "SELECT * FROM " . $tablename . " WHERE concert_id = %d LIMIT 1;";  $prep_sql = $wpdb->prepare( $sql, $concert_id );  $get_concerts = $wpdb->get_results( $prep_sql , ARRAY_A );

I działa świetnie! Nie jestem pewien, dlaczego tak jest. Ale w każdym razie rozumiem to!

— Richard Sweeney,

Umieszczanie nazwy tabeli w pojedynczych cudzysłowach nie będzie działać. Normalne jest wyciek z backticks, więc zapytanie powinno wyglądać jak ten: SELECT * FROM `wp_my_custom_table`. Można włączyć podwójne wsparcie środki, ale wtedy musiałby wyglądać tak: SELECT * FROM "wp_my_custom_table".

— Jan Fabry

Nie zgadzam się z tą odpowiedzią. Dlaczego warto uciec, gdy funkcja już wszystko ucieka? Myślisz, że Wordpress zdecyduje się usunąć ucieczkę z rdzenia? Również nie ma sensu zmieniać nazwy tabeli :), ponieważ jest ona zakodowana na stałe i wiesz, że jest w porządku. Wiem, że to tylko przykład, ale i tak nie unikaj nazw tabel, mam problemy podczas korzystania z przygotowywania z nazwami tabel, dodaje backsticks i SQL trows error.

— Tommixoft,

@Tommixoft Jeśli ponownie przeczytasz odpowiedź, zobaczysz, że faktycznie mówisz to samo, co powiedziałem, i że nazwa tabeli jest przykładem.

— Bainternet,

Podczas korzystania z przygotowania chroni kod przed lukami w zabezpieczeniach SQL injection.

Oto kod, który musisz zmodyfikować, aby używać prepare();

global $wpdb;
$tablename = $wpdb->prefix . "my_custom_table";
$sql = $wpdb->prepare( "SELECT * FROM {$tablename} ORDER BY date_created DESC");
$resulst = $wpdb->get_results( $sql , ARRAY_A );

— softnwords
źródło

W twoim przypadku nie jest możliwy atak iniekcji SQL . Twój kod nie wymaga dodatkowej ochrony, ponieważ nie korzystaj z danych wejściowych użytkownika, takich jak: wysyłanie, pobieranie, żądanie, cookie.

Nie używaj skomplikowanej funkcji, gdy nie są konieczne do oszczędzania zasobów serwera.

— SaschArt
źródło