WordPress-widgets: Refactoring, del 6

Du bör vara väl insatt i den omstrukturering vi gör angående WordPress Widget Boilerplate. Om inte, rekommenderar jag att du kommer ikapp serien hittills genom att:

• läser förra inlägget ,
• eller läser hela serien fram till denna punkt,
• och tittar på utvecklingsgrenen av projektet på GitHub.

När det gäller kodbasen är vi på en bra plats just nu. Vi har börjat omstrukturera mycket av koden till mindre, mer fokuserade klasser. Och vi har precis satt upp ett register så att vi kan börja arbeta med instanser av objekt i hela plugin-programmet utan att behöva för mycket koppling.

Men det finns fortfarande ett problem vi står inför och det handlar om namnutrymmen och automatisk laddning. Jag har pratat lite om detta för ett par år sedan men inte när det gäller Composer.

Och det är vad vi ska titta på i det här inlägget.

WordPress Widget Boilerplate: Refactoring, del 6

I det andra inlägget i den här serien började vi prata om kompositör. Om du frågar de flesta PHP-utvecklare (inklusive de som arbetar med WordPress), kommer du sannolikt att höra att Composer är en pakethanterare eller en beroendehanterare.

Kort sagt, det är ett sätt för oss att ta med tredje parts bibliotek i vårt projekt och sedan använda deras funktioner (så att vi inte behöver skriva vår egen kod för att göra det).

Men det finns en annan funktion som Composer erbjuder som är enormt användbar, speciellt när du använder många klasser och inte vill använda require_once-satser i hela din kodbas.

Och det är autoloadern.

Autoloader Defined

Direkt från manualen:

För bibliotek som anger autoload-information genererar Composer en vendor/autoload.phpfil. Du kan helt enkelt inkludera den här filen och börja använda klasserna som dessa bibliotek tillhandahåller utan extra arbete:

Om du har följt med koden hittills, kommer du att se att vi faktiskt redan använder autoloader som genereras av Composer.

Först definierade vi den nödvändiga konfigurationen :

{
    "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"
  }

Sedan började vi inkludera det i pluginets bootstrap (som vi kommer att slutföra idag):

Men det finns ett problem här: Hur laddar vi bara de klasser vi behöver för distribution?

För att uttrycka det på ett annat sätt: Det finns många bibliotek vi använder under utveckling för att säkerställa att vi skriver högkvalitativ, standardkompatibel kod. Men vi vill inte distribuera 10 MB data till de som använder vårt projekt.

Istället behöver vi bara inkludera de filer som krävs, eller hur? Och för att göra det måste vi se till att vi genererar en autoloader som vi kan inkludera som gör just det.

Först ska jag visa dig kommandot och förklara sedan vad det gör:

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

Detta kommer att generera precis vad vi behöver för att vårt projekt ska fungera i en produktionsmiljö. Så här gör varje flagga:

• kompositör installera. Detta installerar helt enkelt alla beroenden. Om du redan har ett antal av dem i din leverantörskatalog kommer detta att ta bort alla utom de som krävs.
• no-dev. Detta kommer att förhindra Composer från att installera paketen i sektionen require-dev i dess konfigurationsfiler (nämligen beroenden som vi använder med GrumPHP).
• no-ansi. Detta förhindrar att någon ANSI-utgång uppstår. Du kanske inte bryr dig om att köra detta eller inte. Om du väljer att göra någon typ av automatisk distribution, använd den då; annars kan det utelämnas från kommandot.
• ingen interaktion. Det här är en annan flagga som används specifikt för miljöer där du vill bygga projektet automatiskt och inte behöver engagera dig i några frågor, utdata och sådana saker.
• optimize-autoloader. Kort sagt, detta genererar en snabbare autoloader. Det kan ta lite tid att köra beroende på storleken på ditt projekt men det lönar sig när du startar ditt arbete.
• inga framsteg. Detta döljer förloppsindikatorn från att visas i terminalen. Du kanske faktiskt vill se detta och i så fall är det jättebra; dock kanske vissa miljöer inte hanterar vissa tecken (som backsteg) bra.
• föredra-dist. Detta kommer att se till att paketen som installeras görs med distributionsversionen (mot något som är mindre stabilt).

Fortfarande intresserad?

