Moje pięć najgorszych błędów w programowaniu WordPress

Albo do wszystkich serwerów, na których wcześniej tankowałem: horror z przerażeniem na pięć najgorszych błędów WordPressa, jakie popełniłem

Jako programiści popełniamy różnego rodzaju błędy na różnych etapach naszej kariery. Zwłaszcza w rozwoju WordPressa popełniamy różnego rodzaju błędy, ponieważ nasza znajomość kodu WordPressa rośnie.

Kilka lat temu słyszałem, jak Matt Mullenweg oświadczył, że większość ludzi powtarza swoje błędy, mądrzejsi ludzie uczą się na swoich błędach, a najmądrzejsi z nas uczą się na błędach innych. Podoba mi się to, do czego dodam: każdy popełnia błędy, ludzie pokorni dzielą się tymi błędami na osobności, a najodważniejsi z nas zapisują je i publikują na blogu!

Ale na rozmyślania przyjdzie czas później. Czytasz ten artykuł, ponieważ chcesz usłyszeć o wypadku kolejowym, a ja jestem inżynierem. Bez dalszych wstępów dołącz do mnie, aby spojrzeć wstecz z przerażeniem na pięć najbardziej wstydliwych błędów, które popełniłem jako programista WordPress.

Czas, w którym zaktualizowałem zhakowaną wersję rdzenia WordPressa

Właśnie kończyłem od robienia bardzo mało znanych koncertów kodowania CraigsList, do rzeczywistej pracy w prawdziwej agencji na żywo. Przybyłem! Byłem zdenerwowany pracą z innego miejsca niż kanapa, w czymś innym niż piżama. Ale nawet wtedy ogólnie znałem WordPressa prosto z WordPressa Robi to źle i uważałem, że chwalenie się najlepszymi praktykami WordPressa, takimi jak „hakowanie rdzenia”, było dla mnie przyjemne.

Moim pierwszym zadaniem programistycznym dla WordPressa w tej agencji było wznowienie wstrzymanego projektu – dość złożonego jak na moje umiejętności w tamtym czasie. Wymagało to wielu dostosowań w procesie rejestracji i logowania WordPress. Poprzedni programista podobno osiągnął znaczny postęp, po prostu edytując podstawowe pliki wp-login .

Wiedziałem, że jest to nie do utrzymania, więc moim pierwszym zadaniem było zainstalowanie wtyczki do tworzenia kopii zapasowych/przywracania i zastąpienie rdzenia WordPress świeżo pobraną wersją. Byłem przekonany, że do tej pory w projekcie nie wykonano nic szczególnie imponującego i że będę w stanie naśladować istniejący zestaw funkcji za pomocą filtrów.

Jakiekolwiek umiejętności kodowania, które w tym momencie posiadałem lub nie, szybko stały się nieistotne, ponieważ mój nowy pracodawca był wściekły. Nie rozumiała znaczenia „hakowania rdzenia”, a ja nie byłem na tyle dojrzały, by wyjaśnić to w przystępny sposób. Jedyną rzeczą, która tymczasowo ochłodziła jej brwi, było zapewnienie jej, że mogę przywrócić ją za pomocą zainstalowanej wtyczki kopii zapasowej/przywracania.

Czy możesz zgadnąć, dokąd to zmierza?

Ta wtyczka, jak los chciał, utworzyła tylko kopię zapasową folderu wp-content . Bez względu na to, jakie hacki WordPress znajdowały się w tych podstawowych plikach, zniknęły na zawsze. Wciąż pamiętam mój e-mail z powrotem do niej (już dawno wygnała mnie z powrotem do mojego domowego biura):

Chłopaki, nie mogę zrobić kopii zapasowej.

Naprawdę byłem przygotowany na uzupełnienie jej pożądanego zestawu funkcji za pomocą filtrów i działań, ale ona tego nie usłyszała. Zwolniła mnie na miejscu, groziła pozwem i nigdy nie zapłaciła mi za dwa tygodnie bardzo ciężkiej pracy. Byłem tak upokorzony.

