Narracja korzystania z programu Composer we wtyczce WordPress

Ten utwór został napisany przez gościnnego autora Petera Suhma. Peter jest programistą internetowym z Kraju Duńczyków. Jest twórcą WP Pusher i wielkim uzależnionym od podróży, zabierając ze sobą swoją pracę.

Któregoś dnia opublikowałem na blogu WP Pusher ostrzeżenie o używaniu Composera we wtyczkach WordPress. Ten post spotkał się z dużym zainteresowaniem i czuję potrzebę wyjaśnienia kilku punktów, z których nie wszystkie były jasne dla wszystkich. Artykuł był również nieco ciężki w kwestiach technicznych, więc w tym poście postaram się wyjaśnić mój główny punkt widzenia, używając prostej narracji, aby to zilustrować.

Narracja

Wyobraźmy sobie przez chwilę, że oboje jesteśmy autorami wtyczek. Oboje mamy świetny pomysł na wtyczkę, którą chcemy rozpowszechniać za pośrednictwem WordPress.org. Chcemy dołączyć kilka funkcji premium do naszych wtyczek, które użytkownicy darmowej wersji mogą odblokować, wprowadzając klucz licencyjny.

Potrzebujemy kodu, który poradzi sobie z tym procesem. Oboje zdajemy sobie sprawę, że problem ten prawdopodobnie już rozwiązał ktoś inny. Nikt z nas nie jest fanem odkrywania koła na nowo, więc idziemy do Packagist i wpisujemy „menedżer licencji”. Wygląda na to, że nasze założenie było uzasadnione. Yoast ma już pakiet, który sobie z tym poradzi. Oboje decydujemy się na szybki composer require yoast/license-manager . Bułka z masłem. Teraz możemy przejść do pracy nad czymś, co naprawdę ma znaczenie — podstawowymi funkcjami naszych wtyczek.

Szybko do przodu, gotowy do wydania wtyczki, zdajesz sobie sprawę, że: Twój użytkownik niekoniecznie musi mieć pod ręką Composer podczas instalowania wtyczki z WordPress.org, więc w jaki sposób uzyska kod dla menedżera licencji? Ta sytuacja jest trochę irytująca, ponieważ jedynym rozwiązaniem, które naprawdę widzisz, jest po prostu zatwierdzenie całego katalogu vendor wygenerowanego przez Composer do wtyczki i przekazanie go do WordPress.org. Wiesz, że nie tak ma działać Composer, ale co tam. Tak naprawdę nie masz innych opcji.

Tymczasem doszedłem do tego samego wniosku z moją wtyczką. Wystarczy dołączyć kod menedżera licencji i skończyć z tym.

Ponownie szybko do przodu, obie nasze wtyczki są teraz dostępne w repozytorium WordPress.org i raz na jakiś czas ktoś decyduje się na uaktualnienie do naszych wersji premium. Wszystko wydaje się być w porządku i oboje jesteśmy wdzięczni, że mogliśmy po prostu użyć kodu, który Yoast hojnie udostępnił jako open source i nie musieliśmy wymyślać koła na nowo.

Pewnego dnia otrzymujesz dziwny e-mail. Klient doświadcza naprawdę dziwnego zachowania podczas próby odblokowania funkcji premium. To nie ma dla ciebie sensu, ponieważ nikt inny tego nie zgłosił. Po godzinach debugowania w końcu prosisz klienta, aby dezaktywował wszystko inne, z wyjątkiem wtyczki, a następnie: To działa! Hmm. Twoja wtyczka wydaje się być w jakiś sposób niekompatybilna z inną wtyczką. Moja wtyczka.

Zdajesz sobie z tego sprawę po godzinach przeglądania kodu źródłowego wszystkich innych wtyczek, które zainstalował klient. Kiedy zdajesz sobie sprawę, że oboje korzystamy z menedżera licencji, zadzwoni dzwonek. Czy to naprawdę może być to? Jeśli tak, to dlaczego nie ma fatal errors: cannot redeclare class ?

Tydzień wcześniej podbiłem wymaganą wersję menedżera licencji we wtyczce do najnowszej wersji, która zawierała kilka (fikcyjnych) przełomowych zmian. Po jeszcze większym debugowaniu i var_dump() 'ing, zdajesz sobie sprawę, że moja wersja menedżera licencji jest również wersją załadowaną przez PHP do twojej wtyczki. Uważasz to za naprawdę dziwne, ponieważ specjalnie wymagałeś innej wersji menedżera licencji z Composerem. Naprawdę nie wiesz, co z tym zrobić.

Ponieważ naprawdę niewiele można z tym zrobić.

Co tu się stało?

Teraz, gdy wszyscy widzieliśmy problem, poświęćmy chwilę, aby przejść przez to, co faktycznie wydarzyło się w narracji. Po pierwsze, dlaczego PHP nie spowodowało krytycznego błędu, skoro dwie klasy oczywiście miały taką samą nazwę, że oboje włączyliśmy menedżera licencji?

Powodem tego jest to, że użyliśmy autoloadera wygenerowanego przez Composer. Ten autoloader skanuje strukturę katalogów naszych zależności i dodaje każdą klasę do autoloadera. Jeśli klasa została już dodana, Composer ją zignoruje. Bezgłośnie. Napisałem mały przykład kodu, jeśli chcesz to zobaczyć na własne oczy. Jest na GitHub.

Dlaczego moja wersja menedżera licencji została dołączona przed twoją?

Stało się tak, ponieważ moja wtyczka miała nazwę, która spowodowała, że ​​została załadowana przed twoją. Być może w przyszłości wszyscy nazwiemy nasze wtyczki „Aaaaaa My Plugin”, aby były ładowane jako pierwsze!

