12 najgorszych błędów, które popełniają zaawansowani programiści WordPress

WordPress to bardzo popularny sposób na szybkie uruchomienie i uruchomienie witryny. Jednak w pośpiechu wielu programistów podejmuje okropne decyzje. Niektóre błędy, takie jak pozostawienie WP_DEBUG ustawionego na true mogą być łatwe do zrobienia. Inne, takie jak wrzucenie całego kodu JavaScript do jednego pliku, są tak samo powszechne, jak leniwi inżynierowie. Bez względu na to, jaki błąd popełnisz, czytaj dalej, aby poznać 12 najczęstszych błędów WordPressa, które popełniają nowi i doświadczeni programiści. Jeśli popełnisz jeden z tych błędów, nie rozpaczaj. Każdy błąd to okazja do nauki.

1. Umieszczanie kodu JavaScript motywu WordPress w jednym głównym pliku

Kiedyś, robiąc optymalizację szybkości strony dla witryn klienta, zauważyłem, że używa on motywu premium, który zawiera wszystkie używane biblioteki, w tym kod niestandardowy, w jednym pliku o nazwie main.js , theme.js lub custom.js . Ta praktyka jest zła z następujących powodów:

1. Z czasem plik może stać się naprawdę duży, ponieważ motyw, który jest aktywnie rozwijany, będzie miał coraz więcej funkcji, a czasami zobaczysz pliki o rozmiarze do 1 MB. Plik zostanie załadowany w całej witrynie, nawet jeśli na niektórych stronach potrzebne będzie tylko 10% kodu z pliku. Spowoduje to, że pobieranie stron będzie trwać dłużej, a renderowanie wolniejsze, zwłaszcza jeśli jest to kod blokujący renderowanie w sekcji head strony.
2. Utrudnia to zarządzanie kodem wewnątrz pliku, ponieważ nie można używać funkcji takich jak wp_dequeue_script() do wyładowania części kodu na niektórych stronach w celu zwiększenia szybkości strony lub uniknięcia konfliktu z innym kodem JavaScript, który może być załadowany przez jedną z aktywnych wtyczek. Jasne, plik można podzielić na wiele plików i umieścić w kolejce w WordPressie, ale jeśli później administrator witryny zaktualizuje plik main.js motywu, cały proces musi zacząć się od nowa.

2. Używanie nazw, które są zbyt powszechne dla zmiennych, funkcji, stałych lub klas

Podczas tworzenia wtyczki lepiej jest używać konwencji nazewnictwa, która zapobiega konfliktom kodu w przypadku, gdy istnieją inne wtyczki używające tej samej nazwy. Dlatego wielu programistów poprzedza swoje zmienne i nazwy funkcji czymś unikalnym i związanym z samą wtyczką. Oprócz wyeliminowania konfliktu kodu, ułatwia również znalezienie rzeczy, gdy masz włączonych wiele wtyczek.

Z drugiej strony są programiści, którzy wolą używać przestrzeni nazw PHP do enkapsulacji elementów i rozwiązywania dwóch problemów, które napotykają autorzy bibliotek i aplikacji podczas tworzenia elementów kodu wielokrotnego użytku, takich jak klasy lub funkcje:

1. Kolizje nazw między kodem, który tworzą, a wewnętrznym PHP lub klasami, funkcjami lub stałymi innych firm
2. Możliwość aliasowania (lub skracania) Extra_Long_Names w celu rozwiązania pierwszego problemu lub poprawienia czytelności kodu źródłowego. Ten jest moim ulubionym, ponieważ często tworzę motywy lub wtyczki, które mają dużo kodu. Dzięki temu mogę łatwo czytać i zarządzać kodem, nie martwiąc się zbytnio o długie, unikalne nazwy.

Zalecam dobre zrozumienie przestrzeni nazw przed ich użyciem, ponieważ często mogą być używane w niewłaściwy sposób.

