10 najczęstszych błędów popełnianych przez programistów WordPressa

Jesteśmy tylko ludźmi, a jedną z cech bycia człowiekiem jest popełnianie błędów. Z drugiej strony, sami się poprawiamy, co oznacza, że ​​mamy tendencję do uczenia się na własnych błędach i miejmy nadzieję, że dzięki temu jesteśmy w stanie uniknąć dwukrotnego popełniania tych samych. Wiele błędów, które popełniłem w świecie WordPressa, wynika z chęci zaoszczędzenia czasu podczas wdrażania rozwiązań. Jednak zazwyczaj odwracają głowy w dół, gdy w wyniku takiego podejścia pojawiają się problemy. Popełnianie błędów jest nieuniknione. Jednak uczenie się na podstawie niedopatrzeń innych ludzi (i oczywiście własnego!) jest drogą, którą powinieneś aktywnie obrać.

Powszechny błąd nr 1: Wyłączanie debugowania

Dlaczego powinienem używać debugowania, gdy mój kod działa poprawnie? Debugowanie to funkcja wbudowana w WordPress, która powoduje wyświetlanie wszystkich błędów PHP, ostrzeżeń i powiadomień (o przestarzałych funkcjach itp.). Gdy debugowanie jest wyłączone, mogą być generowane ważne ostrzeżenia lub powiadomienia, których nigdy nie widzimy, ale które mogą powodować problemy później, jeśli nie zajmiemy się nimi na czas. Chcemy, aby nasz kod ładnie współgrał z wszystkimi innymi elementami naszej strony. Tak więc, dodając nowy niestandardowy kod do WordPressa, powinieneś zawsze wykonywać prace programistyczne z włączonym debugowaniem (ale pamiętaj, aby je wyłączyć przed wdrożeniem witryny do produkcji!).

Aby włączyć tę funkcję, musisz edytować plik wp-config.php w katalogu głównym instalacji WordPress. Oto fragment typowego pliku:

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

Nie jest to wyczerpująca lista opcji konfiguracyjnych, których można użyć, ale ta sugerowana konfiguracja powinna wystarczyć do większości potrzeb związanych z debugowaniem.

Powszechny błąd nr 2: Dodawanie skryptów i stylów za pomocą wp_head Hook

Co jest złego w dodawaniu skryptów do szablonu nagłówka? WordPress zawiera już mnóstwo popularnych skryptów. Mimo to wielu programistów doda dodatkowe skrypty za pomocą haka wp_head . Może to spowodować wielokrotne ładowanie tego samego skryptu, ale w innej wersji.

Z pomocą przychodzi tu kolejkowanie, które jest przyjaznym dla WordPressa sposobem dodawania skryptów i stylów do naszej strony. Używamy kolejkowania, aby zapobiegać konfliktom wtyczek i obsługiwać wszelkie zależności, jakie może mieć skrypt. Osiąga się to za pomocą wbudowanych funkcji wp_enqueue_script lub wp_enqueue_style do umieszczania w kolejce odpowiednio skryptów i stylów. Główna różnica między tymi dwiema funkcjami polega na tym, że przy wp_enqueue_script mamy dodatkowy parametr, który pozwala przenieść skrypt do stopki strony.

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

Jeśli skrypt nie jest wymagany do renderowania treści w części strony widocznej na ekranie, możemy bezpiecznie przenieść go do stopki, aby zapewnić szybkie wczytanie treści w części strony widocznej na ekranie. Dobrą praktyką jest zarejestrowanie skryptu przed umieszczeniem go w kolejce, ponieważ umożliwia to innym wyrejestrowanie skryptu za pomocą uchwytu we własnych wtyczkach, bez modyfikowania podstawowego kodu wtyczki. Dodatkowo, jeśli uchwyt zarejestrowanego skryptu jest wymieniony w tablicy zależności innego skryptu, który został umieszczony w kolejce, skrypt ten zostanie automatycznie załadowany przed załadowaniem podświetlonego skryptu umieszczonego w kolejce.

Powszechny błąd nr 3: Unikanie motywów potomnych i modyfikowanie podstawowych plików WordPress

