Moja podróż do stworzenia wtyczki WordPress za pomocą ChatGPT: 120 godzin pracy, bez wcześniejszego doświadczenia
Opublikowany: 2024-08-28Będę szczery: właściwie myślałem, że uda mi się zbudować wtyczkę WordPress za pomocą ChatGPT w ciągu zaledwie kilku godzin. A przynajmniej tak mi wmawiały wszystkie tutoriale na YouTube i wątki na Twitterze.
Ale powiem wam, że w tych historiach pominięto kilka kluczowych szczegółów – dokładnie około 120 godzin. Tak, tyle czasu zajęło mi zbudowanie wtyczki od początku do końca: 120 godzin!
Dla kontekstu, nie miałem żadnego wcześniejszego doświadczenia z tworzeniem wtyczek ani WordPressa, ale i tak zdecydowałem się zanurkować. I chociaż uwielbiałem to wyzwanie, okazało się ono o wiele trudniejsze, niż się spodziewałem. Na każdym kroku natrafiałem na jedną przeszkodę za drugą, o istnieniu wielu z nich nawet nie wiedziałem. To było frustrujące, ale także ogromne – ogromne (!) – pouczające doświadczenie.
Zakładając, że planujesz pójść w moje ślady, gorąco zachęcam Cię do wcześniejszego przeczytania tego artykułu w całości. Nie mówię tego w ramach autopromocji. Mówię to, ponieważ naprawdę pozwoli Ci to zaoszczędzić wiele godzin, a nawet dni, dodatkowej pracy. Jest tak wiele rzeczy, na które natknąłem się w tym procesie, że nie miałem pojęcia, że są ważne, aż do momentu, kiedy stało się to faktem. Niestety doprowadziło to do niezliczonych poprawek kodu (wypełnionych dużą ilością frustracji), którym można było zapobiec. Czytając to, nie będziesz miał tego problemu.
Dla kogo to jest, a dla kogo nie jest 🙋♂️
W zależności od Twojego wykształcenia i umiejętności możesz się zastanawiać, czy masz „wystarczające kwalifikacje”, aby to zrobić. Powiem tyle:
Chociaż nie musisz mieć żadnej wymaganej wiedzy na temat kodowania, musisz z entuzjazmem uczyć się kodu i ogólnego procesu tworzenia wtyczki. Należy przejść przez wiele faz i często jedna faza nie ma nic wspólnego z drugą pod względem umiejętności (lub nawet narzędzi) potrzebnych do jej ukończenia. Krótko mówiąc, bądź gotowy na naukę – DUŻO .
W zależności od charakteru wtyczki i ostatecznych celów opracowanie produktu końcowego może z łatwością zająć miesiąc lub dłużej.
Wyostrzone oko do szczegółów i rozpoznawanie wzorców będzie bardzo pomocne, podobnie jak wiedza o tym, co robią PHP, JavaScript i CSS. Nie musisz wiedzieć, jak z nimi kodować, ale zrozumienie ich przeznaczenia i sposobu użycia będzie zaletą.
Jeśli żadne z powyższych nie opisuje Ciebie – zwłaszcza chęci do nauki – i szukasz szybkiego i łatwego rozwiązania, to nie jest to dla Ciebie. Nie jest to ani szybkie, ani łatwe. Jednak jest to możliwe, jeśli włożysz w to wysiłek.
Jeśli nie masz nic przeciwko, zaczynajmy.
Faza pierwsza: szczegółowo zaplanuj swoją wtyczkę 📝
Pierwsze pytanie, które musisz sobie zadać – i odpowiedzieć – brzmi : jakiego typu wtyczkę chcę zbudować i co chcę, żeby robiła?
Możesz mieć ochotę spieszyć się z tym, aby móc zacząć faktycznie budować i kodować, ale nalegam, abyś nie spieszył się z tym. To, co tutaj zrobisz, położy podwaliny pod podpowiedzi i pozwoli ci budować w zorganizowany sposób, zamiast dodawać rzeczy na bieżąco. Aby skutecznie przejść przez tę fazę, rozważ następujące kwestie:
- Jakie funkcje ma mieć Twoja wtyczka?
- Jak ma wyglądać strona wp-admin?
- Twórz modele szkieletowe lub schematy blokowe, aby wizualizować przepływ pracy wtyczki.
- Narysuj go i opisz w najdrobniejszych szczegółach.
- Zdecyduj, czy chcesz go do użytku prywatnego, czy chcesz udostępnić go w repozytorium WordPress do publicznego dostępu.
Funkcje
Administrator wp
Następnie zastanów się, jak chcesz, aby Twoja wtyczka wyglądała i działała w obszarze administracyjnym WordPress. Obejmuje to:
- Strony ustawień : jakie opcje chcesz udostępnić? Jak je zorganizujesz?
- Menu : Gdzie pojawi się Twoja wtyczka w menu administratora? Czy będzie miało podmenu?
- Metaboksy : jeśli Twoja wtyczka wchodzi w interakcję z postami lub stronami, czy będzie potrzebować niestandardowych metaboksów?
- Tabele : jeśli przechowujesz dane, w jaki sposób wyświetlisz je administratorowi do przejrzenia?
W moim przypadku zdecydowałem się na główną stronę ustawień z zakładkami dla każdego z moich skrótów, osobną stronę z dokumentacją, a także stronę z formularzem kontaktowym, na wypadek gdyby użytkownicy chcieli się ze mną skontaktować. Oto co wymyśliłem:
Na nieszczęście dla mnie – ale nie dla ciebie, bo to czytasz – byłem tak skupiony na funkcjonalności mojej wtyczki w fazie planowania, że całkowicie zaniedbałem stronę wp-admin.
To sprawiło, że trwało to dłużej, niż gdybym zaplanował to z wyprzedzeniem, ponieważ musiałem poprawiać kod, gdy zdawałem sobie sprawę, że to, co mam, jest niekompletne lub ma słaby UX. Gdybym zaplanował to z wyprzedzeniem, albo jeszcze lepiej, gdybym użył modeli szkieletowych, wówczas ta faza przebiegłaby znacznie płynniej – co stanowi idealne przejście do następnego punktu.
Modele szkieletowe lub schematy blokowe
Połącz wszystko i opisz szczegółowo
Użytek prywatny a dostęp publiczny za pośrednictwem repozytorium WordPress
Zanim przejdziesz do fazy drugiej, powinieneś podjąć jeszcze jedną decyzję. Ta decyzja ma związek z tym, dla kogo zamierzasz zbudować tę wtyczkę.
Chcesz zrobić to tylko dla siebie (lub klienta)? A może chcesz przesłać go do repozytorium WordPress do zatwierdzenia, aby był dostępny dla ogółu społeczeństwa?
Technicznie rzecz biorąc, nie musisz jeszcze koniecznie podejmować tej decyzji. Jednak z perspektywy czasu żałuję, że nie zrobiłem tego wcześniej. Dlatego zalecam, abyś zrobił to teraz.
Powodem jest to, że moim celem od początku było przesłanie wtyczki do repozytorium, ale początkowo zbudowałem wtyczkę bez przestrzegania standardów kodowania WordPress. Skupiłem się wyłącznie na funkcjonalności i doprowadzeniu jej do punktu, w którym działała bez błędów.
W rezultacie musiałem wprowadzić wiele dodatkowych poprawek w kodzie, aby dostosować go do standardów. Nie trzeba dodawać, że zajęło to dużo czasu i można było tego uniknąć.
Mając to na uwadze, nawet jeśli planujesz zbudować wtyczkę wyłącznie do użytku prywatnego, nadal zalecałbym przestrzeganie standardów kodowania. Zmniejszy to prawdopodobieństwo nieprawidłowego działania wtyczki w późniejszych wersjach WordPress. Jeśli chodzi o proces, główna różnica polega na tym, że nie trzeba aż tak bardzo podchodzić do niefunkcjonalnych aspektów standardów.
Na przykład, gdy tworzysz komentarze wbudowane, takie jak // Use global default. na końcu należy postawić kropkę. Kropka nie ma żadnego celu funkcjonalnego, ale jeśli jej brakuje, zostanie oznaczona jako „błąd” zgodnie ze standardami. W przypadku kompilacji prywatnej możesz zignorować tego typu „błąd”.
Faza druga: daj ChatGPT szczegółowy monit o rozpoczęcie programowania 🗣️
Główną ideą jest udostępnienie GPT przeglądu wtyczki za pomocą jasnych instrukcji. Ogólnie rzecz biorąc, radziłbym unikać prób budowy całego domu na raz. Lepiej zastosować podejście cegła po cegle.
Powiedzmy, że jako przykład miałbyś zbudować moją wtyczkę.
Mimo że ma osiem efektów, zalecałbym poinformowanie GPT, że chcesz zacząć od jednego efektu. Prawie tak, jakbyś budował wtyczkę z jednym efektem zamiast wtyczki z ośmioma efektami . Następnie sprawdź, czy efekt działa – łącznie z obszarem ustawień zaplecza. Napraw wszelkie błędy, a gdy wszystko będzie wyglądać dobrze, dodaj kolejny efekt. Następnie wykonaj ten proces, jeden po drugim.
Powodem takiego działania jest to, że ułatwia to naprawianie wszelkich błędów, które mogą pojawić się w kodzie w miarę wzrostu jego złożoności. Jeśli GPT wygeneruje cały kod na raz i wiele rzeczy nie będzie działać, naprawienie tego będzie znacznie trudniejsze.
Nadal chcesz przedstawić GPT ogólny przegląd swojej ogólnej wizji wtyczki, ale zakończ monit, skupiając się najpierw na jakiejś konkretnej rzeczy.
Aby zaoszczędzić Ci trochę czasu, stworzyłem przykładowy szablon, który możesz udostępnić ChatGPT na początek.
Aby wypełnić sekcje w nawiasach [X], wymagane jest wprowadzenie danych przez Ciebie. Być może będziesz musiał edytować go dalej, w zależności od rodzaju wtyczki, którą planujesz zbudować.
Jeśli nie rozumiesz wszystkiego, co jest zawarte w monicie, nie martw się, ja też nie. Dowiesz się, przechodząc przez ten proces.
Moja podpowiedź 🤖
I want to build a WordPress plugin called [name] that does the following: [General overview but don't give GPT the specifics yet] I'd like it to work via [Refer back to the section "combine everything and describe it in detail" from phase one; think about how you want your plugin to function - if you're not sure, then you can delete this part] . I would also like to create a settings menu in wp-admin so that users can [Explain what you want your settings menu to look like and do, including any specific UI/UX considerations; if you create any wireframes, upload those as well] I plan on using the following tools for this process: - Docker and/or Local by Flywheel {Choose one or use both} - Terminal (MAC) {if you're using a PC, substitute with Command Prompt} - Sublime Text - Chrome and Chrome inspector tool Also, I want to use GitHub for version control to track changes and collaborate effectively. I will use the default WordPress template provided by GitHub to generate the code for the .gitignore file. However, I will need your help to walk me through how to set up a repository and how to commit my files to it. For the main PHP file, the author name should be [your name] and the author URI should be [your website if you have one] . For any code you generate, please use tabs for indentation and not spaces. {important if you plan on submitting your plugin to the WordPress repository} If you need to enqueue any scripts, please ask me questions to help me figure out whether we should use conditional loading or if we should enqueue globally. In addition, when generating CSS, please follow BEM (Block Element Modifier) methodology. Let's begin with [insert which feature you'd like to build first] Please [Optional: help me setup Local by Flywheel and then] generate the initial PHP file and advise on next steps after that.Gdy podasz monit ChatGPT, poprowadzi Cię on przez pozostałe kroki, które opisałem poniżej. Warto zauważyć, że w zależności od nastroju ChatGPT lub Twojej chęci podążania za procesem, jak to przedstawiłem, sposób, w jaki wyszczególniam wszystko, może nie być tak liniowy, jak jest to przedstawiane.
Aby dać ci pojęcie o tym, co mam na myśli, sam przetestowałem monit trzy razy. Oprócz pomocy w skonfigurowaniu Local przez Flywheel i wygenerowaniu początkowego pliku PHP, za każdym razem zdecydował się na wykonanie pozostałych kroków w inny sposób.
Pierwsza próba
Podczas mojej pierwszej próby ChatGPT nie wykraczał poza wygenerowanie pliku PHP i przedstawił mi dwie opcje dotyczące dalszego postępowania. Warto zauważyć, że postępował zgodnie z instrukcjami dotyczącymi kolejkowania skryptów z ładowaniem warunkowym i również o tym wspomniał.
Druga próba
Druga próba zaowocowała najprostszym plikiem PHP, ale jednocześnie najdokładniejszą ogólną odpowiedzią pod względem wykonywania poszczególnych kroków. Od razu przystąpiono do używania Terminalu do konfigurowania katalogów projektu i inicjowania Sublime. Posunęło się nawet do poinstruowania mnie, jak skonfigurować repozytorium Git.
Trzecia próba
Trzecia próba była nieco podobna do pierwszej. Chociaż w przeciwieństwie do pierwszej próby ChatGPT nie skonfigurował warunkowego ładowania skryptów ani mnie o to nie zapytał. Po prostu domyślnie wygenerował je jako globalne.
Jedzenie na wynos
Powodem, dla którego krótko podzieliłem się z Tobą tymi trzema próbami, było nie tylko wzmocnienie tego, co powiedziałem wcześniej o tym, że przepływ pracy niekoniecznie będzie ustandaryzowany, ale także zwrócenie uwagi, że monit jest dla Ciebie tak samo ważny, jak dla GPT .
Mam na myśli to, że Twoim zadaniem jest zwrócenie uwagi na to, co ChatGPT robi – a czego nie robi – i przywrócenie go na właściwe tory, jeśli ulegnie pogorszeniu. Dlatego podczas tej podróży nie zapomnij wrócić do podpowiedzi i wskazówek, które udostępnię nieco później w sekcji debugowania. Przypomnij i zmień orientację ChatGPT, aby robił to, co chcesz, tak często, jak potrzebujesz.
Pobierz moją wtyczkę i przetestuj ją 📥
Jeśli chcesz wypróbować „działającą wersję” mojej wtyczki, plik ZIP znajduje się poniżej. Zaktualizuję to w najbliższej przyszłości, aby uwzględnić wersję repozytorium WP, ale na razie pozwoli ci to z niej korzystać.
Faza trzecia: narzędzia, skrypty, katalogi i Git 👩💻
W tej fazie przygotujesz podstawy do zbudowania wtyczki. Jest to również miejsce, w którym krzywa uczenia się szybko wzrośnie, zwłaszcza gdy zaczniesz instalować skrypty i korzystać z terminala (lub wiersza poleceń, jeśli używasz komputera). Oto zestawienie:
- Zdecyduj, którego narzędzia środowiska lokalnego chcesz użyć (np. Local by Flywheel, Docker).
- Skonfiguruj katalogi projektu.
- Zainstaluj swoje skrypty (np. npm, Composer).
- Skonfiguruj repozytorium Git („repo”) i zatwierdź (prześlij) do niego pliki wtyczek
Buduj środowisko lokalne
Skonfiguruj katalogi projektu
Zainstaluj skrypty
Utwórz repozytorium Git („repo”) i zatwierdź swoje pliki
Po wykonaniu wszystkich poprzednich kroków nadszedł czas na utworzenie repozytorium Git i zatwierdzenie w nim początkowych plików. Ten krok tworzy migawkę punktu początkowego projektu.
Osobiście korzystałem z GitHuba, ponieważ tego właśnie używamy tutaj w Themeisle, więc miałem już tam konto, ale są też inne platformy (np. GitLab, Bitbucket). Jeśli ostatecznie skorzystasz z platformy innej niż GitHub, nie zapomnij dostosować szablonu podpowiedzi w fazie trzeciej .
Aby zachować zwięzłość, nie będę Cię pokazywał, jak to zrobić. Po osiągnięciu tego kroku ChatGPT może poprowadzić Cię przez proces krok po kroku, łącznie z poleceniami, które będziesz musiał wpisać w terminalu/wierszu poleceń.
Podczas zatwierdzania plików początkowych należy pamiętać o następujących kwestiach:
- Sprawdź, co robisz: Upewnij się, że dołączasz tylko niezbędne pliki. Użyj pliku
.gitignoreaby wykluczyć wszelkie pliki tymczasowe lub wygenerowane. - Napisz jasny komunikat zatwierdzenia: Coś w stylu „Początkowe zatwierdzenie: podstawowa struktura projektu i konfiguracje” działa dobrze.
- Nie martw się o perfekcję: to tylko Twój punkt wyjścia. Podczas opracowywania wtyczki będziesz dokonywać znacznie więcej zatwierdzeń.
Ponownie ChatGPT najprawdopodobniej poda ci wskazówki dotyczące konkretnych poleceń, których należy użyć w przypadku tego początkowego zatwierdzenia. Jeśli tak się nie stanie, po prostu o to poproś. Pamiętaj, aby napisać, że potrzebujesz dokładnych kroków w zależności od konfiguracji i platformy Git.
Wykonując ten krok, oficjalnie rozpoczniesz projekt tworzenia wtyczek z solidnymi podstawami kontroli wersji. Odtąd będziesz mógł śledzić każdą wprowadzaną zmianę, bezpiecznie eksperymentować z nowymi funkcjami i współpracować z innymi, jeśli zechcesz.
Faza czwarta: czas odtwarzania wtyczki 🖱️
Powiedziałbym, że ze wszystkich faz ta i następna są prawdopodobnie najfajniejsze, ponieważ wtedy naprawdę zaczynasz widzieć, jak wszystko się układa. Aby rozpocząć, zaloguj się do lokalnej instalacji WordPress. Jeśli zdecydujesz się na użycie Local by Flywheel, jest to bardzo proste, wystarczy kliknąć przycisk WP Admin w prawym górnym rogu:
Jeśli skończysz na Dockerze lub innym lokalnym narzędziu programistycznym i nie będziesz pewien, jak dostać się do swojej witryny, po prostu zapytaj ChatGPT.
Po zalogowaniu aktywuj wtyczkę, przechodząc do Wtyczki → Zainstalowane wtyczki . Następnie znajdź swoją wtyczkę na liście i kliknij Aktywuj :
⚠️ Ważne : jeśli nie widzisz tutaj swojej wtyczki, nie panikuj. Najprawdopodobniej jest to niezgodność katalogu, ale niezależnie od tego możesz dotknąć ChatGPT, aby pomóc Ci to rozgryźć. Jeśli po wielokrotnych próbach nadal utkniesz, a ChatGPT nie zasugerował Ci wypróbowania trybu debugowania WordPressa, poproś go o udostępnienie fragmentów kodu. Będą wyglądać mniej więcej tak:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Po aktywowaniu wtyczki zacznij z niej korzystać i zrób notatki:
- Czy wszystko działa tak jak powinno? Bardzo mało prawdopodobne .
- Co nie działa? W jakim sensie to nie działa?
- Jakie drobne rzeczy całkowicie przeoczyłeś w początkowym opisie podpowiedzi, a które nie działają poprawnie?
Po zrobieniu notatek możesz przejść do następnej fazy: debugowania i lintingu.
Faza piąta: debugowanie i linting 💻
Złożoność wtyczek i błędy są ze sobą powiązane: im bardziej złożona jest wtyczka, tym większe jest ryzyko wystąpienia błędów . Ale nawet prostsze wtyczki będą wymagały lintingu i debugowania.
Linting
Jeśli w tym artykule po raz pierwszy widzisz słowo „linting” i nie jesteś pewien, co ono oznacza, w bardzo prosty sposób sprawdza on kod Twojej wtyczki pod kątem zestawu zasad i standardów dotyczących tego typu kodu. Następnie informuje, czy znalazł jakieś błędy lub niespójności, na jakich liniach się one znajdują i jak je rozwiązać.
Linting jest dość prosty. Upewnij się tylko, że używasz odpowiednich narzędzi do lintingu dla typów kodu/plików, nad którymi będziesz pracować:
- PHP_CodeSniffer ze standardami kodowania WordPress dla lintingu PHP.
- ESLint do lintingu JavaScript.
- StyleLint do lintingu CSS.
W przypadku JavaScript możesz także dodać:
- ESLint Unicorn: Ponad 100 potężnych reguł ESLint.
- Obietnica ESLint: Przydatna do zarządzania zadaniami asynchronicznymi, takimi jak wywołania API, zapytania do bazy danych, obsługa plików lub wszelkie operacje wymagające czasu.
Debugowanie
W przeciwieństwie do lintingu, debugowanie przebiega podobnie do tego, co robiłeś w poprzedniej fazie, czyli samodzielnie korzystasz z wtyczki, identyfikujesz problemy, które wymagają rozwiązania, a następnie albo sam je naprawiasz, albo prosisz ChatGPT o pomoc.
Osobiście uważam, że debugowanie jest bardziej skomplikowane niż linting. Jednym z głównych powodów jest to, że podczas lintowania wynik procesu lintingu mówi dokładnie, na czym polegają problemy i gdzie w kodzie się one znajdują. Debugowanie nie zapewnia takiego luksusu. To zależy od Ciebie i ChatGPT, aby to rozgryźć.
Jednak ChatGPT ma trudności z utrzymaniem skupienia lasera na problematycznych liniach kodu, co oznacza, że musisz zadbać o „gotowość”, zanim pozwolisz mu „odpalić”.
Aby Ci to ułatwić, przygotowałem listę wszystkich porad, które sam bym dał przed rozpoczęciem fazy debugowania.
Nie bądź niejasny i nie zostawiaj tego ChatGPT
Jeśli nie podasz ChatGPT bardzo szczegółowych instrukcji, zacznie wypluwać w Twoją stronę niekończące się linie kodu i często kod nie będzie się nawet różnił od tego, który już Ci dał. Będzie wymagać od Ciebie „podwójnego sprawdzenia”, czy jest poprawny, ale to tylko strata czasu. Nie ma nic bardziej frustrującego niż to:
Zamiast tego powinieneś dać ChatGPT bardzo szczegółowe instrukcje, aby nie tylko wygenerować kod, ale konkretnie wyizolować, które wiersze kodu według niego są przyczyną problemu i pokazać je tobie. Powiedz mu, aby wyjaśnił, w jaki sposób planuje zmienić te linie i dlaczego uważa, że te zmiany rozwiążą problem. Na koniec poproś o informację, jaki powinien być oczekiwany wynik po wdrożeniu tych zmian.
Te instrukcje pomogą mu skoncentrować się na problemie i zminimalizują błędy uboczne, które mogą rozwiązać jeden problem, ale spowodować nowe problemy w procesie.
Zwykły CSS kontra BEM CSS
W powiązaniu z powyższym, ale specyficznym dla CSS, należy pamiętać, że w przypadku dowolnych fragmentów CSS ChatGPT wygeneruje standardowy CSS lub to, co domyślnie nazywam „klasowym CSS”.
Jest to podstawowy kod CSS, którego możesz się nauczyć, biorąc udział w kursie dla początkujących na ten temat. Jest to łatwe do zrozumienia i nie ma w tym nic złego technicznie, ale podczas tworzenia wtyczek WordPress może to prowadzić do konfliktów z innymi wtyczkami lub motywami.
Zamiast tego lepiej powiedzieć GPT, aby zastosował metodologię BEM (Block Element Modifier). BEM pomaga zmniejszyć ryzyko konfliktów CSS, zapewniając jasną i uporządkowaną konwencję nazewnictwa. Zapewnia to, że Twoje style są bardziej przewidywalne i łatwiejsze w zarządzaniu, ponieważ każdy blok, element i modyfikator ma odrębną, opisową nazwę klasy, która minimalizuje ryzyko niezamierzonych wpływów na stylizację. Dodatkowo BEM poprawia łatwość konserwacji, ułatwiając lokalizowanie i aktualizowanie określonych stylów bez wpływu na inne.
Wspomniałem już o tym w przykładowym monicie w fazie drugiej, ale podkreślam to tutaj, abyś zawsze pamiętał o przekazaniu tych instrukcji ChatGPT w przypadku fragmentów CSS.
Ładowanie warunkowe a kolejkowanie globalne
Inne domyślne zachowanie ChatGPT ma związek z kolejkowaniem skryptów. Nie martw się, jeśli jeszcze nie wiesz, co oznacza to wyrażenie. Liczy się to, że rozpoznasz to w swoim kodzie, kiedy go zobaczysz. Będzie to wyglądać mniej więcej tak:
function enqueue_my_scripts() { wp_enqueue_script('my-plugin-script', plugin_dir_url( FILE ) . 'js/my-script.js', array('jquery'), '1.0.0', true); } add_action('admin_enqueue_scripts', 'enqueue_my_scripts');W powyższym przykładzie kod globalnie kolejkuje skrypt dla wszystkich stron administracyjnych, co często jest niepotrzebne i może prowadzić do problemów z wydajnością. Niestety, właśnie to da Ci ChatGPT, chyba że odezwiesz się i powiesz, żeby tego nie robił. Żeby było jasne, w niektórych przypadkach jest to całkowicie właściwe, ale w wielu przypadkach tak nie jest.
Dlatego też, gdy tylko zauważysz, że ChatGPT generuje dowolny kod ze słowem „enqueue”, upewnij się, że prowadzisz na ten temat rozmowę. Zapytaj ChatGPT, czy ma sens kolejkowanie skryptów globalnie, czy tylko na określonych stronach, na których potrzebne są skrypty – co jest znane jako „ładowanie warunkowe”.
Przypominaj i przypominaj często
ChatGPT ma skłonność do zapominania, co jest jeszcze bardziej widoczne, gdy używasz go do kodowania. Tak więc, chociaż możesz wydać mu szczegółowe instrukcje, prawdopodobieństwo, że zastosuje się do tych instrukcji przez cały czas trwania projektu, wynosi zero .
Czasami nawet całkowicie zignoruje to, o co go poprosisz. Jeśli tak się stanie, po prostu bądź bardziej surowy i daj znać, że nie robi tego, czego chcesz:
Co więcej, po kilku interakcjach szybko powróci do swojego standardowego zachowania, polegającego na próbie zatopienia Cię w ogromnych ilościach kodu, które nie mają nic wspólnego z sekcją kodu, którą próbujesz debugować.
Gdy tak się stanie, po prostu naciśnij przycisk stop na wyjściu GPT i przypomnij mu, aby postępował zgodnie z instrukcjami. Pomocne jest także skopiowanie i wklejenie ich do okna czatu podczas dawania przypomnienia.
A mówiąc o generowaniu długich linii kodu…
Unikaj konieczności ponownego generowania przez ChatGPT całych plików
Jeśli nie jesteś przyzwyczajony do pracy z kodem i czujesz się nim onieśmielony, poproszenie ChatGPT o ponowne wygenerowanie całego pliku po każdej zmianie kodu może początkowo wydawać się atrakcyjne.
Wszystko, co musisz zrobić, to „skopiuj i wklej”, prawda?
Choć może się to wydawać kuszące, w rzeczywistości jest to zły pomysł . Na dłuższą metę sprawi ci to więcej kłopotów. Nie tylko zmarnujesz na to dużo czasu – zwłaszcza jeśli debugujesz plik PHP, który może być dość długi, ale ChatGPT może przy tym wprowadzić nowe błędy do istniejącego kodu. Rozwiąże to problem, nad którym pracujesz, ale potem przypadkowo zmieni inną część pliku i coś zepsuje.
Lepiej odizolować konkretne części kodu, które powodują problem i pracować tylko nad nimi.
Weź jeden błąd na raz
Zgodnie z powyższym, nawet jeśli masz wiele błędów – chyba że są one bardzo drobne – mów ChatGPT tylko o jednym z nich na raz. Napraw każdy błąd przed przejściem do następnego.
Zwróć szczególną uwagę na górne i dolne wiersze fragmentów kodu
Kiedy ChatGPT udostępnia fragmenty kodu, czasami – ale nie zawsze – hermetyzuje je, pokazując górną linię całego pliku, z którym pracujesz, a także dolną linię. Dlatego należy uważać, aby nie zawsze po prostu skopiować i wkleić cały fragment kodu, ponieważ spowoduje to uszkodzenie kodu.
⚠️ Zwróć szczególną uwagę na górną linię:
Jeśli nie ma to związku z konkretnym fragmentem kodu, który próbujesz debugować, zignoruj go.
To samo tyczy się wyników końcowych, choć może to być trudniejsze do zauważenia. Czasami może to być tak proste, jak }); co powoduje uszkodzenie kodu, ponieważ zamyka fragment nadrzędny, który nie powinien być jeszcze zamykany.
Po pewnym czasie staniesz się w tym lepszy, ale jeśli zaczniesz przygodę z tworzeniem wtyczek i zauważysz, że po dodaniu fragmentu wiele rzeczy się psuje, spróbuj usunąć ostatnią linijkę, aby sprawdzić, czy „w magiczny sposób” ” naprawia wszystko.
Konsola jest Twoim najlepszym przyjacielem
Jeśli ChatGPT bezskutecznie próbuje debugować ten sam problem i kręci Ci się w kółko, poproś go o dodanie wierszy console.log do sekcji kodu, które jego zdaniem są przyczyną problemu. Następnie otwórz konsolę i odtwarzaj błąd. Wyjaśni, co się stało. Następnie możesz zrobić zrzut ekranu tego wyjaśnienia i przekazać go ChatGPT, aby mógł dowiedzieć się, jak to naprawić.
Aby uzyskać dostęp do konsoli w przeglądarce Google Chrome, kliknij stronę prawym przyciskiem myszy i wybierz opcję Sprawdź :
Gdy konsola nie daje odpowiedzi, sprawdź swoją bazę danych
Konsola jest doskonała i często daje odpowiedzi, których potrzebujesz. Jednak w niektórych przypadkach potwierdzi jedynie to, czego doświadczasz, ale tak naprawdę nie da ci żadnych wskazówek, jak to naprawić.
Na przykład, gdy próbowałem dodać efekt pisania do mojej wtyczki, domyślna prędkość podglądu efektu w wp-admin została ustawiona na 23 milisekundy. Spędziłem niesamowitą ilość czasu na sprawdzaniu plików PHP i JavaScript, próbując rozwiązać problem, ale bezskutecznie.
Konsola potwierdziła, że ładowało się o godzinie 23, ale poza tym nie przekazała mi żadnych innych cennych informacji:
W końcu sprawdziłem bazę danych i zdałem sobie sprawę, że pochodzi stamtąd błędna wartość:
Zmieniłem 23 na 60, czyli to, czego chciałem, i to rozwiązało problem.
Jeśli zdecydujesz się na użycie Local by Flywheel, możesz łatwo uzyskać dostęp do swojej bazy danych poprzez interfejs, klikając kartę Baza danych:
Gdy uzyskasz dostęp, dobrym miejscem do rozpoczęcia poszukiwań będzie to samo miejsce, które widziałem na powyższym zrzucie ekranu: wp_options. W większości przypadków znajdziesz tam ustawienia wtyczek.
⚠️ Należy jednak również zauważyć, że większym problemem było to, że w moim kodzie brakowało instrukcji aktywacji. Kiedy wtyczka jest aktywowana po raz pierwszy, powinna sprawdzić, czy w bazie danych istnieją określone ustawienia. Jeśli tak nie jest, wtyczka powinna dodać je z zamierzonymi wartościami domyślnymi. Dzięki temu każda nowa instalacja wtyczki rozpocznie się z poprawnymi ustawieniami. Nauczyłem się tego na własnej skórze, żebyś ty nie musiał.
Świeży wątek może dać przełom
W miarę jak Twój kod się rozrasta, a Twój wątek w ChatGPT staje się coraz dłuższy, będzie on podatny na popełnianie błędów lub zapominanie. W pewnym momencie warto założyć nowy wątek. Prześlij swoje główne pliki wtyczek do nowego wątku i wyjaśnij ChatGPT, co robisz i gdzie przerwałeś.
Oto przykładowy monit, którego możesz użyć:
Pracowałem z Tobą nad debugowaniem wtyczki WordPress w innym wątku, ale myślę, że wątek stał się za długi i zaczynałeś się mylić. Zacznijmy od nowa.
Przyjrzyj się plikom wtyczek tutaj i spróbujmy rozwiązać problem [opisz swój błąd] .
Ponadto, co jest BARDZO WAŻNE, podczas generowania nowych wersji fragmentów kodu w celu rozwiązania problemu nie należy po prostu generować fragmentu, ale także podać wyjaśnienie, w których liniach zmieniono to, co już jest obecne. Wyjaśnij także uzasadnienie zmiany tych linii i czego możemy się spodziewać po wprowadzonych zmianach.
[Jeśli generujesz CSS, nie zapomnij przypomnieć ChatGPT o przestrzeganiu metodologii BEM (Block Element Modifier).]
Nie bój się używać mózgu
Im bardziej złożona jest wtyczka, tym większe ryzyko, że GPT zepsuje Twój kod. Chociaż pomaga to w debugowaniu, czasami okaże się, że lepiej jest znaleźć rozwiązanie samodzielnie. Szczerze mówiąc, przydarzyło mi się to dość często, zwłaszcza na późniejszych etapach mojej kompilacji, kiedy mój główny plik PHP rozrósł się do ponad 500 linii (z późniejszymi wersjami przekraczającymi 1000).
W zależności od Twojej znajomości i komfortu czytania kodu, może to działać odstraszająco, ale jeśli potrafisz rozpoznawać wzorce i dostrzegać niespójności, możesz sobie poradzić.
Z pewnością nie jestem utalentowanym programistą, chociaż rozumiem, co robią różne języki programowania i pewną znajomość kodu, co mi pomogło.
Mimo to, nawet jeśli jesteś całkowitym noobem, możesz przyjrzeć się linijkom kodu, które według GPT mogą być przyczyną problemu. Następnie znajdź w swoim kodzie identyczny element, który działa poprawnie. Porównaj jego kod z kodem uszkodzonego elementu i spróbuj zobaczyć, czym się różni. Często to rozwiązuje problem:
Zachowaj kopie zapasowe plików wtyczek (opcjonalnie, jeśli używasz Git)
Chociaż korzystanie z Gita zapewnia potężny sposób zarządzania zmianami w kodzie i ich przywracania, nie jest złym pomysłem tworzenie także ręcznych kopii zapasowych. Za każdym razem, gdy osiągniesz kamień milowy w swoim kodzie, sugeruję zapisanie kopii głównych plików kodu w innym folderze:
Może to służyć jako dodatkowe zabezpieczenie, umożliwiające łatwy powrót do poprzedniej, lepszej wersji, jeśli napotkasz poważne błędy podczas kontynuowania kompilacji.
Nie poddawaj się łatwo, ale poznaj swoje ograniczenia
Mogą istnieć pewne funkcje lub poprawki, których po prostu nie będziesz w stanie wdrożyć, niezależnie od tego, jak bardzo się starasz. Bądź przygotowany na dostosowanie swoich oczekiwań i obejście ich . Nie oznacza to jednak poddania się, jeśli uderzysz w ścianę. Oznacza to jednak, że jeśli podjąłeś 100 prób i spędziłeś godziny (lub dni) próbując osiągnąć coś bez powodzenia, prawdopodobnie jest to albo niemożliwe, albo wykracza poza możliwości zarówno Ciebie, jak i ChatGPT.
Na koniec, jeśli zastanawiasz się, czy najpierw powinieneś debugować, czy lintować, według mnie nie ma jednoznacznej odpowiedzi. Debugowałem, zanim zacząłem lintować, ale możesz albo domyślnie wybrać preferencje ChatGPT w trakcie procesu, albo powiedzieć, co chcesz zrobić jako pierwsze.
Faza szósta (opcjonalnie): testowanie 🔬
Jeśli budujesz stosunkowo prostą wtyczkę i masz pewność co do jej funkcjonalności w oparciu o własne ręczne testy, niekoniecznie musisz wykonywać ten krok. Mówię to, ponieważ kodowanie tych testów wymaga nadal dużo pracy i w ten sam sposób, w jaki nie otrzymasz działającej wtyczki za pomocą ChatGPT, jest również mało prawdopodobne, że otrzymasz test funkcjonalny bez błędów.
Mówiąc najprościej, istnieje kompromis pomiędzy inwestycją czasu a wartością praktyczną .
Z własnego doświadczenia udało mi się zbudować jeden test, który sprawdzał, czy moje wtyczki są w stanie wykonywać swoje główne funkcje, gdy użytkownik z nimi wchodzi w interakcję – ale debugowanie zajęło mi cały dzień!
Z praktycznego punktu widzenia już ręcznie sprawdziłem funkcjonalność mojej wtyczki, ale miło było zobaczyć, że test potwierdził, że wszystko działa.
Jeśli zamierzasz zbudować bardziej złożoną wtyczkę niż ja lub jeśli funkcje Twojej wtyczki będą skupione na zapleczu (gdzie nie możesz ręcznie sprawdzić, czy działają, czy nie), poświęć trochę czasu na prawidłowo przeprowadzone testy są warte pracy fizycznej.
Rodzaje testów
Narzędzia do rozważenia
Faza siódma (opcjonalnie): prześlij swoją wtyczkę do repozytorium WordPress 🥳
Jeśli dotarłeś do tego punktu, pomyślnie wspiąłeś się na przysłowiową górę wtyczek. Jedyne, co pozostało do zrobienia, to umieścić swoją flagę tak, aby dołączyła do pozostałych 59 650 wtyczek w repozytorium WordPress.
Ma to swój własny, odrębny proces, któremu towarzyszy lista kontrolna na stronie Dodaj swoją wtyczkę:
- Przeczytaj często zadawane pytania.
- Przestrzegaj wszystkich Wytycznych dla programistów wtyczek.
- Upewnij się, że masz pozwolenie na przesłanie wtyczki do WordPress.org, aby inni mogli z niej korzystać i udostępniać.
- Twoja wtyczka, łącznie ze wszystkimi jej bibliotekami i wszelkimi innymi zawartymi w niej zasobami, jest objęta licencją GPL lub jest kompatybilna z GPL.
- Wykonujesz ostatnią rundę testów z wtyczką Plugin Check i rozwiązujesz wszystkie wskazane problemy (z wyjątkiem tych, które Twoim zdaniem są fałszywie pozytywne).
Sprawdzanie wtyczek (PCP)Aktualna wersja: 1.1.0
Ostatnia aktualizacja: 28 sierpnia 2024 r
plugin-check.1.1.0.zip
Możesz pomyśleć, że po całym debugowaniu, lintingu i testowaniu, które wykonałeś, wtyczka, o użycie której cię proszą, niczego nie wykryje. Jednakże, jako programista wtyczek, który dopiero zaczyna działać, prawdopodobnie będziesz miał kilka nierozwiązanych problemów do rozwiązania – zwłaszcza jeśli nie usuniesz plików testowych ze swojej kompilacji przed uruchomieniem sprawdzania.
Aby kontynuować, przejdź do Narzędzia → Sprawdzanie wtyczek :
Następnie zaznacz wszystkie pięć kategorii i uruchom sprawdzanie:
Następnie możesz przekazać te nierozstrzygnięte problemy do ChatGPT i je rozwiązać. Po zakończeniu uruchom ponownie sprawdzanie, aby upewnić się, że wynik jest czysty. Zrób to tyle razy, ile potrzebujesz. Po całkowitym sprawdzeniu (z wyłączeniem wyników fałszywych alarmów) możesz przesłać wtyczkę do zespołu programistów WordPress. Następnie poczekaj cierpliwie, aż to sprawdzą.
Ostatnie przemyślenia 🧠
Chociaż tworzenie wtyczki za pomocą ChatGPT jest zabawnym i satysfakcjonującym procesem, w żadnym wypadku nie jest to proces szybki. Aby stworzyć przyzwoicie działający produkt końcowy, trzeba włożyć dużo wysiłku. Ostatecznie jednak docenisz wszystkie nowe umiejętności, których nauczy Cię udział w tym projekcie.
Oto kilka rzeczy, których się nauczyłem (i Ty też możesz):
- Nauczyłem się poruszać po dysku twardym za pomocą poleceń terminala, a także innych poleceń związanych z procesem tworzenia wtyczki.
- Teraz całkiem dobrze radzę sobie zarówno z Dockerem, jak i Local by Flywheel, z których nigdy nie korzystałem przed tym eksperymentem.
- Znam także wiele narzędzi i skryptów dla programistów, o których istnieniu nawet nie wiedziałem.
- W przeszłości brałem udział w kilku zajęciach w ramach Free Code Camp i Codecademy i choć oba były świetne, czuję, że dzięki ukończeniu tego projektu zdobyłem o wiele więcej praktycznej wiedzy.
- W związku z powyższym mam teraz wiele losowych fragmentów kodu, które przydadzą mi się, jeśli ponownie będę pracować nad czymś podobnym.
- Różnica między zerem a działającą wtyczką jest znacznie mniejsza niż różnica między działającą wtyczką a wtyczką gotową do przesłania. W ciągu kilku dni udało mi się stworzyć działającą wersję wtyczki, ale zajęło mi to kolejne kilka tygodni, zanim wprowadziłem wszystkie poprawki, aby była na tyle dobra, że można ją było przesłać do repozytorium WordPress.
Ogólnie rzecz biorąc, było to jedno z najfajniejszych zajęć, jakie robiłem od dłuższego czasu. Dziękuję za poświęcenie czasu na przeczytanie. Jeśli wykorzystasz którąkolwiek z tych informacji do zbudowania swojej pierwszej wtyczki, zostaw mi komentarz poniżej. Chętnie sprawdzę Twój efekt końcowy.