W zależności od projektu, który weźmiesz na pokład, prawdopodobnie będziesz musiał trzymać się istniejącego stylu kodowania, chyba że twoja praca jest w większości oddzielona od istniejącego. Jeśli musisz rozszerzyć istniejącą wtyczkę lub motyw, który jest już zgodny ze standardami kodowania PHP dla WordPressa, najlepiej jest trzymać się ich, aby zachować spójny styl, aby kod stał się czysty i łatwy do odczytania. Zwróć uwagę, że niektóre zasady są powszechnie stosowane w celu poprawy wydajności, bez względu na styl kodowania. Na przykład zawsze najlepiej jest używać pojedynczych cudzysłowów (zamiast podwójnych), jeśli nie oceniasz niczego w ciągu. Ponadto kod musi być wcięty, aby można go było odczytać, zwłaszcza jeśli ma zagnieżdżony kod (np. IF s w IF s, zagnieżdżone FOREACH s i FOR s).

3. Niewykorzystywanie istniejącej podstawowej funkcjonalności WordPressa do jej prawdziwego potencjału

Ponieważ WordPress zawiera zestaw regularnie aktualizowanych bibliotek, które można po prostu wywołać w naszych wtyczkach i motywach, najlepiej jest po prostu wykorzystać w jak największym stopniu istniejącą podstawową funkcjonalność. Widziałem motywy i wtyczki WordPress, które miały w katalogu zasobów pliki, które znajdowały się już w podstawowych plikach WordPress (np. jQuery lub Color Picker). Oprócz tego, że pakiet będzie się powiększał i ładowanie przez sieć będzie trwało dłużej, musisz również upewnić się, że wszystkie biblioteki innych firm są regularnie aktualizowane, co jest kolejną rzeczą, o którą należy zadbać.

Wykorzystaj to, co WordPress ma już do zaoferowania, ponieważ biblioteki są już aktualizowane przez zespół programistów WordPress i możesz mieć lekki i łatwiejszy w utrzymaniu projekt. Regularnie aktualizując WordPress, zyskujesz dostęp do większej liczby funkcji (niezależnie od tego, czy jest to wtyczka, motyw, czy sam rdzeń WordPressa, ponieważ jego Dashboard jest stale ulepszany) i zwiększasz bezpieczeństwo witryny w przypadku wykrycia luk w starych wersjach kodu.

4. Nie ułatwianie zmiany wtyczki lub motywu za pomocą akcji i filtrów

Bezpośrednia edycja wtyczki lub motywu WordPress jest złym pomysłem, chyba że jesteś bezpośrednio zaangażowany w rozwój tego pakietu i przyczyniasz się do jego kodu. Jeśli zostanie wykonana automatyczna aktualizacja wtyczki lub motywu, wszelkie bezpośrednie zmiany w pakiecie zostaną utracone i będziesz musiał ponownie edytować pliki.

Dlatego używanie akcji i filtrów, a także tworzenie motywu potomnego (który rozszerza motyw nadrzędny) są najskuteczniejszymi podejściami do modyfikowania motywu, ponieważ możesz zmienić istniejącą funkcjonalność bez edytowania motywu nadrzędnego lub samej wtyczki. Ponadto, jeśli oferujesz wtyczkę do bezpłatnego pobrania na WordPress.org, a później chcesz stworzyć rozszerzenie premium, które będzie zależne od wtyczki nadrzędnej, powinieneś opracować darmową wtyczkę w taki sposób, aby była łatwo rozszerzać i dodawać rozszerzenia premium.

5. Programowanie z WP_DEBUG Ustaw na false

Domyślnie stała WP_DEBUG jest ustawiona na 'false', aby uniknąć drukowania błędów PHP, ostrzeżeń i powiadomień. W środowisku na żywo jest to zalecany wybór, ponieważ utrzymuje prywatne ścieżki serwera i skrypty ukryte przed widokiem publicznym, co jest świetne ze względów bezpieczeństwa. Jednak na etapie rozwoju najlepiej ustawić ją na „true”, ponieważ powiadomi nas o wszelkich błędach w naszym kodzie. Nawet jeśli błędy nie wpływają bezpośrednio na funkcjonalność, często zmuszają Cię do pisania lepszego kodu i rozwijania lepszych nawyków związanych z kodowaniem. Zdarzyło mi się. Zapewni to również, że rozwijana wtyczka lub motyw nie generuje błędów PHP w żadnej instalacji WordPressa.

