WordPressi vidinad: ümbertöötamine, 6. osa

Peaksite olema hästi kursis WordPressi vidina katlaplaadi ümbertöötamisega. Kui ei, siis soovitan seriaaliga tutvuda järgmiselt:

• lugedes eelmist postitust ,
• või lugedes kogu seeriat kuni selle hetkeni,
• ja vaadates projekti arendusharu GitHubis.

Mis puutub koodibaasi, siis oleme praegu heas kohas. Oleme hakanud suurt osa koodist ümber kujundama väiksemateks, rohkem keskendunud klassideks. Ja me oleme just seadistanud registri, et saaksime alustada tööd objektide esinemisjuhtudega kogu pistikprogrammis, ilma et oleks vaja liigset sidumist.

Kuid endiselt on probleem, millega me silmitsi seisame ja see käsitleb nimeruume ja automaatset laadimist. Ma olen sellest paar aastat tagasi natuke rääkinud, kuid mitte nii, nagu see on seotud heliloojaga.

Ja seda me selles postituses vaatlemegi.

WordPressi vidina katlaplaat: ümbertöötamine, 6. osa

Selle sarja teises postituses hakkasime rääkima heliloojast. Kui küsite enamiku PHP arendajate käest (sh neilt, kes töötavad WordPressiga), kuulete tõenäoliselt, et Composer on paketihaldur või sõltuvushaldur.

Lühidalt, see on viis, kuidas saame oma projekti kaasata kolmandate osapoolte teegid ja seejärel kasutada nende funktsioone (nii et me ei pea selleks oma koodi kirjutama).

Kuid on veel üks funktsioon, mida Composer pakub ja mis on tohutult kasulik, eriti kui kasutate palju klasse ega soovi kogu koodibaasis kasutada nõudeid_once.

Ja see on automaatlaadur.

Autoloader määratletud

Otse juhendist:

Teekide jaoks, mis määravad automaatse laadimise teabe, loob Composer vendor/autoload.phpfaili. Saate selle faili lihtsalt kaasata ja hakata kasutama klasse, mida need teegid pakuvad, ilma lisatööta.

Kui olete koodi seni jälginud, näete, et tegelikult kasutame juba Composeri loodud automaatset laadijat.

Esiteks määratlesime vajaliku konfiguratsiooni :

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

Seejärel hakkasime seda lisama pistikprogrammi alglaadimisribale (mille me täna lõpetame):

Kuid siin on probleem: kuidas laadida just neid klasse, mida levitamiseks vajame?

Teisisõnu: me kasutame arenduses palju teeke, et tagada kvaliteetse ja standarditele vastava koodi kirjutamine. Kuid me ei taha jagada 10 MB andmeid neile, kes meie projekti kasutavad.

Selle asemel peame kaasama ainult vajalikud failid, eks? Ja selleks peame tagama, et loome automaatlaaduri, mille saame lisada ja mis teeb just seda.

Esiteks näitan teile käsku ja seejärel selgitan, mida see kõik teeb:

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

See loob just selle, mida vajame, et meie projekt tootmiskeskkonnas toimiks. Iga lipp teeb järgmist.

• helilooja installimine. See lihtsalt installib kõik sõltuvused. Kui teil on hankijate kataloogis neid juba mitu, eemaldab see kõik, välja arvatud need, mis on vajalikud.
• no-dev. See takistab Composeril installimast pakette oma konfiguratsioonifailide jaotisesse request -dev (nimelt sõltuvused, mida me GrumPHP-ga kasutame).
• no-ansi. See hoiab ära ANSI väljundi esinemise. Võib-olla te ei hooli selle käivitamisest või mitte. Kui valite teatud tüüpi automaatse juurutamise, kasutage seda; vastasel juhul võib selle käsust välja jätta.
• interaktsiooni puudumine. See on veel üks lipp, mida kasutatakse spetsiaalselt keskkondade jaoks, kus soovite projekti automaatselt üles ehitada ja te ei pea tegelema küsimuste, väljundi ja muu sellisega.
• optimeeri-automaatlaadur. Lühidalt, see loob kiirema automaatlaaduri. Olenevalt teie projekti suurusest võib selle käivitamine veidi aega võtta, kuid see tasub töö käivitamisel ära.
• edenemata. See peidab edenemisriba terminalis kuvamise eest. Võib-olla soovite seda näha ja kui jah, siis see on suurepärane; mõned keskkonnad ei pruugi aga teatud märke (nt tagasilükkeklahvi) hästi käsitleda.
• eelista-dist. See tagab, et installitud paketid tehakse nii, kasutades levitamisversiooni (võrreldes millegi vähem stabiilsega).

Kas olete endiselt huvitatud?

