Widżety WordPress: Refaktoryzacja, część 6

Powinieneś być dobrze zorientowany w refaktoryzacji, którą robimy w odniesieniu do WordPress Widget Boilerplate. Jeśli nie, to polecam nadrobić dotychczasowe zaległości w serii o:

• czytanie poprzedniego posta ,
• lub przeczytanie całej serii do tego momentu,
• i przyglądając się gałęzi deweloperskiej projektu na GitHub.

Jeśli chodzi o bazę kodu, jesteśmy teraz w dobrym miejscu. Zaczęliśmy refaktoryzować większość kodu do mniejszych, bardziej skoncentrowanych klas. Właśnie skonfigurowaliśmy Rejestr, abyśmy mogli rozpocząć pracę z instancjami obiektów w całej wtyczce bez potrzeby zbytniego łączenia.

Ale wciąż istnieje problem, z którym się borykamy i dotyczy on przestrzeni nazw i automatycznego ładowania. Mówiłem o tym trochę kilka lat temu, ale nie w odniesieniu do Composera.

I właśnie temu przyjrzymy się w tym poście.

Szablon WordPress Widget: Refaktoryzacja, część 6

W drugim poście z tej serii zaczęliśmy rozmawiać o Composerze. Jeśli zapytasz większość programistów PHP (w tym tych, którzy pracują na WordPressie), prawdopodobnie usłyszysz, że Composer jest menedżerem pakietów lub menedżerem zależności.

Krótko mówiąc, jest to dla nas sposób na wprowadzenie bibliotek innych firm do naszego projektu, a następnie wykorzystanie ich funkcji (więc nie musimy pisać własnego kodu, aby to zrobić).

Ale jest jeszcze jedna funkcja oferowana przez Composer, która jest niezwykle użyteczna, zwłaszcza gdy używasz wielu klas i nie chcesz używać instrukcji require_once w całym kodzie.

I to jest autoloader.

Definicja autoloadera

Prosto z instrukcji:

W przypadku bibliotek, które określają informacje o automatycznym ładowaniu, Composer generuje vendor/autoload.phpplik. Możesz po prostu dołączyć ten plik i zacząć korzystać z klas dostarczanych przez te biblioteki bez dodatkowej pracy:

Jeśli do tej pory śledziłeś ten kod, zobaczysz, że faktycznie używamy już autoloadera wygenerowanego przez Composer.

Najpierw zdefiniowaliśmy niezbędną konfigurację :

{
    "name": "wordpress-widget-boilerplate/wordpress-widget-boilerplate",
    "description": "An organized, maintainable boilerplate for building widgets using WordPress best practices.",
    "type": "wordpress-plugin",
    "license": "GPL-3.0-or-later",
    "homepage": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate",
    "authors": [
      {
        "name": "Tom McFarlin",
        "email": "tom@pressware.co",
        "homepage": "https://pressware.co"
      }
    ],
    "support": {
      "issues": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate/issues"
    },
    "config": {
      "preferred-install": "dist",
      "platform": {
          "php": "7.1"
      }
    },
    "repositories": [
      {
        "type": "composer",
        "url": "https://wpackagist.org"
      }
    ],
    "require": {
      "php": "7.1",
      "composer/installers": "^1.4"
    },
    "require-dev": {
        "friendsofphp/php-cs-fixer": "^2.13.1",
        "jakub-onderka/php-parallel-lint": "^1.0.0",
        "phpmd/phpmd": "^v2.6.0",
        "nikic/php-parser": "^4.0",
        "ocramius/proxy-manager": "^2.0.0",
        "phpro/grumphp": "^0.13.1"
    },
    "scripts": {
      "test": [
        "./vendor/bin/grumphp run"
      ]
    },
    "minimum-stability": "stable"
  }

Następnie zaczęliśmy dołączać go do programu startowego wtyczki (który dokończymy dzisiaj):