Chociaż jest to coś, co robią najbardziej doświadczeni programiści, zdarza się to, zwłaszcza w pośpiechu. Bez względu na to, jak pilna jest ta praca, programiści powinni zawsze starać się zachować standardy kodowania WordPress, z oczywistym uwzględnieniem najlepszych praktyk PHP.

6. Pisanie kodu PHP bez uwzględnienia tego, że strona może zostać zbuforowana pewnego dnia

Jest to częsty błąd PHP i, podobnie jak poprzedni, stosunkowo łatwo go uniknąć, jeśli trzymasz się standardów kodowania PHP.

Niektórzy programiści mają zwyczaj implementowania fragmentów PHP do motywów i wtyczek, które są poprawne tylko wtedy, gdy kod PHP jest uruchamiany przez cały czas. Na przykład, funkcja PHP, która odpowiada agentowi użytkownika HTTP za pomocą pewnych działań, powinna zostać wykonana lub nie (np. kolejkowanie skryptów, które są przeznaczone tylko dla użytkowników mobilnych).

Jeśli twój klient zainstaluje wtyczkę, która buforuje stronę (np. W3 Total Cache lub WP Rocket) bez wyzwalania warunków w twoim motywie lub wtyczkach, twój kod PHP stanie się bezużyteczny. Jeśli intencją jest, aby strony były responsywne, należy to zrobić po stronie front-endu za pomocą zapytań o media i JavaScript. Ten ostatni tylko wtedy, gdy jest to naprawdę konieczne. Najlepiej byłoby uniknąć używania JavaScriptu, aby Twoja witryna była responsywna.

7. Brak śledzenia zmian dokonanych w profesjonalny sposób przez system kontroli wersji, taki jak Git

Pliki, które są zakodowane w sposób niestandardowy, takie jak motyw podrzędny lub niestandardowa wtyczka, powinny w idealnym przypadku podlegać kontroli wersji. Git tworzy rejestr zmian i umożliwia programistom współpracę nad tym samym projektem WordPress lub łatwe przywracanie poprzedniej wersji, gdy coś pójdzie nie tak ze stroną internetową. Co więcej, klienci mogą używać Git do śledzenia całej historii pracy wykonanej przez wszystkich programistów zatrudnionych do tego konkretnego projektu, zwłaszcza jeśli była to duża, długoterminowa niestandardowa witryna WordPress.

Chociaż na początku może to być onieśmielające, zwłaszcza dla młodszych programistów, zrozumienie Git będzie warte czasu, a oprogramowanie z interfejsem graficznym Git, takie jak SourceTree (jeden z moich ulubionych), będzie po prostu sposobem interakcji z repozytoriami Git, dzięki czemu całość krzywa uczenia się przyjemniejsza. Gdy już zrozumiesz, jak to działa, rozważ zapoznanie się z najlepszymi praktykami i wskazówkami w serwisie Git autorstwa Toptal Developers, które szczegółowo wyjaśniają kilka sposobów korzystania z usługi Git.

8. Kolejkowanie plików CSS i JavaScript, gdy nie są potrzebne

Posiadanie wielu żądań HTTP spowolniłoby ładowanie strony internetowej, a tym samym miałoby niższy wynik w Google PageSpeed, co prawdopodobnie wpłynęłoby na ranking wyszukiwania. Może to również prowadzić do błędów JavaScript z powodu konfliktów między wtyczkami. Na przykład mogą istnieć dwie wtyczki korzystające ze wspólnej biblioteki jQuery, które mogą być ładowane dwukrotnie i mogą powodować problemy. I naprawdę jest to najlepszy przykład, ponieważ jQuery jest bardzo często wielokrotnie ładowane na aktywnych stronach internetowych. Dzieje się tak prawdopodobnie z powodu źle napisanych wtyczek lub motywów.

9. Używanie plików .php do wyprowadzania kodu CSS lub JavaScript zamiast statycznych plików .css i .js

Widziałem motywy, a nawet wtyczki WordPress, które zawierały pliki takie jak style.php , które były używane tylko do generowania niestandardowego kodu CSS i drukowania go. Rzeczy takie jak kolory, rozmiary czcionek i odstępy wokół elementów zostały ustawione w ustawieniach motywu, a następnie zapisane w bazie danych. Następnie style.php jest odczytywany (np. <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) i generuje kod CSS na podstawie niestandardowych ustawień, które zostały zaktualizowane w desce rozdzielczej.