Kui olete tõesti huvitatud automaatlaaduri optimeerimisest väljaspool seda postitust hõlmavate projektide jaoks, siis soovitan lugeda seda lehte Composeri dokumentatsioonist. See ei kuulu meie siin tehtavasse valdkonda, kuid see võib olla kasulik muu töö puhul, mis teil praegu on või mida teete tulevikus.

Kuidas see katlaplaadil välja näeb?

Kui töötate kohalikus masinas Boilerplate’iga, võite näha midagi sellist:

Kui aga käivitate ülaltoodud käsu, näete midagi sellist:

See on suur erinevus ja see on väike projekt. Kujutage ette, et teete midagi palju suuremat, mis hakkab tootmises käima.

Kogemusest rääkides võin teile öelda, et projektid võivad kiiresti jõuda 20 MB või enama sõltuvuseni, kui kasutate mitmesuguseid kolmanda osapoole teeke näiteks logimiseks, HTTP-päringuteks ja koodikvaliteedi tööriistadeks.

Kas lisame oma hankijate kataloogi?

Inimesed ütlevad sageli, et te ei tohiks hankija kataloogi allika juhtimisse kaasata ja mõjuval põhjusel: see võib olla tohutu.

Isegi helilooja dokumentatsioon räägib sellest:

Parim tava on lasta kõigil arendajatel kasutada sõltuvuste installimiseks Composerit. Sarnaselt tuleks koostamisserverit, CI-d, juurutustööriistu jne kohandada Composeri käitamiseks projekti alglaadimise osana.

Mida me siis tegema peaksime? Meil on vaja automaatlaadurit ja teatud sõltuvusi, sest meie kasutajad ei tea, et meie teose allalaadimisel käivitatakse (ega peaks ka käima!) Composer.

WordPressi olemuse ja meie tehtava töö tõttu peame hankijate kataloogi siduma, kuid ainult väga teatud nõuetega.

1. Loome haru, mida kasutatakse väljalaskmiseks (nimetame seda loominguliselt väljalaskmiseks ja saame sellesse arenduse liita, kui vaja).
2. Veendume, et hankija kataloog ei kuulu gitignore’i faili; aga tagame, et müüja kataloogis olevaid .git katalooge ignoreeritakse (see võib siiski võtta palju ruumi).

Nii et teeme iga sammu ja vaatame, kuidas see välja näeb, kui oleme lõpetanud.

Väljalaskeharu loomine

Uue haru loomiseks terminalist sisestage järgmine käsk :

$ git checkout -b release

See võtab kogu koodi, mille kallal me töötame, ja loob sellega uue haru. Kuna see on haru, mida me kasutame, et toimida samamoodi nagu meie kasutajad (meistrist räägime tulevases postituses).

Esmalt vaadake üle oma fail composer.json ja veenduge, et see sisaldaks järgmist.

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

Nüüd peame veenduma, et käivitame ülaltoodud käsu Composer veendumaks, et tarnija kataloogis pole midagi peale selle, mida vajame.

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

Nüüd peame gitignore’i värskendama.

Uuendame seda, mida me ignoreerime

Ja kui olete nii sarja kui ka postitust seni jälginud, siis teate, et see näeb välja umbes selline (see võib sisaldada rohkem või vähem, kuid peaks sisaldama vähemalt seda).

Minu jaoks näeb see välja järgmine :

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

Olenevalt sellest, kas kasutate terminali või klienti, näete, et sisestamiseks on uusi faile (eriti hankija kataloogist). Nii et lisage need oma harusse.

Seejärel tehke oma muudatused sisse. Kui töötate terminalis, peate võib-olla määrama järgmise:

$ git push --set-upstream origin release

Ja sellega peaks teie kood töötama ja olema saadaval GitHubis (või mis tahes allika juhtimisteenuses, mida kasutate). Siin näete, mis mul saadaval on .

Funktsionaalsuse lisamine

Nüüd, kui meil on kõik vajalikud osad paigas, on aeg hakata kasutama Composerit, automaatlaadurit, meie abstraktseid klasse ja registrit, et hakata WordPressi vidina katlaplaadile põhifunktsioone lisama, et meil oleks oma töö jaoks midagi näidata. .

Kellel on uudishimu, siis praegu plaanin filiaalid sellisena korrastada:

• Master on see, mis on saadaval kõigile, kes soovivad luua WordPressi vidina,
• arendada on mõeldud ainult arendajatele, sealhulgas neile, kes teavad, kuidas kasutada heliloojat ja selles postituses käsitletud teemasid,
• väljalaset kasutatakse toimiva demo pakkumiseks.

Praegu aga vaadake üle, mida selles postituses käsitletakse, ja jätkame sellega järgmises postituses.