Jest wiele (teraz oczywistych) rzeczy, których mogłem się nauczyć z tego doświadczenia. Ogólna lekcja, że ​​kopia zapasowa nie jest kopią zapasową, dopóki nie zostanie przećwiczona i potwierdzona, jest dobra. Ale ten, który utknął mi bardziej, to konkretna lekcja na temat tego, jak dokładnie postępować z tworzeniem kopii zapasowych w WordPress – szczególnie z rdzeniem WordPress.

Nauczyłem się naprawdę cenić środowiska zarządzane, takie jak WP-Engine, z solidnym systemem tworzenia kopii zapasowych/przywracania. Wielu hostów butikowych ma różne narzędzia wiersza poleceń i inne funkcje przeznaczone dla programistów do wykonywania kopii zapasowych, ale WP-Engine jest moim ulubionym. Jest dość szybki, chyba że masz bardzo dużą sieć. Interfejs użytkownika jest prosty. Ma interfejs użytkownika, kropka: Każdy, kto wie, jak korzystać z WordPressa, może z tym pracować. To znaczy, w przeciwieństwie do niektórych metod CLI, które są prawdopodobnie o wiele szybsze, lub jakiejś niejasnej rzeczy ukrytej w Plesku, moi klienci mogą z tego korzystać, rozumieć to, monitorować i sprawdzać, czy go używam. Jestem wielkim fanem.

Czas, w którym przeciągnąłem całą naszą platformę do katalogu rodzeństwa

Byłem wciąż całkiem nowy w profesjonalnym miejscu pracy i zawsze byłem osobą Windows. Jednak moja nowa praca była w sklepie Mac i bardzo szybko nauczyłem się kochać wszystko w tej pracy. No, prawie wszystko. Wydawało mi się, że mam dużo problemów z „magiczną myszą”. Miałem tendencję do utraty połączenia Bluetooth, co prowadziło do przypadkowych i często przerażających czynności przeciągania i upuszczania po ponownym połączeniu. Co więcej, byłam po prostu niezdarna z nową umiejętnością motoryczną.

W tamtych czasach nasz przepływ programowania WordPress nadal obejmował wdrażanie do produkcji za pośrednictwem FTP. Nierzadko zdarzało mi się spędzać całe dni robocze na pisaniu kodu, rozmowach, odpowiadaniu na e-maile, ogólnie kręcąc się tam i z powrotem za pomocą mojej nowej magicznej myszy, podczas gdy Cyberduck był otwarty do produkcji na moim komputerze. Boże, czy to źle brzmi! Ale tak było.

Pewnego dnia po prostu zniknęła cała nasza platforma. Nasz administrator szybko założył, że to jakiś rodzaj DDoS lub coś ogólnie na jego poziomie. Jeśli chodzi o nas, deweloperów, zaufaliśmy jego instynktowi i założyliśmy, że wkrótce to zrozumie.

Mijały godziny. Dzień przyszedł i minął. Cały czas nie działa.

Następnego ranka wszystko zostało przywrócone, a nasz CTO delikatnie poprosił mnie, abym dołączył do niej w sali konferencyjnej. Nasz administrator zidentyfikował problem. Wyciągnął logi FTP i zauważył, że mój użytkownik przeniósł całą naszą platformę do katalogu siostrzanego. Oznacza to, że wp-content został zagnieżdżony w wp-includes .

Byłem zbity z tropu, ale nasz CTO był z tego świetny. Widziała, że ​​jestem ogólnie pomocnym i odpowiedzialnym pracownikiem, ale rzuciła mi wyzwanie, abym wyszedł poza zwykłą skruchę i wymyślił sposoby, aby temu zapobiec. Znalazłem dwie naprawdę pomocne rzeczy.

Pierwszym z nich było zlokalizowanie polecenia CLI, aby uniemożliwić Cyberduckowi w ogóle zezwalanie na zdalne przenoszenie plików. Był to dobry środek bezpieczeństwa i natychmiast przyjęliśmy go jako politykę firmy.