To naprawdę zła praktyka pod względem wydajności WordPressa. Oto główne wady, które się z tym wiążą:

1. Ponieważ plik CSS ładuje się w tagu head (co jest normalne i większość z nich ładuje się w ten sposób), pojawia się problem z wydajnością, ponieważ przeglądarka musi całkowicie pobrać plik przed renderowaniem strony. Jeśli środowisko WordPress działa wolno z powodu niektórych wtyczek, znacznie opóźni to czas ładowania. Nawet jeśli używane są techniki buforowania lub tylko część środowiska WordPress jest ładowana w celu pobrania wartości z bazy danych. Najlepiej zamiast tego użyć statycznego pliku .css.
2. W pliku PHP kod (reguły CSS zmieszane ze zmiennymi PHP i klauzulami warunkowymi) będzie trudniejszy do odczytania przez programistów, gdy będą musieli coś sprawdzić. Jasne, plik można uruchomić w przeglądarce (chociaż jestem pewien, że kiedy zostanie wydrukowany, nie będzie nawet wcięty ani ładnie wyglądający), ale jeśli masz lokalną kopię projektu i przeglądasz kod motywu i potrzebujesz znalezienie składni CSS lub JavaScript (w przypadku użycia script.php), utrudniłoby to czytelność.

Rozwiązanie: Zapisz dowolny niestandardowy CSS poza katalogiem wtyczek. Przykład: /wp-content/uploads/theme-name-custom-css/style-5.css . W ten sposób, w przypadku aktualizacji motywu lub wtyczki, niestandardowy plik nie zostanie utracony.

10. Nieużywanie odpowiedniej architektury (organizacja kodu) dla wtyczek i motywów WordPress

W zależności od rozmiaru i charakteru wtyczki (np. samodzielna wtyczka lub rozszerzenie wtyczki, które działa tylko wtedy, gdy aktywowana jest główna wtyczka, taka jak WooCommerce), należy skonfigurować odpowiednią architekturę i organizację kodu.

Jeśli musisz zbudować jednofunkcyjną wtyczkę WordPress dla klienta i ma ona ograniczoną interakcję z rdzeniem WordPress, motywami i innymi wtyczkami, tworzenie złożonych klas nie jest skuteczne, chyba że masz pewność, że wtyczka rozszerzy się znacznie później na.

Jeśli wtyczka ma być bogata w dużo kodu, to użycie podejścia do kodowania zorientowanego obiektowo (OOP) (mające wiele klas) miałoby sens. Na przykład, jeśli masz wiele skrótów, możesz je wszystkie przechowywać w osobnym pliku klasy, takim jak class.shortcodes.php lub jeśli istnieją pliki CSS i JavaScript, które mają być ładowane w widoku pulpitu nawigacyjnego i frontonu następnie można użyć jednej klasy, takiej jak class.scripts.php i umieścić w kolejce pliki frontonu w metodzie takiej jak enqueue_public_scripts() podczas umieszczania w kolejce plików przeznaczonych do załadowania w obszarze administracyjnym w enqueue_admin_scripts() .

Zamiast mieszać kod HTML z kodem PHP, lepiej jest go odseparować, implementując wzorzec MVC do wtyczek i motywów. Dobrym przykładem jest wtyczka WooCommerce. Zawiera szablony dla różnych układów, które można również łatwo nadpisać za pomocą motywu lub różnych filtrów, tylko dlatego, że logika jest oddzielona od projektu. Szablon zawierający układ HTML służy głównie do drukowania już przetworzonych informacji. Posiadanie kodu HTML w metodach PHP jest zwykle złą praktyką (istnieją oczywiście wyjątki dla małych fragmentów kodu HTML), zwłaszcza w przypadku wtyczki, która jest utrzymywana przez więcej niż jednego programistę w miarę wzrostu rozmiaru.

Zgodnie z podręcznikiem WordPress Plugin Handbook, chociaż istnieje wiele możliwych wzorców architektury, można je ogólnie podzielić na trzy odmiany:

• Pojedynczy plik wtyczki zawierający funkcje
• Pojedynczy plik wtyczki, zawierający klasę, skonkretyzowany obiekt i opcjonalnie funkcje
• Główny plik wtyczki, a następnie jeden lub więcej plików klas

11. Nie traktuj poważnie bezpieczeństwa WordPress podczas pisania kodu

Bezpieczeństwo często nie jest traktowane poważnie w programowaniu WordPress, ponieważ wielu początkujących programistów koncentruje się bardziej na wynikach, których oczekuje klient. Wszystko jest w porządku, dopóki witryna klienta nie zostanie zhakowana lub Twoja wtyczka opublikowana na WordPress.org nie będzie miała luki, przez co dotknięte zostaną tysiące witryn. Takie rzeczy zdarzają się czasami i nawet rdzeń WordPressa radził sobie z dużą liczbą luk w zabezpieczeniach od początków CMS. Naszym obowiązkiem jest uczynienie go tak bezpiecznym, jak to tylko możliwe, a na wypadek, gdyby coś się stało, działać szybko i upewnić się, że wydamy solidną, dobrze przetestowaną łatkę.

Oto niektóre z najważniejszych wskazówek dotyczących bezpieczeństwa:

Luki XSS: Aby tego uniknąć, należy zrobić dwie rzeczy: oczyścić dane wejściowe i dane wyjściowe. W zależności od danych i kontekstu, w którym jest używany, w WordPressie istnieje kilka metod oczyszczania kodu. Nie należy ufać żadnym danym wejściowym ani danym, które mają zostać wydrukowane. Jedną z typowych funkcji oczyszczania wprowadzania danych jest sanitize_text_field() . Sprawdza nieprawidłowe znaki UTF-8, konwertuje pojedyncze znaki < na elementy HTML, usuwa wszystkie znaczniki, usuwa podziały wierszy, tabulatory oraz dodatkowe spacje i oktety usuwania. Jeśli chodzi o drukowanie danych, dobrym przykładem wyprowadzania linków jest funkcja esc_url() , która odrzuca nieprawidłowe adresy URL, eliminuje nieprawidłowe znaki i usuwa niebezpieczne znaki.

Zapobiegaj bezpośredniemu dostępowi do plików: Dostęp do plików można uzyskać bezpośrednio, ponieważ pozwala na to większość hostów. Jeśli jednak tak się stanie, a kod nie zostanie odpowiednio napisany, aby sobie z tym poradzić, mogą zostać wydrukowane niektóre błędy (np. brakujące funkcje lub zmienne, które nie są zadeklarowane), które będą zawierać informacje cenne dla potencjalnych napastników. Jednym z typowych fragmentów kodu, które często widzisz we wtyczkach i motywach, jest:

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Jeśli stała ABSPATH nie jest zdefiniowana (co powinno dotyczyć każdej instalacji WordPress), skrypt zakończy działanie i nic nie wydrukuje.

Użyj nonce: Jak stwierdzono w dokumentacji WordPress, numer jednorazowy to „liczba użyta raz”, aby chronić adresy URL i formularze przed niektórymi rodzajami niewłaściwego użycia, złośliwego lub innego.

Na przykład następujący adres URL w panelu zostanie użyty do usunięcia posta: http://example.com/wp-admin/post.php?post=123&action=trash — podczas uzyskiwania dostępu do tego adresu URL, WordPress zweryfikuje informacje z pliku cookie uwierzytelniania a jeśli masz odpowiednie uprawnienia (np. jesteś administratorem ze wszystkimi uprawnieniami), post zostanie usunięty.

Atakujący może zrobić, aby przeglądarka uzyskała dostęp do tego adresu URL bez Twojej wiedzy, tworząc link na stronie innej firmy, jak w poniższym przykładzie: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> Podczas wysyłania tego żądania do WordPress przeglądarka automatycznie dołączy plik cookie uwierzytelniania, a WordPress uzna żądanie za prawidłowe.

Wtedy pojawia się wartość jednorazowa, ponieważ atakujący nie będzie w stanie tak łatwo uzyskać wartości jednorazowej (wygenerowanej dla administratora, który jest faktycznie zalogowany do WordPressa). Nowy adres URL żądania będzie wyglądał tak: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