Podsumowując, głównym problemem jest to, że nie będziemy wiedzieć, która wersja naszych zależności jest dla nas dostępna w jakim czasie. Zależy to po prostu od czynników, których nie możemy w pełni kontrolować jako twórcy wtyczek.

Czy jest to problem związany z kompozytorem?

Nie. Naprawdę nie jest. WordPress nie ma sposobu na radzenie sobie z kodem stron trzecich we wtyczkach lub motywach. Na tym polega problem. Powodem, dla którego mówię o Composerze, jest to, że w dzisiejszych czasach zyskuje na popularności. Jeśli programiści WordPressa chcą używać Composera we wtyczkach udostępnianych za pośrednictwem WordPress.org, należy to jakoś rozwiązać. W przeciwnym razie zobaczymy prawdziwy chaos, gdy wszystkie wtyczki zaczną być ze sobą niekompatybilne, ponieważ używają różnych wersji. Witaj w piekle debugowania.

Co możemy z tym zrobić?

Ktoś, kto był tym naprawdę zaniepokojony i ciężko pracował, aby znaleźć potencjalne rozwiązanie, to Coen Jacobs. Postanowiłem skontaktować się z Coenem i zapytać go, czy sądzi, że możemy coś z tym zrobić.

Wielu programistów dołącza już kod stron trzecich do swoich wtyczek. Czy to naprawdę problem?

Tak, to już jest problem w ekosystemie wtyczek. Będzie jeszcze gorzej, gdy więcej osób uzna, że ​​dobrym pomysłem jest umieszczenie wspólnej funkcjonalności w osobnych pakietach. Te pakiety można następnie połączyć z wieloma wtyczkami, a problem będzie pojawiał się coraz częściej. Rozmawiałem z kilkoma programistami, którzy już przeszli przez piekło debugowania, próbując dowiedzieć się, co powoduje ten problem.

Idąc dalej, czy sugerowałbyś, aby programiści przestali dołączać kod stron trzecich do swoich wtyczek?

Jestem trochę rozdarty na ten temat. Z punktu widzenia programistów nie ma sensu mówienie ludziom, aby przestali dołączać współdzielone pakiety do swoich wtyczek. Z drugiej strony, każdy chce jak najlepszego doświadczenia dla swoich użytkowników. To na pewno trudna decyzja.

W tym momencie chcę popchnąć rozwój związany z WordPressem. Chcę udostępniać biblioteki i korzystać z bibliotek udostępnionych przez innych. Nikt nie powinien ciągle wymyślać koła na nowo. Więc zaryzykowałbym wpadnięcie w takie problemy, rozwiązując problemy, gdy się pojawiają.

Oznacza to również, że zrobię co w mojej mocy, aby znaleźć długoterminowe rozwiązanie tego problemu. Więcej osób zacznie korzystać z Composera, więcej osób połączy biblioteki ze swoimi wtyczkami. Ten problem będzie pojawiał się częściej, więc czas go naprawić.

Co mogą zrobić twórcy wtyczek, aby zapobiec temu problemowi?

Istnieje obejście, którego niektórzy już używają. Zasadniczo sprowadza się to do przeniesienia zależności do przestrzeni nazw wtyczki. Danny van Kooten zrobił to dla jednej ze swoich wtyczek. Nie jest to jednak idealne rozwiązanie. Za każdym razem, gdy aktualizuje swoje zależności, musi przejrzeć wszystkie pliki i ponownie zmienić przestrzenie nazw. Teraz nie jest to tak duże zadanie dla stosunkowo małej biblioteki, jak Pimple, ale ogromne przedsięwzięcie dla większych bibliotek.

Można to zrobić tylko z przestrzeniami nazw, więc musisz sprawić, by twoja wtyczka również wymagała PHP 5.3+. Nie będę kłamał, myślę, że każda wtyczka powinna zacząć to robić prędzej czy później, ale zdecydowanie jest to coś, co musisz wziąć pod uwagę, kiedy zdecydujesz się to zrobić.

Jakie byłoby idealne rozwiązanie, jeśli istnieje?

Idealną sytuacją byłoby użycie jakiegoś menedżera zależności. Jest oczywiście Composer, najczęściej używany menedżer zależności. Composer jest bardzo trudny, jeśli nie niemożliwy w użyciu dla zdecydowanej większości użytkowników WordPressa. W końcu to narzędzie dla programistów.

WordPress powinien to ułatwić użytkownikom końcowym, jednocześnie umożliwiając programistom korzystanie z praktycznie każdego pakietu, jaki tylko zechcą. Z tej myśli zacząłem składać wtyczkę WordPress Composer Installer, która wykonuje całą ciężką pracę Composera, podczas gdy ludzie instalują wtyczki tak, jak zawsze. Jak tylko będę w stanie to dokończyć, zintegruję go poprawnie z całym przepływem instalatora wtyczek.

Teraz może pewnego dnia będzie można to zintegrować z głównym WordPressem. Przed nami długa droga, ale weryfikacja koncepcji już działa.

Wniosek

Jeśli czytałeś do tej pory, przede wszystkim: Dziękuję. Po drugie, mam nadzieję, że teraz widzisz, jak to w końcu stanie się problemem. Nasza obecna sytuacja jest bardzo frustrująca, ponieważ po prostu nie mamy potrzebnych nam narzędzi. Mimo to uważam, że ważne jest, abyśmy nadal o tym rozmawiali i upewnili się, że wszyscy, jako programiści WordPress, rozumiemy potencjalne problemy spowodowane konfliktowymi zależnościami stron trzecich w naszym kodzie.

Na koniec chcę jeszcze raz wspomnieć, że nie jest to sprawa kompozytora. To problem WordPressa.