Po drugie, bardzo zainteresowałem się wdrażaniem przez Git. W końcu napisałem wtyczkę WordPress, aby wpleść nasze wersje Bitbucket w normalny przepływ aktualizacji wp-admin . Od tego czasu nie mieliśmy prawie żadnego powodu, aby mieć nawet dostęp FTP do produkcji. Ta wtyczka jest jednym z moich ulubionych osiągnięć zawodowych. Oczywiście, powinowactwo do Git jest dzisiaj warunkiem wstępnym dla programistów.

Czas, w którym usunąłem całą zawartość front-endu za pomocą add_filter()

Naprawdę myślałem, że w tym momencie stałem się całkiem sprytny dzięki moim praktykom WordPress. Prośba polegała na dołączaniu „plakietki” do postów określonej kategorii. Z jakiegoś powodu miałem na myśli, że tylko noobs doda kolejny warunek do pliku szablonu dla czegoś takiego, więc z wielką dumą zaimplementowałem następujący filtr:

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

Widzisz coś złego w tym? Szybko przetestowałem to w inscenizacji, aby potwierdzić, że wymagane posty otrzymały odznaki. Potem go uruchomiłem i wyszedłem z pracy na cały dzień. Jak można się domyślić, wszechświat eksplodował.

W rezultacie posty bez plakietki były renderowane w interfejsie bez żadnej treści! Czy widzisz dlaczego? Problem polegał na tym, że zamiast zwracać $content w stanie warty, zwracałem wartość false . Ale tak naprawdę jest tu wiele warstw błędów.

Dlaczego zadowoliłem się testowaniem tylko postów, które otrzymały plakietki? Dlaczego nie sprawdziłem również, czy inne posty pozostały nietknięte? Dlaczego wdrożenie do produkcji odbywało się tak późno? Dlaczego nasza kontrola jakości polegała wyłącznie na tym, że trochę kliknąłem i odświeżyłem stronę?

Odpowiedź na wszystkie te pytania można podsumować jako dojrzałość . Po prostu potrzeba trochę czasu, aby znudzić się popełnianiem tego rodzaju błędów, zanim zaczniemy inwestować w takie rzeczy, jak testy regresji wizualnej i testy jednostkowe. Ten konkretny błąd był pośród setek kroplą, która ostatecznie złamała grzbiet wielbłąda i doprowadziła do tego, że bardzo zainwestowałem w phpUnit i xDebug. Z kolei te narzędzia nauczyły mnie pisania testowalnego kodu, co prawdopodobnie zapobiegło większej liczbie błędów niż same testy.

Czas, który podzieliłem przez zero w nieskończonej pętli

Żądanie klienta polegało na przeformatowaniu wpisu na blogu WordPress w taki sposób, aby data brzmiała „XYZ temu” w przeciwieństwie do „10 listopada 2011 r.” Nie byłem do końca pewien, jak to osiągnąć, ale zdawałem sobie sprawę, że jest to format daty, który wydaje się zyskiwać na popularności, i rzeczywiście dr Google bardzo szybko dostarczył mi fragment. Udało się na moim lokalnym! Miał dużo matematyki, w szczególności dużo dzielenia . Nie byłem do końca pewien, dlaczego to zadziałało — było wiele zagnieżdżonych pętli, reszt, zaokrągleń i tak dalej. Ale było w Google i wydawało się, że działa, i byłem wystarczająco szczęśliwy, aby wdrożyć go do produkcji.

Jakieś 30 minut później otrzymałem nieprzyjazny Skype od naszego administratora. Produkcja spadła. Martwy w wodzie. Zapytał mnie, czy ostatnio dzielę przez zero i nie miałam pojęcia, do czego może się odnosić. Oto, co się stało.