Bez ważnego numeru jednorazowego do przeglądarki zostanie wysłana odpowiedź 403 Forbidden z dobrze znanym komunikatem o błędzie: „Czy na pewno chcesz to zrobić?”

Chociaż większość ludzi nie traktuje poważnie bezpieczeństwa WordPress, myśląc, że ich witryna nigdy nie zostanie zhakowana, ufając hostingowi (co może być pomocne, ale tylko do pewnego momentu) oraz fakt, że kupili komercyjne wtyczki/motywy (co często prowadzi zakładając, że są one bardzo bezpieczne), powinniśmy zawsze przeprowadzać testy penetracyjne dla naszych stron internetowych, aby zidentyfikować możliwe do wykorzystania luki, zanim jakikolwiek haker będzie w stanie je zidentyfikować i wykorzystać.

Zwróć uwagę, że duża liczba włamań nie jest wykonywana nawet przez jedną osobę z zamiarem zhakowania Twojej witryny. Często zdarzają się boty, które automatycznie i regularnie skanują witryny WordPress i w momencie wykrycia znanej luki w zabezpieczeniach jest ona wykorzystywana, a serwer wykorzystywany do spamowania, pozyskiwania prywatnych informacji z bazy danych, umieszczania ukrytych linków na niektórych stronach witryny, które prowadziłoby do wszelkiego rodzaju podejrzanych witryn internetowych (np. pornografii, nielegalnych narkotyków). Czasami hacki są tak dobrze ukryte, że potrzebujesz odpowiedniego przeskanowania swojej witryny i zobaczenia daty aktualizacji określonych plików w celu wykrycia zhakowanego kodu. Dlatego dobrze jest nawet ponownie zainstalować WordPress (tak, ta sama wersja, jeśli masz ostatnią), aby wszelkie zhakowane pliki zostały zastąpione oryginalnymi plikami rdzenia WordPress.

12. Korzystanie z funkcji WordPress i fragmentów kodu bez ich zrozumienia

Często, gdy programiści utknęli i znajdują rozwiązanie w miejscach takich jak StackOverflow, są po prostu zadowoleni z faktu, że udało im się coś zrobić bez zawracania sobie głowy zrozumieniem logiki stojącej za tym kodem lub jeśli ten kod można zmienić, aby ładować się szybciej lub mieć mniej wierszy kodu.

Widziałem tę praktykę wiele razy, kiedy fragmenty kodu są kopiowane w skryptach PHP, gdy tylko jedna trzecia tego kodu jest faktycznie używana.

Może to mieć kilka wad, w tym:

1. Kod nie używa tego samego stylu, co istniejący kod projektu. Tak, wygodnie jest po prostu skopiować i wkleić fragmenty, które działają po wyjęciu z pudełka i chociaż są w porządku w przypadku małego osobistego projektu (ktoś może przekształcić się w duży projekt, kto wie), ta praktyka często nie jest dobra, jeśli chodzi o do pracy komercyjnej, w której należy zachować spójność stylu.
2. Chociaż kod spełnia swoje zadanie, może zawierać nieefektywne funkcje, które nie są zalecane do zadania, które ma zostać zrealizowane. Jeśli kod nie jest zoptymalizowany, ta praktyka „kopiuj i wklej” może prowadzić do powolnego i trudniejszego w utrzymaniu witryny, zwłaszcza jeśli w różnych lokalizacjach w projekcie używany jest więcej niż jeden fragment kodu.
3. Kod może nie być licencjonowany do ponownego wykorzystania, a włączenie kodu do projektu klienta może narazić go na wiele problemów prawnych.

Ciągłe doskonalenie

Każdy popełnia błędy, a każdy błąd jest okazją do doskonalenia się. Jako programiści WordPress, nasza branża rozwija się w bardzo szybkim tempie i nigdy nie ma jednego „właściwego sposobu” robienia rzeczy. Jednak im więcej ćwiczysz i uczysz się, tym lepszym się staniesz.

Czy nie zgadzasz się z którymkolwiek ze wskazanych przeze mnie błędów, czy też uważasz, że jeden z nich pominąłem? Dajcie znać w komentarzach i porozmawiamy.