Zawsze twórz motyw potomny, jeśli planujesz modyfikować motyw. Niektórzy programiści wprowadzają zmiany w plikach motywu nadrzędnego tylko po to, aby po uaktualnieniu do motywu odkryć, że ich zmiany zostały nadpisane i utracone na zawsze.

Aby utworzyć motyw potomny, umieść plik style.css w podkatalogu folderu motywu potomnego z następującą zawartością:

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

Powyższy przykład tworzy motyw potomny oparty na domyślnym motywie WordPress, Twenty Sixteen . Najważniejszym wierszem tego kodu jest ten zawierający słowo „Szablon”, które musi odpowiadać nazwie katalogu motywu nadrzędnego, z którego klonujesz potomka.

Te same zasady dotyczą plików podstawowych WordPressa: nie wybieraj łatwej drogi, modyfikując pliki podstawowe. Włóż dodatkowy wysiłek, korzystając z funkcji i filtrów, które można podłączyć do WordPressa, aby zapobiec nadpisaniu zmian po aktualizacji WordPress. Funkcje wtykowe pozwalają zastąpić niektóre podstawowe funkcje, ale ta metoda jest powoli wycofywana i zastępowana filtrami. Filtry osiągają ten sam efekt końcowy i są wstawiane na końcu funkcji WordPress, aby umożliwić modyfikację ich wyników. Sztuczka polega na tym, aby zawsze owijać swoje funkcje za pomocą if ( !function_exists() ) podczas korzystania z funkcji wtyczek, ponieważ wiele wtyczek próbujących przesłonić tę samą wtykową funkcję bez tego opakowania spowoduje błąd krytyczny.

Powszechny błąd nr 4: Wartości kodowania sztywno

Często wydaje się, że szybsze jest zakodowanie wartości (takiej jak adres URL) gdzieś w kodzie, ale czas poświęcony na debugowanie i rozwiązywanie problemów, które powstają w wyniku tego, jest znacznie dłuższy. Używając odpowiedniej funkcji do dynamicznego generowania żądanych danych wyjściowych, znacznie upraszczamy późniejszą konserwację i debugowanie naszego kodu. Na przykład, jeśli migrujesz swoją witrynę ze środowiska testowego do produkcyjnego z zakodowanymi na stałe adresami URL, nagle zauważysz, że Twoja witryna nie działa. Dlatego powinniśmy używać funkcji, takich jak ta wymieniona poniżej, do generowania ścieżek plików i linków:

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

Innym złym przykładem hardcodingu jest pisanie niestandardowych zapytań. Na przykład, jako środek bezpieczeństwa, zmieniamy domyślny prefiks datatable WordPress z wp_ na coś bardziej unikalnego, jak wp743_ . Nasze zapytania zakończą się niepowodzeniem, jeśli kiedykolwiek przeniesiemy instalację WordPressa, ponieważ prefiksy tabel mogą się zmieniać między środowiskami. Aby temu zapobiec, możemy odwołać się do właściwości tabeli klasy wpdb :

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

Zauważ, że nie używam wartości wp_users jako nazwy tabeli, ale zamiast tego pozwalam WordPressowi to rozwiązać. Użycie tych właściwości do generowania nazw tabel pomoże zapewnić, że zwracamy poprawne wyniki.

Częsty błąd nr 5: Nie powstrzymywanie witryny przed indeksowaniem

Dlaczego nie miałbym chcieć, aby wyszukiwarki indeksowały moją witrynę? Indeksowanie jest dobre, prawda? Cóż, tworząc witrynę internetową, nie chcesz, aby wyszukiwarki indeksowały Twoją witrynę, dopóki nie skończysz jej budować i nie ustanowisz struktury permalinków. Co więcej, jeśli masz serwer pomostowy, na którym testujesz aktualizacje witryny, nie chcesz, aby wyszukiwarki takie jak Google indeksowały te zduplikowane strony. Gdy istnieje wiele fragmentów nieodróżnialnej treści, wyszukiwarkom trudno jest zdecydować, która wersja jest bardziej odpowiednia dla wyszukiwanego hasła. Wyszukiwarki w takich przypadkach będą karać witryny ze zduplikowaną treścią, a Twoja witryna ucierpi w wyniku tego w rankingu wyszukiwania.