Wierzcie lub nie, ale nieczytelny fragment „działał na moim lokalnym” fragmencie, który znalazłem, biorąc pod uwagę wystarczająco dużą próbkę, mógł wykazywać pewne nienormalne zachowanie. Dostarczone z pewnymi niefortunnymi kombinacjami dni, godzin i minut, pętle Rube Goldberg od czasu do czasu próbują podzielić liczbę przez zero. Przypomnij sobie z matematyki w szkole średniej:

W zwykłej arytmetyce wyrażenie to nie ma znaczenia, ponieważ nie ma liczby, która pomnożona przez 0 daje a (przy założeniu a ≠ 0), a więc dzielenie przez zero jest nieokreślone. - Wikipedia

Więc co to oznacza dla komputerów? Zwykle tylko komunikat o błędzie w dziennikach, ale w moim przypadku było gorzej: błąd matematyczny zakłócał logikę mojej pętli, powodując, że moje zagnieżdżone pętle działały bez ukończenia — nieskończona pętla prowadząca do białego ekranu śmierci. I jest coraz gorzej! Ponieważ każda iteracja pętli zapisywała błąd polegający na dzieleniu przez zero, dziennik błędów urósł do fantastycznych proporcji i zaczął utrudniać nasz system plików. Wywołało to efekt ataku DDoS, aczkolwiek absurdalnie wykonanego samodzielnie.

Złą rzeczą związaną z tym błędem było to, że usunął witrynę o dużym natężeniu ruchu. Dobrą stroną tego błędu jest to, że radykalnie zmienił moje podejście do pracy. Bardziej niż czegokolwiek wstydziłem się mojej chęci wdrożenia bez zrozumienia. Poprzysiągłem, że nigdy więcej nie będę wklejać fragmentu tekstu bez dołożenia wszelkich możliwych starań, aby zrozumieć każdy wiersz, nawet jeśli będzie to konieczne, skontaktuje się z autorem fragmentu.

Co więcej, obiecałem nigdy więcej nie wysyłać kodu, który nie byłby zbyt czytelny dla początkujących programistów. Miałem obsesję na punkcie standardów kodowania WordPressa, rozszerzeń edytora tekstu, wbudowanych komentarzy i docblocków, a nawet tabulatorów i spacji, tego klasycznego rytuału przejścia! Podsumowując, zdecydowałem się bardziej dbać o to, jak łatwo jest odczytać mój kod, niż jak łatwo go napisać . Ten bunt przeciwko wklejaniu bez zrozumienia doprowadził mnie do głębokiego zawodowego zainteresowania zarządzaniem zależnościami od osób trzecich, tematem, który w ciągu następnej dekady dostarczył mi różnych możliwości pisania i mówienia.

Och, a naprawdę zabawna rzecz w tym błędzie? Rdzeń WordPressa ma na to rozwiązanie jednoliniowe.

Czas, w którym projekt wymknął się spod kontroli, dopóki wszyscy nie mieli go dość

Dostałem naprawdę fascynujący projekt. Miałem być kierownikiem technicznym i inżynierem ds. rozwoju WordPressa, miałem też programistę Amazon AWS Lambda i głębokiego eksperta w raportowaniu JavaScript. To był pierwszy raz, kiedy zgłosiło się do mnie wiele osób i był to zdecydowanie najbardziej złożony projekt, nad jakim kiedykolwiek pracowałem. Nawet nazwanie tego projektem WordPressa było bardzo mało istotne, ale WordPress był spoiwem, które spajało całość, więc pełnienie roli kierownika technicznego miało dla mnie sens.

Ponieważ moją główną rolą było zazwyczaj bycie wyłącznie technikiem, a także dlatego, że mam słabość do minimalizmu, nigdy nie przyszło mi do głowy, aby zaimplementować coś takiego jak Jira lub Basecamp lub jakąkolwiek prawdziwą platformę do zarządzania zadaniami. W pierwszej iteracji projektu wszystko potoczyło się całkiem dobrze. Byliśmy w stanie pracować nad naszymi własnymi, indywidualnymi komponentami, odnosić się do dokumentu specyfikacji klienta jako naszej mapy drogowej produktu i po prostu pingować się nawzajem przez Slack, gdy potrzebowaliśmy połączyć rzeczy.