Ale tutaj pojawia się problem: jak załadować tylko te klasy, których potrzebujemy do dystrybucji?

Innymi słowy: istnieje wiele bibliotek, których używamy w fazie rozwoju, aby zapewnić pisanie wysokiej jakości kodu zgodnego ze standardami. Ale nie chcemy udostępniać 10 MB danych tym, którzy korzystają z naszego projektu.

Zamiast tego musimy uwzględnić tylko te pliki, które są wymagane, prawda? Aby to zrobić, musimy upewnić się, że generujemy autoloader, który możemy dołączyć, a który właśnie to robi.

Najpierw pokażę ci polecenie, a następnie wyjaśnię, co robi:

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

To wygeneruje dokładnie to, czego potrzebujemy, aby nasz projekt działał w środowisku produkcyjnym. Oto, co robi każda flaga:

• instalacja kompozytora. To po prostu instaluje wszystkie zależności. Jeśli masz już kilka z nich w katalogu dostawców, usunie to wszystkie oprócz tych, które są wymagane.
• bez-dev. Uniemożliwi to Composerowi instalowanie pakietów w sekcji required -dev swoich plików konfiguracyjnych (mianowicie zależności, których używamy z GrumPHP).
• nie ansi. Zapobiega to występowaniu jakichkolwiek danych wyjściowych ANSI. Możesz nie mieć ochoty na to, czy nie. Jeśli zdecydujesz się na jakiś rodzaj automatycznego wdrożenia, użyj go; w przeciwnym razie można go pominąć w poleceniu.
• brak interakcji. Jest to kolejna flaga używana specjalnie w środowiskach, w których chcesz automatycznie budować projekt i nie musisz angażować się w żadne pytania, wyniki i tym podobne.
• zoptymalizuj-autoloader. Krótko mówiąc, generuje to szybszy autoloader. Uruchomienie może trochę potrwać w zależności od rozmiaru projektu, ale opłaca się to po uruchomieniu pracy.
• brak postępu. Dzięki temu pasek postępu nie będzie widoczny w terminalu. Możesz naprawdę chcieć to zobaczyć, a jeśli tak, to świetnie; jednak niektóre środowiska mogą nie obsługiwać dobrze niektórych znaków (takich jak Backspace).
• preferowana odległość. Zapewni to, że pakiety, które są instalowane, są wykonywane przy użyciu wersji dystrybucyjnej (w przeciwieństwie do czegoś, co jest mniej stabilne).

Nadal jesteś zainteresowany?

Jeśli naprawdę interesuje Cię optymalizacja autoloadera dla projektów spoza tego postu, to polecam przeczytanie tej strony w dokumentacji Composera. To wykracza poza zakres tego, co tutaj robimy, ale może się przydać w przypadku innej pracy, którą wykonujesz teraz lub którą wykonujesz w przyszłości.

Jak to wygląda na płycie kotłowej?

Jeśli pracujesz na Boilerplate na lokalnym komputerze, możesz zobaczyć coś takiego:

Ale jeśli uruchomisz powyższe polecenie, zobaczysz coś takiego:

To duża różnica, a to mały projekt. Wyobraź sobie, że robisz coś znacznie większego, co będzie działać w środowisku produkcyjnym.

Mówiąc z doświadczenia, mogę powiedzieć, że projekty mogą szybko osiągnąć 20 MB lub więcej zależności, jeśli używasz różnych bibliotek innych firm do takich rzeczy, jak rejestrowanie, żądania HTTP i narzędzia do jakości kodu.

Czy uwzględnimy w naszym katalogu dostawców?

Ludzie często mówią, że nie należy uwzględniać katalogu dostawców w kontroli źródeł i nie bez powodu: może być ogromny.

Nawet dokumentacja Composera mówi o tym:

Najlepszą praktyką jest, aby wszyscy programiści używali Composera do instalowania zależności. Podobnie serwer kompilacji, CI, narzędzia wdrożeniowe itp. powinny być przystosowane do uruchamiania Composera w ramach ładowania początkowego projektu.

