WordPress-widgetit: Refaktorointi, osa 6

Sinun pitäisi olla perehtynyt WordPress Widget Boilerplaten uudelleenjärjestelyyn. Jos ei, suosittelen seuraamaan sarjaa tähän mennessä:

• lue edellinen viesti ,
• tai lukea koko sarja tähän asti,
• ja tarkastellaan projektin kehityshaaraa GitHubissa.

Koodikannan osalta olemme tällä hetkellä hyvässä paikassa. Olemme alkaneet jakaa suuren osan koodista pienempiin, keskittyneempiin luokkiin. Ja olemme juuri perustaneet rekisterin, jotta voimme aloittaa työskentelyn objektien esiintymien kanssa kaikkialla laajennuksena ilman liiallista kytkentää.

Mutta meillä on edelleen ongelma, joka koskee nimiavaruuksia ja automaattista latausta. Olen puhunut tästä vähän pari vuotta sitten, mutta en niin kuin se liittyy Composeriin.

Ja sitä aiomme tarkastella tässä viestissä.

WordPress Widget Boilerplate: Refactoring, osa 6

Tämän sarjan toisessa viestissä aloimme puhua säveltäjästä. Jos kysyt useimmilta PHP-kehittäjiltä (mukaan lukien ne, jotka työskentelevät WordPressissä), kuulet todennäköisesti, että Composer on paketinhallinta tai riippuvuushallinta.

Lyhyesti sanottuna se on tapa, jolla voimme tuoda kolmannen osapuolen kirjastoja projektiimme ja sitten hyödyntää niiden ominaisuuksia (joten meidän ei tarvitse kirjoittaa omaa koodia tehdäksemme niin).

Mutta on toinenkin Composerin tarjoama ominaisuus, joka on valtava hyödyllinen, varsinkin kun käytät paljon luokkia etkä halua käyttää request_once -lauseita koko koodipohjassasi.

Ja se on automaattinen lataus.

Autoloader määritetty

Suoraan ohjekirjasta:

Kirjastoille, jotka määrittävät automaattisen lataustiedot, Composer luo vendor/autoload.phptiedoston. Voit yksinkertaisesti sisällyttää tämän tiedoston ja alkaa käyttää näiden kirjastojen tarjoamia luokkia ilman ylimääräistä työtä:

Jos olet seurannut koodia tähän asti, huomaat, että käytämme itse asiassa jo Composerin luomaa automaattista latausohjelmaa.

Ensin määritimme tarvittavat kokoonpanot :

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

Sitten aloimme sisällyttää sen laajennuksen bootstrapiin (jonka viimeistelemme tänään):

Mutta tässä on ongelma: Kuinka lataamme vain jakelua varten tarvitsemamme luokat?

Toisin sanoen: Kehitysvaiheessa käytämme monia kirjastoja varmistaaksemme, että kirjoitamme korkealaatuista, standardien mukaista koodia. Emme kuitenkaan halua jakaa 10 megatavua dataa niille, jotka käyttävät projektiamme.

Sen sijaan meidän on sisällytettävä vain vaaditut tiedostot, eikö niin? Ja tehdäksemme sen, meidän on varmistettava, että luomme automaattisen latausohjelman, jonka voimme sisällyttää ja joka tekee juuri sen.

Ensin näytän sinulle komennon ja sitten selitän, mitä se tekee:

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

Tämä tuottaa juuri sen, mitä tarvitsemme, jotta projektimme toimisi tuotantoympäristössä. Jokainen lippu tekee näin:

• säveltäjän asennus. Tämä yksinkertaisesti asentaa kaikki riippuvuudet. Jos sinulla on jo useita niitä toimittajahakemistossasi, tämä poistaa kaikki paitsi pakolliset.
• no-dev. Tämä estää Composeria asentamasta paketteja määritystiedostojensa require-dev- osioon (eli riippuvuuksiin, joita käytämme GrumPHP:n kanssa).
• ei-ansi. Tämä estää ANSI-lähdön esiintymisen. Et ehkä välitä suorittaako tätä tai et. Jos päätät tehdä jonkinlaisen automaattisen käyttöönoton, käytä sitä; muuten se voidaan jättää pois komennosta.
• ei vuorovaikutusta. Tämä on toinen lippu, jota käytetään erityisesti ympäristöissä, joissa haluat rakentaa projektin automaattisesti, eikä sinun tarvitse olla tekemisissä kysymysten, tulosten ja vastaavien kanssa.
• optimoi-autoloader. Lyhyesti sanottuna tämä luo nopeamman automaattilataimen. Sen suorittaminen voi kestää jonkin aikaa projektin koosta riippuen, mutta se kannattaa, kun aloitat työn.
• ei edistystä. Tämä piilottaa edistymispalkin näkymästä terminaalissa. Haluat ehkä itse nähdä tämän, ja jos on, niin se on hienoa; Jotkin ympäristöt eivät kuitenkaan välttämättä käsittele tiettyjä merkkejä (kuten askelpalautinta) hyvin.
• mieluummin-dist. Tämä varmistaa, että asennetut paketit on tehty jakeluversiolla (verrattuna johonkin, joka on vähemmän vakaa).

Oletko edelleen kiinnostunut?

