Spis treści
Zrobiłem to i Ty też możesz!
Nigdy nie uważałem się za zawodowego developera WordPress. Potrafię czytać kod, coś poprawić, dopisać kawałek PHP, ale nie jestem osobą, która na co dzień siedzi w edytorze i refaktoryzuje klasy. Mimo to napisałem wtyczkę, która przeszła review WordPressa za pierwszym razem. Jak? Z pomocą sztucznej inteligencji, a dokładnie, Google AI Studio. I, co ważniejsze, z uważnym podejściem do zasad, które obowiązują przy publikacji wtyczek w oficjalnym repozytorium.
Wtyczka do WordPressa
Wszystko zaczęło się od potrzeby. Chciałem stworzyć narzędzie, które automatycznie generuje wpis w WordPressie na podstawie samego tytułu. Czyli, wpisujesz tytuł, a treść tworzy się sama, przy użyciu API AI. Taki prosty generator treści zasilany AI. Sam pomysł nie był specjalnie oryginalny bo podobne rozwiązania już istnieją, ale zależało mi na czymś lekkim, własnym, bez ciężkich edytorów i bez integracji z płatnymi API. Uznałem, że Google Gemini API będzie dobrym punktem startowym. I tu pojawiła się okazja na stworzenie wtyczki, która to wszystko ogarnie. Sam tego nie pisałem linijka po linijce. Zleciłem to Gemini w AI Studio, formułując precyzyjne polecenia i iterując kod. To AI napisało mi gotowy plugin. Moim zadaniem było go poprawić, przystosować do realiów WordPressa i przygotować tak, by przeszedł przez sito review.
Automatyczny review
Na początku myślałem, że wystarczy wrzucić gotowy kod, opisać, o co chodzi i czekać na zatwierdzenie. Szybko zderzyłem się z rzeczywistością. Pierwsza automatyczna wiadomość z systemu review zatrzymała publikację z kilku powodów: zła nazwa, brak opisu po angielsku, potencjalny konflikt z biblioteką i brak prefiksów. Nie był to dramat, ale jasny sygnał, że tu nie wystarczy bo „działa lokalnie”.
Pierwsza rzecz, którą poprawiłem, to nazwa i slug. Wtyczka miała się pierwotnie nazywać „GeminiPost Generator”, co od razu zostało oznaczone jako ryzyko naruszenia znaku towarowego Google. Zmieniłem więc nazwę na „SkyGenAI” - bardziej neutralną, unikalną i niekojarzącą się z żadną firmą. Dodałem do tego slug skygenai, żeby wszystko było spójne.
Kolejny krok to dokumentacja. Całość opisałem po angielsku - nawet jeśli wtyczka miała być używana głównie lokalnie. Opisałem, co robi, jak działa, jakie ma zależności, gdzie wkleić klucz API. Nie musiałem pisać poematu - wystarczyło jasno przedstawić funkcjonalność i sposób konfiguracji. Dzięki temu reviewer, który będzie ją sprawdzał, od razu wiedział, z czym ma do czynienia.
Trzeci ważny element to prefiksowanie wszystkiego. Google AI Studio wygenerowało kod w czystym PHP, bez żadnych prefiksów. Klasy miały ogólne nazwy, funkcje nazywały się save_post albo generate_content. W świecie WordPressa to przepis na katastrofę, bo każdy plugin działa w jednej, globalnej przestrzeni nazw. Zmieniłem więc wszystkie nazwy na unikalne, dodając prefiks skygenai_. Funkcja save_post stała się skygenai_save_post, a klasa Generator przemieniła się w SKYGENAI_Generator. Nuda? Trochę. Ale bardzo skuteczna.
Wtyczka korzystała też z biblioteki Parsedown do obsługi Markdowna. AI dołączyło ją po prostu jako plik w katalogu wtyczki. Ja dodałem warunek if (!class_exists('Parsedown')), żeby nie ładować jej ponownie, jeśli już istnieje. Dzięki temu uniknąłem potencjalnego konfliktu z innymi wtyczkami, które mogą korzystać z tej samej biblioteki.
Plugin Check (PCP)
Zanim wrzuciłem ZIP z pluginem do systemu, uruchomiłem jeszcze testy przy użyciu oficjalnej wtyczki Plugin Check. To narzędzie działa jak szybki audyt zgodności z wytycznymi WordPressa. Wskazuje potencjalne problemy z kodem, nieprawidłowe struktury katalogów, brak tłumaczeń czy funkcje używane niezgodnie z dokumentacją. Gdyby nie to narzędzie, pewnie pominąłbym kilka technicznych drobiazgów, które mogłyby opóźnić akceptację. Plugin Check nie załatwia wszystkiego, ale daje bardzo dobry punkt wyjścia. I naprawdę warto go użyć zanim klikniesz „Upload plugin”.
Banner i ikona
Zanim zamknąłem cały temat, musiałem jeszcze przygotować to, co w repozytorium WordPressa widać na pierwszy rzut oka - ikonę i banner pluginu. To niby kosmetyka, ale robi ogromną różnicę. WordPress ma konkretne wymagania: ikona powinna mieć 256x256 lub 512x512 pikseli, natomiast banner dokładnie 772x250 pikseli. Te pliki wrzuca się do katalogu assets/ – równoległego do trunk/. Dzięki temu po zatwierdzeniu pluginu grafiki będą widoczne na stronie wtyczki.
Subversion
Do zarządzania kodem używane jest w repozytorium WordPress.org nie Git, a SVN (Subversion). Ponieważ pracuję na macOS, najwygodniej było mi zainstalować SVN lokalnie przez Homebrew:
brew install subversionPo zatwierdzeniu pluginu przez WordPress otrzymałem unikalny URL do repozytorium. Przeszedłem do katalogu projektu i przygotowałem jego strukturę: trunk/ na bieżące pliki pluginu, tags/ na wersje oraz assets/ na grafikę. W terminalu wykonałem kolejne kroki:
svn add trunk/* --force
svn add assets/* --force
svn commit -m "Initial release: version 1.0.0"Po zalogowaniu do systemu SVN przy użyciu swojego loginu i hasła z WordPress.org, commit przeszedł pomyślnie. Następnie oznaczyłem wersję pluginu jako 1.0.0:
svn cp trunk tags/1.0.0
svn commit -m "Tag version 1.0.0"I tyle. Plugin pojawił się publicznie w repozytorium. Review zakończył się sukcesem! Bez poprawek, bez cofnięć, bez zamieszania.
Zamknięcie tego procesu - od wygenerowania kodu przez AI, przez poprawki, testy, przygotowanie grafik, aż po commit przez SVN - pokazało mi, że naprawdę da się to zrobić bez bycia zawodowym developerem WordPress. Wystarczyło podejść do sprawy metodycznie, przeczytać dokumentację i trzymać się zasad.
Jeśli mnie się udało, bez znajomości SVN, bez pisania kodu od zera, za to z pomocą AI i odrobiny determinacji, to Tobie też się uda. WordPress docenia jakość, nawet jeśli za nią nie stoi agencja czy full-time dev. Wystarczy, że podejdziesz do projektu uczciwie i konsekwentnie. Cała reszta to już tylko narzędzia i dobre praktyki.