Om du verkligen är nyfiken på att optimera autoloadern för projekt utanför detta inlägg rekommenderar jag att du läser den här sidan i Composer-dokumentationen. Det ligger utanför ramarna för vad vi gör här men det kan komma väl till pass med annat arbete som du har nu eller som du gör i framtiden.

Hur ser det här ut i Boilerplate?

Om du arbetar med Boilerplate på din lokala maskin kan du se något i stil med detta:

Men om du kör kommandot som ingår ovan kommer du att se något så här:

Det är en stor skillnad och det här är ett litet projekt. Föreställ dig att göra något mycket större som kommer att köras i produktion.

På tal av erfarenhet kan jag berätta att projekt snabbt kan nå 20 MB eller mer av beroenden om du använder en mängd olika tredjepartsbibliotek för saker som loggning, HTTP-förfrågningar och kodkvalitetsverktyg.

Kommer vi att inkludera i vår leverantörskatalog?

Folk kommer ofta att säga att du inte bör inkludera leverantörskatalogen i källkontroll och med goda skäl: det kan vara enormt.

Till och med kompositörens dokumentation talar om detta:

Det bästa är att sedan låta alla utvecklare använda Composer för att installera beroenden. På samma sätt bör byggservern, CI, distributionsverktyg etc anpassas för att köra Composer som en del av deras projektstart.

Så vad ska vi göra? Vi behöver autoloadern och vi behöver vissa beroenden eftersom våra användare inte vet att köra (inte heller ska de behöva köra!) Composer när de laddar ner vårt arbete.

På grund av WordPresss natur och det arbete vi gör, kommer vi att behöva bestämma leverantörskatalogen men bara med mycket vissa krav.

1. Vi kommer att skapa en gren som kommer att användas för release (vi kommer kreativt att kalla det release och vi kan slå samman utvecklas till det när det behövs).
2. Vi kommer att se till att leverantörskatalogen inte är en del av gitignore-filen; vi kommer dock att se till att .git-katalogerna i leverantörskatalogen ignoreras (som fortfarande kan ta upp mycket utrymme).

Så låt oss göra varje steg och se hur det ser ut när vi är klara.

Skapar utgivningsgrenen

För att skapa en ny gren från terminalen, skriv in följande kommando :

$ git checkout -b release

Detta tar all kod som vi arbetar med och skapar sedan en ny gren med den. Eftersom detta kommer att vara den gren vi använder för att fungera som vad våra användare kommer att använda (vi kommer att prata om master i ett framtida inlägg).

Granska först din composer.json-fil och se till att den innehåller följande:

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

Nu måste vi se till att vi kör ovanstående Composer-kommando för att se till att inget annat än det vi behöver finns i leverantörskatalogen.

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

Nu måste vi uppdatera gitignore.

Uppdatera vad vi ignorerar

Och om du har följt både med serien och inlägget så här långt, så vet du att det kommer att se ut ungefär så här (det kan innehålla mer eller mindre men bör innehålla åtminstone detta).

För mig ser det ut som följande :

*.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

Beroende på om du använder en terminal eller en klient, kommer du att se att det finns nya filer att commit (från leverantörskatalogen, specifikt). Så lägg till dem i din filial.

Gör sedan dina ändringar. Du kan behöva ange följande om du arbetar i terminalen:

$ git push --set-upstream origin release

Och med det borde din kod fungera och vara tillgänglig på GitHub (eller vilken källkontrolltjänst du än använder). Du kan se vad jag har tillgängligt här.

Lägger till funktionalitet

Nu när vi har alla nödvändiga delar på plats är det dags att börja använda Composer, autoloadern, våra abstrakta klasser och vårt register för att börja lägga till några grundläggande funktioner till WordPress Widget Boilerplate så att vi har något att visa för vårt arbete .

För den som är nyfiken planerar jag just nu att hålla grenarna organiserade som sådana:

• master kommer att vara det som är tillgängligt för alla och alla som vill bygga en WordPress-widget,
• utveckla är strikt för utvecklare, inklusive de som vet hur man använder Composer och de ämnen som diskuteras i det här inlägget,
• release är vad som kommer att användas för att tillhandahålla en fungerande demo.

För nu, dock, granska vad som tas upp i det här inlägget så återupptar vi detta i nästa inlägg.