Kłopoty zaczęły się, gdy zaczęliśmy prezentować postępy klientowi i wdrażać jego opinie. To, co zaczęło się jako trzyosobowy zespół, od razu poczuło, że zostało przeniesione do nowego rzędu wielkości: nie było jasne, kto był odpowiedzialny za którą część informacji zwrotnych, jaki był status wdrożenia tych informacji zwrotnych, a nawet naprawdę kto rozmawiał z kim . Kilkakrotnie przekroczyliśmy limit 100 odpowiedzi w Gmailu na wątek!

Zaczęło się robić niekomfortowo. Myślę, że klient czuł, że stracił kontrolę nad kierunkiem projektu i co równie ważne, czuł, że stracił widoczność statusu projektu. Mój programista Amazon wspomniał pewnego dnia: „Zastanawiam się, czy powinniśmy używać Trello”.

Huh , pomyślałem. Czy trzyosobowy zespół potrzebuje takiej platformy? Ponownie, moja zwykła tendencja to preferowanie mniejszej liczby narzędzi, mniejszych kosztów ogólnych, mniejszej złożoności. Ale projekt już wciągał nas wszystkich w błoto, więc co było złego w próbowaniu?

Przeszukałem wszystkie nasze e-maile, wszystkie nasze dokumenty dotyczące specyfikacji, wszystkie różne wątki komentarzy i mapowałem je na tablicach Trello. Projekt natychmiast zmartwychwstał ze swojego cyfrowego grobowca, ponieważ mogliśmy komunikować się ze znacznie mniejszym obciążeniem psychicznym. Zamiast szukać tekstu w skrzynce odbiorczej lub w przeważnie przestarzałym dokumencie specyfikacji, mieliśmy piękne tablice, listy i karty. Łatwo było zobaczyć stan dowolnej funkcji, uwzględnić informacje zwrotne i wykonać nowe zadania. Czuło się, jakbyśmy stopniowo tracili wzrok, tak powoli, że tego nie zauważyliśmy, a potem nagle znowu mogliśmy widzieć .

To prawda, że ​​kod nie napisał się sam, wciąż był to bardzo wymagający projekt, a my nadal musieliśmy wykorzystać każdy gram naszych umiejętności technicznych. Ale o to właśnie chodzi: ponieważ w końcu mieliśmy infrastrukturę do zrozumienia projektu, mogliśmy teraz swobodnie zastosować nasze umiejętności techniczne.

Z radością mogę powiedzieć, że projekt został zrealizowany z pełną satysfakcją klienta. Obecnie uważam Trello lub Jira za de facto wymóg dla zespołów składających się z dwóch lub więcej osób.

Idź naprzód i ucz się na błędach innych

Oto jedna z najmądrzejszych rzeczy, jakich nauczyłem się w czasie mojej służby w wojsku: „Porucznicy mogą popełniać błędy poruczników i kapitanowie popełniają błędy kapitanów. To, co nie jest w porządku, to to, że kapitanowie popełniają błędy poruczników lub porucznicy popełniają błędy prywatne.

Innymi słowy, nie ma nic złego w popełnianiu typowych błędów, które są oczywiste przy obecnym poziomie odpowiedzialności. Ważniejsze jest to, jak z nich wyrastasz.

Mam nadzieję, że my jako programiści nauczymy się współczuć innym, gdy popełniają błędy, tak jak miejmy nadzieję, że inni byli z nami. Mam nadzieję, że pozostanę ciekawy i odpowiedzialny, kiedy popełniam błędy, aby móc dalej wprowadzać innowacje. Mam nadzieję, że zawsze będę otoczony inspirującą społecznością ekspertów od WordPressa — ludzi, na których błędach mogę się uczyć i których nie popełniam. A przede wszystkim mam nadzieję, że inni mogą wyciągnąć wnioski z mojego doświadczenia, na przykład z błędów WordPressa, którymi się tutaj podzieliłem.