Jos olet todella utelias optimoimaan automaattinen latausohjelma tämän viestin ulkopuolisille projekteille, suosittelen lukemaan tämän sivun Composer-dokumentaatiosta. Se ei kuulu toimintamme piiriin, mutta siitä voi olla hyötyä muun työn kanssa, joka sinulla on nyt tai mitä teet tulevaisuudessa.

Miltä tämä näyttää kattilalevyssä?

Jos työskentelet Boilerplaten parissa paikallisella koneellasi, saatat nähdä jotain tällaista:

Mutta jos suoritat yllä olevan komennon, näet jotain tällaista:

Se on iso ero ja tämä on pieni projekti. Kuvittele, että teet jotain paljon suurempaa, joka tulee toimimaan tuotannossa.

Kokemuksesta voin kertoa, että projektit voivat nopeasti saavuttaa 20 Mt tai enemmän riippuvuuksia, jos käytät erilaisia ​​kolmannen osapuolen kirjastoja esimerkiksi lokiin, HTTP-pyyntöihin ja koodinlaatutyökaluihin.

Sisällytämmekö toimittajaluetteloomme?

Ihmiset sanovat usein, että sinun ei pitäisi sisällyttää toimittajahakemistoa lähdehallintaan ja hyvästä syystä: Se voi olla valtava.

Jopa säveltäjän dokumentaatiossa puhutaan tästä:

Paras käytäntö on, että kaikki kehittäjät käyttävät Composeria riippuvuuksien asentamiseen. Samoin koontipalvelin, CI, käyttöönottotyökalut jne. tulisi mukauttaa suorittamaan Composeria osana projektin käynnistystä.

Joten mitä meidän pitäisi tehdä? Tarvitsemme automaattisen latausohjelman ja tiettyjä riippuvuuksia, koska käyttäjämme eivät tiedä suorittavansa (eikä heidän tarvitse suorittaa!) Composeria aina kun he lataavat töitämme.

WordPressin luonteen ja tekemämme työn vuoksi meidän on sitouduttava toimittajahakemistoon, mutta vain hyvin tietyin vaatimuksin.

1. Luomme haaran, jota käytetään julkaisuun (kutsumme sitä luovasti julkaisuksi ja voimme yhdistää siihen kehitystä tarvittaessa).
2. Varmistamme, että toimittajahakemisto ei ole osa gitignore-tiedostoa; Varmistamme kuitenkin, että toimittajahakemiston .git-hakemistot jätetään huomiotta (se voi silti viedä paljon tilaa).

Tehdään siis jokainen vaihe ja katsotaan, miltä se näyttää, kun olemme valmiit.

Julkaisuhaaran luominen

Luo uusi haara terminaalista antamalla seuraava komento :

$ git checkout -b release

Tämä ottaa kaiken koodin, jonka parissa työskentelemme, ja luo sen kanssa uuden haaran. Koska tämä on haara, jota käytämme toimimaan kuten käyttäjämme käyttävät (puhumme mestarista seuraavassa postauksessa).

Tarkista ensin composer.json-tiedostosi ja varmista, että se sisältää seuraavat tiedot:

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

Nyt meidän on varmistettava, että suoritamme yllä olevan Composer-komennon varmistaaksemme, että toimittajahakemistossa ei ole mitään muuta kuin mitä tarvitsemme .

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

Nyt meidän on päivitettävä gitignore.

Päivitämme huomiotta

Ja jos olet seurannut sekä sarjaa että julkaisua tähän asti, tiedät sen näyttävän suunnilleen tältä (se voi sisältää enemmän tai vähemmän, mutta sen pitäisi sisältää ainakin tämä).

Minulle tämä näyttää tältä :

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

Riippuen siitä, käytätkö päätettä vai asiakasta, näet, että uusia tiedostoja on sitova (erityisesti toimittajahakemistosta). Joten lisää ne haaraasi.

Tee sitten tekemäsi muutokset. Sinun on ehkä määritettävä seuraavat, jos työskentelet terminaalissa:

$ git push --set-upstream origin release

Ja sen myötä koodisi pitäisi toimia ja olla saatavilla GitHubissa (tai missä tahansa käyttämässäsi lähteenhallintapalvelussa). Täältä näet mitä minulla on tarjolla .

Toiminnan lisääminen

Nyt kun meillä on kaikki tarvittavat osat paikoillaan, on aika alkaa käyttää Composeria, automaattista latausohjelmaa, abstrakteja luokkiamme ja rekisteriä ja aloittaa perustoimintojen lisääminen WordPress Widget Boilerplateen, jotta meillä on jotain näytettävää työssämme. .

Niille, jotka ovat uteliaita, aion juuri nyt pitää konttorit järjestettynä:

• master on se, mikä on saatavilla kaikille ja kaikille, jotka haluavat rakentaa WordPress-widgetin,
• kehittäminen on tarkoitettu vain kehittäjille, mukaan lukien ne, jotka osaavat käyttää Composeria ja tässä viestissä käsiteltyjä aiheita,
• julkaisua käytetään toimivan demon tarjoamiseen.

Tarkista kuitenkin toistaiseksi, mitä tämä viesti sisältää, ja jatkamme sitä seuraavassa viestissä.