Więc co mamy zrobić? Potrzebujemy autoloadera i potrzebujemy pewnych zależności, ponieważ nasi użytkownicy nie będą wiedzieć, jak uruchomić (ani nie powinni uruchamiać!) Composera za każdym razem, gdy pobierają naszą pracę.

Ze względu na naturę WordPressa i pracę, którą wykonujemy, będziemy musieli zatwierdzić katalog dostawców, ale tylko z bardzo określonymi wymaganiami.

1. Stworzymy gałąź, która będzie używana do wydania (twórczo nazwiemy go wydaniem i możemy w razie potrzeby scalić z nim development).
2. Upewnimy się, że katalog dostawcy nie jest częścią pliku gitignore; jednak upewnimy się, że katalogi .git w katalogu dostawcy są ignorowane (co nadal może zajmować dużo miejsca).

Zróbmy więc każdy krok i zobaczmy, jak wygląda, kiedy skończymy.

Tworzenie gałęzi wydania

Aby utworzyć nową gałąź z poziomu terminala, wprowadź następujące polecenie :

$ git checkout -b release

Spowoduje to zabranie całego kodu, nad którym pracujemy, a następnie utworzenie z nim nowej gałęzi. Ponieważ będzie to gałąź, której używamy do działania jako to, czego będą używać nasi użytkownicy (o masterze porozmawiamy w przyszłym poście).

Najpierw przejrzyj swój plik composer.json i upewnij się, że zawiera on następujące elementy:

"autoload": {
    "psr-4": {
        "WordPressWidgetBoilerplate": "src/",
        "WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
        "WordPressWidgetBoilerplateUtilities": "src/Utilities/",
        "WordPressWidgetBoilerplateViews": "src/Views/"
    }
},

Teraz musimy upewnić się, że uruchamiamy powyższe polecenie Composer, aby upewnić się, że nic poza tym, czego potrzebujemy, nie znajduje się w  katalogu dostawcy.

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Teraz musimy zaktualizować gitignore.

Aktualizacja tego, co ignorujemy

A jeśli śledziłeś zarówno serię, jak i post do tej pory, wiesz, że będzie to wyglądało mniej więcej tak (może zawierać mniej więcej, ale powinno zawierać przynajmniej to).

Dla mnie wygląda to tak :

*.DS_Store
*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php

/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz

/vendor/**/.git
/vendor/bin
composer.lock

W zależności od tego, czy używasz terminala, czy klienta, zobaczysz, że są nowe pliki do zatwierdzenia (w szczególności z katalogu dostawcy). Więc dodaj je do swojej gałęzi.

Następnie zatwierdź swoje zmiany. Jeśli pracujesz w terminalu, może być konieczne określenie następujących danych:

$ git push --set-upstream origin release

A dzięki temu Twój kod powinien działać i być dostępny w GitHub (lub dowolnej usłudze kontroli źródła, z której korzystasz). Możesz zobaczyć, co mam dostępne tutaj.

Dodawanie funkcjonalności

Teraz, gdy mamy już wszystkie niezbędne elementy, nadszedł czas, aby zacząć używać Composer, autoloadera, naszych klas abstrakcyjnych i naszego rejestru, aby rozpocząć dodawanie podstawowych funkcji do WordPress Widget Boilerplate, abyśmy mieli coś do pokazania w naszej pracy .

Dla tych, którzy są ciekawi, w tej chwili planuję uporządkowanie oddziałów w następujący sposób:

• master będzie dostępny dla każdego i każdego, kto chce zbudować widget WordPress,
• development jest przeznaczony wyłącznie dla programistów, w tym tych, którzy wiedzą, jak korzystać z Composera i tematów poruszanych w tym poście,
• wydanie jest tym, co zostanie użyte do udostępnienia działającego demo.

Na razie jednak przejrzyj, co jest omówione w tym poście, a wznowimy to w następnym poście.