Tämän sarjan tarkoituksena on aloittaa syvempi sukellus työskentelyyn olio-ohjelmoinnin kanssa WordPressin kontekstissa.
Ja koska WordPress Widgets API on yksi oliokeskeisiä käytäntöjä käyttävistä sovellusliittymistä, se on looginen paikka aloittaa. Lisäksi se antaa meille joitain perustavanlaatuisia tekniikoita, joita voimme käyttää tulevaan työhön, kun näemme, kuinka tulevissa sarjoissa rakennetaan enemmän olioprojekteja WordPressiin.
Tähän mennessä olemme käsitelleet seuraavat asiat:
- WordPress-widgetit: Olio-lähestymistapa. Widgets API tarjoaa vankan lakmustestin ja esimerkin siitä, kuinka pääset alkuun olio-ohjelmoinnin kanssa WordPressissä.
- WordPress-widgetit: Olio-ohjelmoinnin tunnistaminen. Tavoitteena on varustaa sinut kaikella, mitä tarvitset oliolähtöisten käytäntöjen havaitsemiseen.
Jos et ole perillä, nyt on hyvä aika tehdä se. Ja jos sinulla on, muistat edellisestä viestistä, jonka päätimme seuraavaan huomautukseen:
Toisin sanoen, palaamme WordPress Widget Boilerplateen ja aion muuttaa sen nykyiseen tilaan ottamaan käyttöön nykyaikaisemmat PHP-standardit.
Jotta voimme aloittaa WordPress Widget Boilerplaten päivittämisen noudattamaan mainittuja standardeja, meidän on tehtävä muutama asia:
- luoda haara olemassa olevasta kattilalevystä,
- asentaa koodin laatutyökalut,
- varmistaa, että IDE-tietojärjestelmämme on määritetty oikein,
- ja aloita koodin muokkaaminen mainittujen standardien mukaiseksi.
Ja sitä aiomme tehdä tällä postauksella.
Standardeista alkaen
Jos olet ollut tämän sivuston jäsen jonkin aikaa, tiedät, että käytän mieluummin Visual Studio Codea. Jos ei, minulla on koko joukko artikkeleita, jotka on omistettu siihen, miten käytän sitä (ja siten kuinka käytämme sitä koko tämän viestisarjan ajan).
Ja jos olet kiinnostunut koodausstandardeista, virheenkorjauksesta, IDE:istä, kehitysympäristöistä ja niin edelleen liittyvistä kattavuudesta, tutustu The Independent WordPress Developeriin.
Oletan kuitenkin, että jos luet tätä, olet lukenut yllä olevan materiaalin läpi tai voit käydä läpi kaiken yllä olevan materiaalin.
Tämän sanottuaan aloitetaan.
Varaston lataaminen
Ensimmäinen asia, jonka haluat tehdä, on kloonata kopio arkistosta. Teen tämän mieluummin komentorivin kautta.
Lisäksi mielestäni kannattaa tehdä niin WordPressin uusinta versiota vastaan. Jos sinulla ei ole kopiota Subversionin WordPressin runkokopiosta, voit lukea sen määrittämisestä täältä. tämä on kuitenkin täysin vapaaehtoista. Voit seurata tämän opetusohjelman muuta osaa millä tahansa haluamallasi WordPress-versiolla.
Tehdä niin,
- Varmista, että olet WordPress-asennuksesi plugins -hakemistossa
- Ja sitten kirjoita seuraavat komennot päätelaitteen kopioon
$ Tämä luo WordPress-Widget-Boilerplate- hakemiston laajennushakemistoosi. Voit navigoida siihen yksinkertaisesti kirjoittamalla:
$ cd WordPress-Widget-BoilerplateArkiston kloonauksen tulosten pitäisi näyttää tältä:
Seuraavaksi sinun on varmistettava, että vaihdat luomaani kehityshaaraan. Tämän tekeminen on todella helppoa. Mutta ennen kuin teemme sen, miksi et määritä projektia Visual Studiossa?
Visual Studio Coden määrittäminen
Vaiheet projektin määrittämiseksi Visual Studio Codessa ovat yksinkertaisia:
- Vedä Boilerplaten hakemisto IDE:hen,
- Avaa integroitu pääte,
- Vaihda oksat
Aivan kuten olen tehnyt yllä, annan näyttölähetyksen siitä, kuinka tämä kaikki tehdään. Hakemiston vetäminen Visual Studio Code -koodiin pitäisi olla riittävän helppoa, mutta haarojen vaihtaminen komentorivillä voi olla hieman erilaista.
Ensin projektin määrittäminen Visual Studio Codessa:
Huomaa tässä, että avaan myös integroidun päätteen painamalla CMD+P-pikakuvaketta (olen macOS:ssä, joten pikakuvake voi olla erilainen). Sitten annan komennon tarkistaaksesi kehityshaan.
Kun olet tehnyt tämän, paikallisen arkiston pitäisi vaihtaa kehityshaaraan. Voit vahvistaa, että kyseessä on haara, jota työskentelet kirjoittamalla:
$ git branchTarkista sitten päätteen sisältö. Tarkkaan ottaen kehittämistä tulisi korostaa.
Tässä vaiheessa aiomme tuoda projektiin muutamia uusia tiedostoja. Tämän opetusohjelman lopussa voit muodostaa vedon saadaksesi kaiken, mitä aion dokumentoida tänne. Mutta koska toimintamme tarkoitus on kaksijakoinen, on tärkeää varmistaa, että teemme tämän oikeassa järjestyksessä, koska ensimmäinen askel on jotain, jota käytän jokaisessa WordPress-projektissa tällä hetkellä.
Joten tämän sanottua, katsotaanpa.
Säveltäjä ja koodin laatu
Ensimmäinen asia, jonka haluan tehdä, on luoda sarja työkaluja koodin laadun valvomiseksi. Tämä saavutetaan useilla Composer-paketteilla. Nämä sisältävät:
- GrumPHP. PHP-koodilaatuinen työkalu. Älä aliarvioi selkeyttä ja sitä, missä määrin tämä arkisto on täynnä tietoa. Jos joskus jäät jumiin johonkin muuhun tässä mainittuun työkaluun, lue ensin tämän arkiston dokumentaatio.
- PHP CS Fixer. Työkalu PHP-koodausstandardien ongelmien automaattiseen korjaamiseen.
- PHP Parallel Lint. Tämä työkalu tarkistaa PHP-tiedostojen syntaksin nopeammin kuin sarjatarkistus hienommalla lähdöllä.
- PHPMD. Tämä apuohjelma käyttää tietyn PHP-lähdekoodipohjan ja etsii useita mahdollisia ongelmia kyseisessä lähteessä
- PHP jäsentäjä. Jäsentäjä on hyödyllinen staattiseen analyysiin, koodin käsittelyyn ja periaatteessa kaikkiin muihin koodia ohjelmallisesti käsitteleviin sovelluksiin.
- Välityspalvelimen hallinta. Tämän kirjaston tarkoituksena on tarjota abstraktio erilaisten välityspalvelinluokkien luomiseen.
Haluan olla selvä kahdesta asiasta:
- Yllä olevat työkalut ovat käyttämäni vähimmäismäärä, ja tulet todennäköisesti käyttämään muita työkaluja tulevaisuudessa,
- yllä olevat työkalut auttavat valvomaan koodin laatusääntöjä ennen koodin tarkistamista arkistoon. Sen on tarkoitus täydentää IDE:n asetuksia.
Jotta nämä työkalut saadaan käyttöön ja toimimaan projektin sisällä, meidän on luotava tältä näyttävä composer.json – tiedosto :
{
"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"
}Muista, että voit vetää tämän alas manuaalisesti tämän viestin lopussa. Jos kuitenkin haluat seurata mukana, voit tehdä tämän manuaalisesti. En koskaan haluaisi lannistaa sinua siitä. 🙂
Kun olet luonut composer.json – tiedoston, sinun kannattaa varmistaa, että suoritat seuraavan komennon päätteestä:
$ composer installTämä voi kestää jonkin aikaa; Kuitenkin, kun se on tehty, sinulle pitäisi näyttää seuraava viesti:
Varo! GrumPHP haistaa sitoumuksesi!
Anna sen kuivaajon kirjoittamalla seuraava komento terminaaliin:
$ vendor/bin/grumphp runRiippuen siitä, miten työskentelet projektin kanssa, saatat nähdä tulosteen, joka näyttää suunnilleen tältä:
Mutta työtä on enemmän. Nimittäin meidän on:
- päivittää .gitignore- tiedostomme,
- esittele GrumPHP:n asetukset
- esittele PHPMD-asetukset,
- esitellä PHPCS-määritykset,
- lopuksi rakentele uudelleen kattilalevyn hakemistorakenne.
Kaikki viimeiseen vaiheeseen asti, pyrimme tekemään tässä viestissä.
Ohita-tiedoston päivittäminen
Ensinnäkin emme halua sitoa toimittajahakemistoa tai säveltäjän lukitustiedostoa. Nämä voidaan luoda aina, kun käyttäjä lataa hakemiston. Ne voivat helposti pudota tahdista ja lisäävät valtavasti projektin hakemistoon.
Tätä varten gitignore- tiedostosi pitäisi 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/
composer.lockTämä käskee laajennuksen ohittamaan kaiken paitsi sen, mikä on laajennushakemiston juurissa (ja jotkin mahdollisesti luoduista hakemistoista) sekä joitain perustiedostoja, joita olemme tottuneet näkemään WordPress-asennuksissa.
Jotkut näkemistäsi, kuten wp-config.php tai wp-content/backups, joita et todennäköisesti koskaan näe laajennuksen yhteydessä, mutta nämä ovat tavallisia WordPressin huomiotta jättäviä ohjeita, jotka haluan pitää käden ulottuvilla.
Huomaat, että olen lisännyt myös toimittajan ja säveltäjän lukitustiedoston tiedoston alaosaan.
Määritä GrumPHP
GrumPHP voi tehdä paljon, ja jos vietit aikaa arkiston tutkimiseen ennen kuin olet lukenut tähän asti, tiedät sen todennäköisesti; Aion kuitenkin pitää sen mahdollisimman vähärasvaisena, joten se tarjoaa käyttämillemme työkaluille tarvitsemansa ohjeet eikä mitään muuta.
parameters:
git_dir: .git
bin_dir: vendor/bin
process_timeout: 120
tasks:
securitychecker:
composer:
jsonlint:
xmllint:
yamllint:
phplint:
exclude:
- vendor/
phpcs:
metadata:
priority: 200
phpcsfixer2:
allow_risky: true
config: '.php_cs.dist'
metadata:
priority: 300
phpparser:
visitors:
forbidden_function_calls:
blacklist:
- "exit"
- "var_dump"
phpversion:
project: '7.1'
phpmd:
exclude: ['vendor']
ruleset: ['phpmd.xml']Lyhyesti sanottuna tässä sanotaan suorittavan erilaisia tarkistuksia:
- turvallisuus,
- säveltäjä,
- JSON,
- XML,
- Jaml,
- PHP,
- PHPCS,
- PHP jäsentäjä,
- PHPMD,
- ja enemmän.
Kun olemme määrittäneet kaiken muun, näytän sinulle varmasti, kuinka tämä kaikki sopii yhteen. Mutta ensin lopetetaan muiden apuohjelmiemme konfigurointi.
PHPCS
Tämä käyttää kahta erillistä tiedostoa – dist -tiedostoa ja XML – tiedostoa – joista jokainen palvelee erilaisia, vaikkakin erittäin hyödyllisiä tarkoituksia.
Ensimmäinen tiedosto, php_cs.dist, jonka näet arkistossa tämän viestin lopussa, tarjoaa otsikon, jota sovelletaan kaikkiin projektimme PHP-tiedostoihin. Se pakottaa myös joitain erilaisia sääntöjä, jotka parantavat koodin laatua.
Säännöt ovat itsestään selviä, ja voit nähdä, mitä se panee täytäntöön, yksinkertaisesti tarkastelemalla jokaista määritettyä sääntöä.
<?php
$header = <<<'EOF'
This file is part of the WordPress Widget Boilerplate
(c) Tom McFarlin <tom@tommcfarlin.com>
This source file is subject to the GPL license that is bundled
with this source code in the file LICENSE.
EOF;
return PhpCsFixerConfig::create()
->setRiskyAllowed(true)
->setRules([
'@PHP56Migration' => true,
'@Symfony' => true,
'@Symfony:risky' => true,
'align_multiline_comment' => true,
'array_syntax' => ['syntax' => 'short'],
'blank_line_before_statement' => true,
'combine_consecutive_issets' => true,
'combine_consecutive_unsets' => true,
// one should use PHPUnit methods to set up expected exception instead of annotations
'general_phpdoc_annotation_remove' => ['annotations' => ['expectedException', 'expectedExceptionMessage', 'expectedExceptionMessageRegExp']],
'header_comment' => ['header' => $header],
'heredoc_to_nowdoc' => true,
'list_syntax' => ['syntax' => 'long'],
'method_argument_space' => ['ensure_fully_multiline' => true],
'method_chaining_indentation' => false,
'no_extra_consecutive_blank_lines' => ['tokens' => ['break', 'continue', 'extra', 'return', 'throw', 'use', 'parenthesis_brace_block', 'square_brace_block', 'curly_brace_block']],
'no_null_property_initialization' => true,
'no_short_echo_tag' => true,
'no_unneeded_curly_braces' => true,
'no_unneeded_final_method' => true,
'no_unreachable_default_argument_value' => true,
'no_useless_else' => true,
'no_useless_return' => true,
'ordered_class_elements' => true,
'ordered_imports' => true,
'php_unit_construct' => true,
'php_unit_test_class_requires_covers' => true,
'php_unit_dedicate_assert' => true,
'phpdoc_add_missing_param_annotation' => true,
'phpdoc_order' => true,
'phpdoc_types_order' => ['null_adjustment' => 'always_last'],
'semicolon_after_instruction' => true,
'single_line_comment_style' => true,
'visibility_required' => ['const', 'property', 'method'],
'yoda_style' => true,
])
->setFinder(
PhpCsFixerFinder::create()
->exclude(__DIR__. '/vendor/*')
->in([
__DIR__. '/src'
])) ;Seuraavaksi haluat myös luoda XML-tiedoston täydentämään yllä olevaa tiedostoa. Huomaat, että toimittamassani tiedostossa käytän tätä työssäni Presswarella. Lisäksi se myös kuittaa testihakemiston.
Tällä hetkellä meillä ei ole kirjoitettuja yksikkötestejä, mutta jos päätät sisällyttää ne widgetiin, tämä on valmis käsittelemään ne oikein.
<?xml version="1.0"?>
<ruleset name="Pressware">
<description>Pressware, LLC Coding Standards</description>
<!-- Scan all files in directory -->
<file>./src</file>
<file>./tests</file>
<exclude-pattern>./tests/phpunit/*</exclude-pattern>
<!-- Scan only PHP files -->
<arg name="extensions" value="php"></arg>
<!-- Show colors in console -->
<arg value="-colors"></arg>
<!-- Show sniff codes in all reports -->
<arg value="ns"></arg>
<!-- Use PSR-2 as a base -->
<rule ref="PSR2"></rule>
<rule ref="Generic.Arrays.DisallowLongArraySyntax.Found" ></rule>
<!-- Force 2 spaces indentation -->
<rule ref="Generic.WhiteSpace.ScopeIndent">
<properties>
<property name="indent" value="4"></property>
<property name="tabIndent" value="false"></property>
</properties>
</rule>
</ruleset>Määritän tässä vain pienen joukon kokoonpanoja, mutta olen huomannut sen olevan enemmän kuin riittävä tarpeisiini toistaiseksi. Kun löydän lisää tai päätän käyttää enemmän, aion varmasti päivittää sisältöä tulevissa viesteissä.
Määritä PHPMD
Ja lopuksi meidän on määritettävä PHP Mess Detector (tai PHPMD). Onneksi tämä käyttää XML-tiedostoa, joka käyttää Composerin asentaman paketin sääntöjoukkoja. Meidän tarvitsee vain viitata sääntöön asetustiedostossa.
Toiseksi tarjoamme myös pienen poikkeuksen ShortVariable- nimelle, kuten näet seuraavasta sisällöstä :
<?xml version="1.0" encoding="UTF-8" ?>
<ruleset
name="VersionEyeModule rules"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd"
>
<rule ref="rulesets/cleancode.xml" ></rule>
<rule ref="rulesets/codesize.xml" ></rule>
<rule ref="rulesets/controversial.xml" ></rule>
<rule ref="rulesets/design.xml" ></rule>
<rule ref="rulesets/unusedcode.xml" ></rule>
<rule ref="rulesets/naming.xml">
<exclude name="ShortVariable"></exclude>
</rule>
<rule ref="rulesets/naming.xml/ShortVariable"
since="0.2"
message="Avoid variables with short names like {0}. Configured minimum length is {1}."
class="PHPMDRuleNamingShortVariable"
externalInfoUrl="http://phpmd.org/rules/naming.html#shortvariable">
<priority>3</priority>
<properties>
<property name="minimum" description="Minimum length for a variable, property or parameter name" value="3"></property>
<property name="exceptions" value="id,q,w,i,j,v,e,f,fp" ></property>
</properties>
</rule>
</ruleset>Ja kun kaikki nämä ovat paikoillaan, meidän pitäisi pystyä ajamaan GrumPHP:tä uudelleen komentoriviltä ja saada hieman erilaiset tulokset.
GrumPHP käynnissä taas
Kirjoita terminaaliin seuraavat tiedot:
$ vendor/bin/grumphp runJa sinun pitäisi nähdä jotain tällaista:
Erilaisia tuloksia kuin ensimmäisellä kerralla, vai mitä? Tämä johtuu siitä, että rikomme joitain sääntöjä ja standardeja, jotka ovat nykyaikainen osa PHP:tä ja olio-kehitystä.
Ja sitä aiomme siivota seuraavassa postauksessa.
Tulossa
Joten mistä tämän oliolähtöisyys tulee? Tähän asti olemme puhuneet Widgets API:n käyttämisestä oliopohjaisena mallina oliokoodin kirjoittamiseen WordPressissä.
Jotkut siitä, mitä olemme tehneet tähän mennessä, ovat olleet juuri sitä (puhumalla sen periaatteista, katsomalla, miten se on laadittu, ja paljon muuta).
Mutta kuten mainitsin tämän viestin alussa, koodin laatutyökalujen asettaminen antaa meille ensin perustan, jota voimme käyttää kattilalevyn uudelleenmuodostamiseen (mikä meidän on selvästikin tehtävä GrumPHP:n osoittaman punaisen määrän vuoksi).
Ja tästä aloitamme tämän sarjan seuraavassa postauksessa.