Przy wielu dyskusjach na WordCampach był to jeden z najczęściej poruszanych tematów. Nie wymyślaj na nowo koła. Używaj WordPressa z całym dobrodziejstwem inwentarza, nie zaś wybiórczo.
Teraz, gdy pluginy są weryfikowane przed dopuszczeniem do repozytorium będzie to konieczność. Nawet jednak, jeżeli piszesz coś tylko na własny użytek – zrób to raz i poprawnie. Założę się, że kiedyś będziesz chciał do tego kodu wrócić, coś zmienić, może zastosować w innym projekcie. Wtedy prawidłowe pisanie na pewno zaprocentuje.
Jeden z najczęściej popełnianych błędów przez developerów przytrafia się przy otwieraniu zdalnych zasobów. Ręka do góry, kto widział (lub popełnił – nie wierzę, że wszyscy zaczynali z wysokim poziomem znajomości API WordPressa) wtyczkę używającą [cci]curl()[/cci] lub nie daj Boże jeszcze[cci]fopen()[/cci] dla zdalnych plików?. A można to zrobić w sposób o wiele prostszy i, co ważne, uniwersalny.
WordPress jest dostarczany ze specjalnie służącą do tego celu klasą [cci]WP_Http[/cci]. Dla wygody użytkowników powstały nawet cztery funkcje, które ułatwiają pobieranie zdalnych plików:
Dlaczego warto?
Po pierwsze – jest łatwiej. Używasz jednej funkcji, która od razu daje Ci dostęp do tego co potrzebujesz. Nie przepisujesz całej sekwencji wywołań CURL, nie tworzysz do tego własnej funkcji. Prosto i do celu.
Po drugie – jest bardziej uniwersalne. Kod WordPressa tworzyli specjaliści, którzy wiedzą, że nie wszystko działa na wszystkich serwerach. Klasa [cci]WP_Http[/cci] jest tak zbudowana, by sprawdzić jakie metody pobierania zdalnych plików są na danym serwerze dostępne, po czym wybiera spośród nich najbezpieczniejszą.
Jak z tych funkcji korzystać?
Składnia wszystkich czterech funkcji jest taka sama. Przyjmują one dwa parametry
[code]wp_remote_request( $url, $args )[/code]
[cci]$url[/cci] jest adresem internetowym zasobu, który chcemy pobrać.
[cci]$args[/cci] to tablica argumentów dla funkcji. Nie musimy jej definiować. Co więcej, jeżeli chcemy jakiś argument zmienić to wystarczy podać (oczywiście w postaci odpowiedniej tablicy) tylko ten argument. Domyślne wartości [cci]$args[/cci] to:
$defaults = array(
'method' => 'GET',
'timeout' => apply_filters( 'http_request_timeout', 5),
'redirection' => apply_filters( 'http_request_redirection_count', 5),
'httpversion' => apply_filters( 'http_request_version', '1.0'),
'user-agent' => apply_filters( 'http_headers_useragent', 'WordPress/' . $wp_version . '; ' . get_bloginfo( 'url' ) ),
'blocking' => true,
'headers' => array(),
'cookies' => array(),
'body' => null,
'compress' => false,
'decompress' => true,
'sslverify' => true,
'stream' => false,
'filename' => null
);
W przypadku [cci]wp_remote_post()[/cci] i [cci]wp_remote_head[/cci] zmienia się tylko parametr [cci]method[/cci].
Znaczenie poszczególnych parametrów:
- [cci]timeout[/cci] – czas na wykonanie (domyślnie 5 sekund). Można ustawić filtr, by zmienić czas domyślny dla wszystkich zapytań.
- [cci]redirection[/cci] – ilość przekierowań, za którymi skrypt może podążyć.
- [cci]blocking[/cci] – zmiana na [cci]false[/cci] umożliwia kontynuowanie wykonywania strony przed zakończeniem pobrania pliku
- [cci]body[/cci] – treść requesta
- [cci]compress[/cci] – zmiana na [cci]true[/cci] pozwala na kompresję requesta
- [cci]decompress[/cci] – wysyła w nagłówkach informację, że jest w stanie zaakceptować skompresowaną odpowiedź oraz dekompresuje ją automatycznie po otrzymaniu
- [cci]sslverify[/cci] – odrzuca połączenia ssl, jeżeli certyfikat witryny nie jest wiarygodny
Na temat [cci]stream[/cci] i [cci]file[/cci] znana mi dokumentacja nie wspomina.
Jak funkcja zwraca wynik?
Nie jest to prosty typ zmiennej lecz tablica lub obiekt klasy [cci]WP_Error[/cci] w przypadku niepowodzenia.
Przykładowa tablica zwracana przez funkcję [cci]wp_remote_get[/cci] wygląda następująco:
Array
(
[headers] => Array
(
[date] => Thu, 30 Sep 2010 15:16:36 GMT
[server] => Apache
[x-powered-by] => PHP/5.3.3
[x-server] => 10.90.6.243
[expires] => Thu, 30 Sep 2010 03:16:36 GMT
[cache-control] => Array
(
[0] => no-store, no-cache, must-revalidate
[1] => post-check=0, pre-check=0
)
[vary] => Accept-Encoding
[content-length] => 1641
[connection] => close
[content-type] => application/php
)
[body] =>This is a website!
[response] => Array
(
[code] => 200
[message] => OK
)
[cookies] => Array
(
)
)
WordPress Codex poleca następujący fragment kodu, aby pobrać treść witryny:
$response = wp_remote_get( $url );
if( is_wp_error( $response ) ) {
$error_message = $response->get_error_message();
echo "Something went wrong: $error_message";
} else {
echo 'Response: <pre>';
print_r( $response );
echo '</pre>';
}
Kiedy nie używać tych funkcji?
Pytanie dość nietypowe, prawda? Otóż tych funkcji należy używać zawsze, gdy pobieramy zewnętrzny plik chyba, że istnieje funkcja bardziej wyspecjalizowana. Funkcją taką może być na przykład [cci]fetch_feed[/cci] służąca do pobierania kanałów RSS.
Jeżeli zdarza nam się często pobierać ten sam plik, warto pomyśleć o mechanizmach cache’owania. Znów – nie piszmy własnych, lecz użyjmy wbudowanych w WordPressa. Jakich? O tym następnym razem.
Podsumowując
Znaj swoje funkcje. Dziś poznałeś [cci]wp_remote_get[/cci] i jej rodzinę. Następnym razem będzie o cache – przykład z życia wzięty.
Aby rozszerzyć swoją wiedzę, warto poświęcać regularnie czas na studiowanie WordPress Codex oraz… źródeł samego WordPressa. Wiele z tych rzeczy nie jest opisanych w dokumentacji, bądź są porozrzucane po różnych miejscach. Szybciej można znaleźć je w samym kodzie. Poza tym zapoznasz się ze specyfiką pisania kodu pod WordPressa oraz pewnymi przyjętymi konwencjami (nowe linie, spacje, wcięcia itp.).
A może znasz jakąś funkcję, o której warto tu napisać. Jeżeli czujesz się na siłach – te łamy są dla Ciebie otwarte. Jeżeli chcesz tylko poruszyć temat – daj znać w komentarzu.
Leave a Reply