Jak pokazano poniżej, w ustawieniach czytania WordPressa znajduje się pole wyboru „Zniechęcaj wyszukiwarki do indeksowania tej witryny”, chociaż pod spodem znajduje się ważna uwaga: „Od wyszukiwarek zależy, czy uszanują tę prośbę”.

Pamiętaj, że wyszukiwarki często nie uwzględniają tego żądania. Dlatego, jeśli chcesz niezawodnie uniemożliwić wyszukiwarkom indeksowanie Twojej witryny, edytuj plik .htaccess i wstaw następujący wiersz:

 Header set X-Robots-Tag "noindex, nofollow"

Częsty błąd nr 6: niesprawdzanie, czy wtyczka jest aktywna

Dlaczego powinienem sprawdzać, czy funkcja wtyczki istnieje, jeśli moja wtyczka jest zawsze włączona? Na pewno przez 99% czasu Twoja wtyczka będzie aktywna. A co z tym 1% przypadków, gdy z jakiegoś powodu został dezaktywowany? Jeśli i kiedy to nastąpi, Twoja witryna prawdopodobnie wyświetli brzydkie błędy PHP. Aby temu zapobiec, możemy sprawdzić, czy wtyczka jest aktywna, zanim wywołamy jej funkcje. Jeśli funkcja wtyczki jest wywoływana przez interfejs, musimy dołączyć bibliotekę plugin.php , aby wywołać funkcję is_plugin_active() :

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

Ta technika jest zwykle dość niezawodna. Mogą jednak wystąpić sytuacje, w których autor zmienił nazwę głównego katalogu wtyczek. Bardziej niezawodną metodą byłoby sprawdzenie istnienia klasy we wtyczce:

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

Autorzy są mniej skłonni do zmiany nazwy klasy wtyczki, więc generalnie polecam korzystanie z tej metody.

Powszechny błąd nr 7: Ładowanie zbyt wielu zasobów

Dlaczego powinniśmy być selektywni w ładowaniu zasobów wtyczek dla stron? Nie ma uzasadnionego powodu, aby ładować style i skrypty dla wtyczki, jeśli ta wtyczka nie jest używana na stronie, do której przeszedł użytkownik. Ładując pliki wtyczek tylko wtedy, gdy jest to konieczne, możemy skrócić czas ładowania naszej strony, co spowoduje lepsze wrażenia użytkownika końcowego. Weźmy na przykład witrynę WooCommerce, w której chcemy, aby wtyczka była ładowana tylko na naszych stronach zakupów. W takim przypadku możemy selektywnie usunąć wszelkie pliki z załadowania na wszystkich innych stronach witryn, aby zmniejszyć wzdęcia. Do motywu lub pliku functions.php wtyczki możemy dodać następujący kod:

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

Skrypty można usunąć za pomocą funkcji wp_dequeue_script($handle) poprzez uchwyt, za pomocą którego zostały zarejestrowane. Podobnie, wp_dequeue_style($handle) zapobiegnie załadowaniu arkuszy stylów. Jeśli jednak jest to zbyt trudne do zaimplementowania, możesz zainstalować Organizer wtyczek, który umożliwia selektywne ładowanie wtyczek na podstawie określonych kryteriów, takich jak typ posta lub nazwa strony. Dobrym pomysłem jest wyłączenie wszelkich wtyczek pamięci podręcznej, takich jak W3Cache, które mogłeś włączyć, aby zapobiec konieczności ciągłego odświeżania pamięci podręcznej w celu odzwierciedlenia wprowadzonych zmian.

Częsty błąd nr 8: Utrzymywanie paska administratora

Czy nie mogę po prostu pozostawić paska administracyjnego WordPressa widocznym dla wszystkich? Cóż, tak, możesz zezwolić swoim użytkownikom na dostęp do stron administracyjnych. Jednak te strony bardzo często nie integrują się wizualnie z wybranym motywem i nie zapewniają bezproblemowej integracji. Jeśli chcesz, aby Twoja witryna wyglądała profesjonalnie, wyłącz pasek administracyjny i udostępnij własną stronę zarządzania kontem front-end:

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

