Jeśli właśnie zdarzyło Ci się dołączyć do członkostwa w witrynie i szukasz treści specjalnie dla The Independent WordPress Developer, polecam przeczytanie poprzedniego posta – przynajmniej – aby przygotować się na treść w tym poście.
Jeśli jednak chcesz nadrobić zaległości w poprzednim artykule, oto krótka lista wszystkiego, co do tej pory napisano:
- Lokalny rozwój dla niezależnego programisty WordPress
- Bazy danych i narzędzia dla niezależnego programisty WordPress
- Instalowanie WordPressa dla rozwoju lokalnego
Gdy przygotowujemy się do rozmowy o bardziej zaawansowanych tematach, takich jak debugowanie i IDE, warto najpierw zwrócić uwagę na dostępne narzędzia, które możemy zainstalować w WordPressie, które pomogą nam w problemach z debugowaniem podczas rozwoju.
Co więcej, te problemy nie są związane z problemami stricte PHP. Obejmują one również problemy z JavaScriptem. Idąc o krok dalej, istnieją sposoby, w jakie możemy natywnie skonfigurować WordPressa, aby wyświetlał błędy bezpośrednio w naszej przeglądarce.
Więc zanim przyjrzymy się dziennikom błędów, IDE, Xdebug i tak dalej, przyjrzymy się, co możemy zrobić w samym WordPressie.
Natywne narzędzia do debugowania WordPress
Natywne narzędzia do debugowania WordPressa to połączenie dwóch rzeczy:
- opcje, które możemy ustawić w pliku konfiguracyjnym WordPressa, które pozwalają nam zobaczyć informacje zapisywane na ekranie,
- kilka wtyczek, które pomogą nam pracować z plikami PHP i JavaScript z obszaru administracyjnego WordPress
W odniesieniu do drugiego punktu powyżej chcę wyjaśnić, że istnieje wiele dostępnych wtyczek do czegoś takiego; jednak chcę, aby instalacja była jak najcieńsza, aby nie zasypywać nas zbyt dużą ilością informacji.
Zamiast tego chcę, abyśmy mieli informacje potrzebne do przetestowania i oceny naszej pracy, ale że mamy tylko to, czego potrzebujemy. Przynajmniej na razie. Być może porozmawiamy o zaawansowanych tematach w przyszłych postach.
Powiedziawszy to, zacznijmy.
Konfiguracja WordPress
Zanim zaczniesz martwić się konfiguracją, sam WordPress udostępnia kilka różnych opcji, które możemy skonfigurować w wp-config.phppliku. Są one dobrze udokumentowane w Kodeksie, ale z doświadczenia e-maili innych wiem, że informacje mogą być nieco trudne do przesiewania.
Po pierwsze, należy zwrócić uwagę na następujące informacje (cytowane z Kodeksu WordPress):
[WP_DEBUG]( https://codex.wordpress.org/WP_DEBUG „WP DEBUG") to stała PHP (stała zmienna globalna), której można użyć do uruchomienia trybu „debugowania” w całym WordPressie. Zakłada się, że domyślnie jest to wartość false i zwykle jest ustawiona na wartość true w pliku wp-config.php w kopiach programistycznych WordPress.
To zakłada, że rozumiesz stałe PHP. Jeśli nie, zapoznaj się z instrukcją tutaj (to całkiem proste). W skrócie to:
Stała to identyfikator (nazwa) prostej wartości.
Więc zrobię, co w mojej mocy, aby zapewnić opcje konfiguracyjne tak bardzo, jak to możliwe.
Najpierw w wp-config.phppliku będziesz chciał zmienić wiersz , który brzmi:
<?php
define( 'WP_DEBUG', false );Do tego :
<?php
define( 'WP_DEBUG', true );To jednak nie wszystko. Jest jeszcze kilka rzeczy do dodania, które poprawią środowisko debugowania:
<?php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );Jeśli podążasz za tekstem Ale co oznacza każda linijka? Oto zwięzłe wyjaśnienie, jakie mogę teraz podać:
- WP_DEBUG. Spowoduje to wyświetlenie wszelkich błędów i ostrzeżeń zgłoszonych przez PHP podczas uruchamiania WordPressa. Samo uruchomienie aplikacji nie powinno wykazywać żadnych problemów; jednak uruchamianie go razem z różnymi wtyczkami może być inną historią w zależności od jakości wtyczki.
- WP_DEBUG_LOG. Jest to jedna z moich ulubionych stałych, która szczegółowo zapisuje wszystkie dane wyjściowe w dzienniku. Opowiem o tym w nadchodzącym poście, ale na razie wiedz, że jest to coś, co moim zdaniem zawsze powinno być ustawione w twoim środowisku programistycznym.
- WP_DEBUG_DISPLAY. To jest taki, który możesz ustawić na prawdę lub fałsz (chociaż ja wolę prawda). Uzupełnia poprzednie ustawienie, umożliwiając wyświetlanie wiadomości w przeglądarce, które są również zapisywane na blogu. Nie wiem, czy uznasz to za korzystne, czy nie. Jeśli nie jesteś przygotowany na przeglądanie śladów stosu i bardziej szczegółowych informacji, możesz rozważyć ustawienie tego na true.
- dislay_errors. Kodeks wspomina, że możesz ustawić to na false, ale myślę, że powinno to być ustawione na true, aby umożliwić wyświetlanie błędów i ostrzeżeń.
- SCRIPT_DEBUG. Rdzeń WordPressa wykorzystuje zminifikowane wersje plików CSS i JavaScript. Wyłączenie tego ustawienia umożliwi przeglądanie całej zawartości plików w oryginalnej formie. Jest to szczególnie przydatne, jeśli zamierzasz współtworzyć Core lub pracować nad JavaScript zawartym w Core.
- ZAPISY. Moim zdaniem jest to nieco bardziej zaawansowane ustawienie. Krótko mówiąc, wszystkie zapytania, które działają w bazie danych, zostaną zapisane w tablicy PHP, którą można później przeanalizować. To
Skoro omówiliśmy konfigurację WordPressa, co z wtyczkami?
Wtyczki do debugowania
Kiedy mówię, że repozytorium jest pełne wtyczek do tego, mam na myśli to. W rzeczywistości, jeśli jesteś nowy w programowaniu WordPress, nie polecam szukania rzeczy do zainstalowania.
Może to szybko stać się przytłaczające, ryzykujesz, że nie zrozumiesz, co robią niektóre z nich, i potencjalnie poprowadzisz cię na ścieżkę, na której skończysz zepsuć instalację.
Zamiast tego polecam przyjrzeć się następującym wtyczkom (oczywiście najpierw przeczytać ich opis), a następnie przejść od tego miejsca:
- Pasek debugowania. Sama ta wtyczka dodaje menu do paska administracyjnego, które pozwala zobaczyć zapytanie, pamięć podręczną i inne informacje. Wymaga to włączenia funkcji WP_DEBUG i SAVEQUERIES, jak opisano powyżej.
- Zależności skryptów i stylów listy debugowania. Jest to dodatek do powyższej wtyczki, który pozwoli Ci debugować dalsze style JavaScript i CSS działające w kontekście WordPressa.
- Konsola paska debugowania. Ta wtyczka to taka, której powinieneś używać z wahaniem. Przynajmniej pozwala na uruchamianie PHP i MySQL z samego WordPressa. Nie polecam tej wtyczki, chyba że dobrze znasz jeden z dwóch języków. Mimo to, jeśli tak, jest to coś, co może być przydatne do tworzenia prototypów funkcji lub zapytania przed wbudowaniem ich we wtyczkę.
Badanie dzienników błędów
W następnym poście zaczniemy zastanawiać się, co jest konieczne, aby sprawdzić dziennik błędów generowany przez WordPress i jak zrozumieć wyświetlane informacje.
Ponadto przyjrzymy się, co jest konieczne do korzystania z wtyczek opisanych w tym poście. Następnie przejdziemy do jeszcze bardziej zaawansowanych narzędzi.
Ale krok po kroku, prawda?
Na razie jednak skonfiguruj swoją instalację zgodnie z powyższym opisem, zainstaluj połączone wtyczki, a następnie zrób, co możesz, aby zbadać, jak działają, co możesz zobaczyć na ekranie i jak może to wpłynąć i pozytywnie wpłynąć na Twój rozwój.
Tak, może być trochę krzywej uczenia się. Ale właśnie dlatego robimy to powoli. Jest wiele do nauczenia się, a my mamy mnóstwo czasu, aby ogarnąć wszystko, co jest potrzebne.