Powyższy kod, po skopiowaniu do pliku functions.php motywu, wyświetli pasek administracyjny tylko dla administratorów witryny. Możesz dodać dowolne role lub możliwości użytkownika WordPress do funkcji current_user_can($capability) , aby uniemożliwić użytkownikom wyświetlanie paska administratora.

Powszechny błąd nr 9: nieużywanie filtra GetText

Mogę użyć CSS lub JavaScript do zmiany etykiety przycisku, co w tym złego? No tak, możesz. Jednak dodajesz zbędny kod i dodatkowy czas na renderowanie przycisku, podczas gdy możesz zamiast tego użyć jednego z najprzydatniejszych filtrów w WordPressie, zwanego gettext . W połączeniu z textdomain wtyczki, unikalnym identyfikatorem, który zapewnia WordPressowi rozróżnianie wszystkich załadowanych tłumaczeń, możemy zastosować filtr gettext , aby zmodyfikować tekst przed wyrenderowaniem strony. Jeśli przeszukasz kod źródłowy funkcji load_plugin_textdomain($domain) , otrzymasz nazwę domeny, której potrzebujemy, aby zastąpić dany tekst. Każda renomowana wtyczka zapewni, że textdomain dla wtyczki zostanie ustawiona podczas inicjalizacji wtyczki. Jeśli chcesz zmienić tekst w motywie, wyszukaj wiersz kodu load_theme_textdomain($domain) . Używając ponownie WooCommerce jako przykładu, możemy zmienić tekst, który pojawia się w nagłówku „Produkty powiązane”. Wstaw następujący kod do pliku functions.php motywu:

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

Ten zaczep filtra jest stosowany do przetłumaczonego tekstu przez funkcje internacjonalizacji __() i _e() , o ile textdomain jest ustawiona za pomocą wyżej wymienionych funkcji.

 _e( 'Related Products', 'woocommerce' );

Przeszukaj swoje wtyczki pod kątem tych funkcji internacjonalizacji, aby zobaczyć, jakie inne ciągi możesz dostosować.

Częsty błąd nr 10: Zachowanie domyślnych permalinków

Domyślnie WordPress używa ciągu zapytania z identyfikatorem wpisu, aby zwrócić określoną treść. Jednak nie jest to przyjazne dla użytkownika i użytkownicy mogą usuwać odpowiednie części adresu URL podczas jego kopiowania. Co ważniejsze, te domyślne permalinki nie używają struktury przyjaznej dla wyszukiwarek. Włączenie tego, co nazywamy „ładnymi” permalinkami, zapewni, że nasze adresy URL będą zawierać odpowiednie słowa kluczowe z tytułu posta, aby poprawić wydajność w rankingach wyszukiwarek. Zmiana permalinków z mocą wsteczną może być dość zniechęcającym zadaniem, zwłaszcza jeśli Twoja witryna działa przez dłuższy czas, a wyszukiwarki mają już zaindeksowane setki postów. Więc po zainstalowaniu WordPressa upewnij się, że szybko zmienisz strukturę permalinków na coś bardziej przyjaznego dla wyszukiwarek niż tylko identyfikator posta. Generalnie używam nazwy posta w większości witryn, które tworzę, ale możesz dostosować permalink do dowolnego formatu, korzystając z dostępnych tagów struktury permalink.

Wniosek

Ten artykuł w żadnym wypadku nie jest wyczerpującą listą błędów popełnianych przez programistów WordPressa. Jeśli jest jedna rzecz, którą powinieneś wynieść z tego artykułu, to to, że nigdy nie powinieneś iść na skróty (i jest to prawdą na każdej platformie programistycznej, nie tylko w WordPressie!). Czas zaoszczędzony teraz przez złe praktyki programistyczne wróci, by cię prześladować później. Podziel się z nami błędami, które popełniłeś w przeszłości – a co ważniejsze, wszelkimi wyciągniętymi lekcjami – zostawiając komentarz poniżej.