✅ WEB ja WordPressi uudised, teemad, pistikprogrammid. Siin jagame näpunäiteid ja parimaid veebisaidi lahendusi.
man in black t-shirt using laptop computer
ArendajaKoodWordPress

WordPressi vidinad: alustades standarditest

14
Sisu
Alustades standarditest
Hoidla allalaadimine
Visual Studio koodi seadistamine
Helilooja ja koodi kvaliteet
Ignoreeri faili värskendamine
GrumPHP seadistamine
PHPCS
PHPMD seadistamine
Jälle GrumPHP käivitamine
Tulekul

Selle seeria eesmärk on hakata WordPressi kontekstis objektorienteeritud programmeerimisega töötamisse sügavamalt sukelduma.

Ja kuna WordPressi vidinate API on üks API-dest, mis kasutab objektorienteeritud tavasid, on see loogiline koht alustamiseks. Lisaks annab see meile mõned põhilised tehnikad, mida saame kasutada tulevases töös, kui näeme, kuidas tulevastes seeriates WordPressis rohkem objektorienteeritud projekte ehitada.

Siiani oleme käsitlenud järgmist.

  1. WordPressi vidinad: objektorienteeritud lähenemine. Vidinate API pakub kindlat lakmustesti ja näidet selle kohta, kuidas WordPressis objektorienteeritud programmeerimist alustada.
  2. WordPressi vidinad: objektorienteeritud programmeerimise tuvastamine. Eesmärk on varustada teid kõige vajalikuga objektorienteeritud tavade tuvastamiseks.

Kui te ei jõua järele, on nüüd suurepärane aeg seda teha. Ja kui on, siis mäletate eelmisest postitusest, mille lõpetasime järgmise märkusega:

See tähendab, et vaatame uuesti WordPressi vidina katlaplaati ja muudan selle praeguses seisukorras, et võtta kasutusele kaasaegsemad PHP-standardid.

WordPress Widget Boilerplate’i värskendamise alustamiseks nimetatud standardite järgimiseks peame tegema mõned asjad:

  1. luua olemasolevast katlaplaadist haru,
  2. installige koodikvaliteedi tööriistad,
  3. veenduge, et meie IDE on õigesti seadistatud,
  4. ja alustage koodi ümberkujundamist nimetatud standardite järgi.

Ja seda me selle postitusega tegema hakkamegi.

Alustades standarditest

Kui olete selle saidi liige olnud mõnda aega, siis teate, et eelistan kasutada Visual Studio koodi. Kui ei, siis on mul terve rida artikleid, mis on pühendatud selle kasutamisele (ja seega ka sellele, kuidas me seda selle postituste seeria jooksul kasutame).

Ja kui teid huvitab kodeerimisstandardite, silumise, IDE-de, arenduskeskkondade jms katvus, vaadake The Independent WordPress Developerit.

Siiski eeldan, et kui loete seda, siis olete ülaltoodud materjali läbi lugenud või olete rahul kogu ülaltoodud materjaliga.

Seda öeldes alustame.

Hoidla allalaadimine

Esimene asi, mida soovite teha, on hoidla koopia kloonimine. Eelistan seda teha käsurea kaudu.

Lisaks arvan ma, et seda tasub teha ka WordPressi uusima versiooni puhul. Kui teil pole Subversioni WordPressi põhikoopia koopiat, saate lugeda, kuidas seda seadistada siit. see on aga täiesti vabatahtlik. Saate seda õpetust ülejäänud osaga suurepäraselt jälgida mis tahes WordPressi versiooniga, mida soovite.

Selleks

  1. Veenduge, et olete oma WordPressi installi pistikprogrammide kataloogis
  2. Ja seejärel sisestage järgmised käsud oma terminali koopiasse
$

See loob teie pistikprogrammide kataloogi kataloogi WordPress-Widget-Boilerplate. Selle juurde pääsete lihtsalt tippides:

$ cd WordPress-Widget-Boilerplate

Hoidla kloonimise tulemused peaksid välja nägema umbes sellised:

Järgmiseks peate veenduma, et kasutate minu loodud arendusharu. Seda on tõesti lihtne teha. Aga enne kui me seda teeme, miks mitte seadistada projekt Visual Studios?

Visual Studio koodi seadistamine

Projekti Visual Studio Code’is seadistamise sammud on lihtsad:

  1. Lohistage Boilerplate’i kataloog IDE-sse,
  2. Avage integreeritud terminal,
  3. Vahetage oksad

Nii nagu ma eespool tegin, annan ekraanilekande selle kohta, kuidas seda kõike teha. Kataloogi lohistamine Visual Studio Code’i peaks olema piisavalt lihtne, kuid harude vahetamine käsureal võib olla veidi erinev.

Esiteks seadistage projekt Visual Studio Code’is:

Pange tähele, et ma avan ka integreeritud terminali, vajutades kiirklahvi CMD+P (kasutan macOS-is, nii et teie otsetee võib olla erinev). Seejärel sisestan käsu arendusharu kontrollimiseks.

Kui olete seda teinud, peaks teie kohalik hoidla vahetama arendusharu vastu. Saate kinnitada, et see on haru, mille juures te töötate, tippides:

$ git branch

Ja siis vaata üle terminali sisu. Rangelt võttes tuleks esile tõsta arendamist .

WordPressi vidinad: alustades standarditest

Siinkohal tutvustame projekti mõned uued failid. Selle õpetuse lõpus saate moodustada tõmbe, et hankida kõik, mida ma siin dokumenteerima hakkan. Kuid kuna meie tegevuse eesmärk on kahekordne, on oluline veenduda, et teeme seda õiges järjekorras, sest esimene samm on midagi, mida ma praegu kasutan igas WordPressi projektis.

Nii et seda öeldes, vaatame.

Helilooja ja koodi kvaliteet

Esimene asi, mida mulle meeldib teha, on koodikvaliteedi jõustamiseks tööriistade seeria seadistamine. See saavutatakse erinevate Composeri pakettide abil. Need sisaldavad:

  • GrumPHP. PHP koodikvaliteedi tööriist. Ärge alahinnake selgust ja seda, mil määral see hoidla on teavet täis. Kui jääte kunagi mõne muu siin mainitud tööriistaga jänni, vaadake esmalt läbi selle hoidla dokumentatsioon.
  • PHP CS parandaja. Tööriist PHP kodeerimisstandardite probleemide automaatseks lahendamiseks.
  • PHP Parallel Lint. See tööriist kontrollib PHP-failide süntaksit kiiremini kui seeriakontroll uhkema väljundiga.
  • PHPMD. See utiliit kasutab antud PHP lähtekoodi baasi ja otsib selles allikas mitmeid võimalikke probleeme
  • PHP parser. Parser on kasulik staatiliseks analüüsiks, koodiga manipuleerimiseks ja põhimõtteliselt kõikidele muudele programmiliselt koodiga tegelevatele rakendustele.
  • Puhverserveri haldur. Selle teegi eesmärk on pakkuda abstraktsiooni mitmesuguste puhverserveri klasside genereerimiseks.

Ma tahan olla selge kahest asjast:

  1. Ülaltoodud tööriistad on miinimum, mida ma kasutan, ja tõenäoliselt näete, et kasutan tulevikus täiendavaid tööriistu,
  2. ülaltoodud tööriistad aitavad enne koodi hoidlasse kontrollimist jõustada koodi kvaliteedireegleid. Selle eesmärk on täiendada teie IDE seadistust.

Nende tööriistade seadistamiseks ja projektis käitamiseks peame looma faili composer.json, mis näeb välja järgmine :

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

Pidage meeles, et saate selle postituse lõpus käsitsi alla tõmmata. Kui aga soovite teksti jälgida, tehke seda vabalt käsitsi. Ma ei tahaks sind kunagi sellest heidutada. 🙂

Kui olete  faili composer.json loonud, peate veenduma, et käivitate terminalist järgmise käsu:

$ composer install

See võib võtta aega; kuid kui see on tehtud, peaks teile esitama järgmise teate:

Vaata ette! GrumPHP nuusutab teie kohustusi!

Kuivkäivitamiseks sisestage terminali järgmine käsk:

$ vendor/bin/grumphp run

Sõltuvalt sellest, kuidas te projektiga töötate, võite näha väljundit, mis näeb välja umbes selline:

WordPressi vidinad: alustades standarditest

Aga tööd on veel. Nimelt peame:

  • värskendage meie .gitignore- faili,
  • tutvustada GrumPHP konfiguratsiooni
  • tutvustada PHPMD konfiguratsiooni,
  • tutvustada PHPCS-i konfiguratsiooni,
  • lõpuks restruktureerige katlaplaadi kataloogistruktuur.

Selles postituses püüame teha kõike kuni viimase etapini.

Ignoreeri faili värskendamine

Esiteks ei taha me siduda tarnija kataloogi ega helilooja lukufaili. Neid saab luua alati, kui kasutaja laadib kataloogi alla. Need võivad kergesti sünkroonist välja kukkuda ja lisavad projekti kataloogile tohutult suurust.

Selleks peaks teie gitignore’i fail välja nägema 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/
composer.lock

See käsib pistikprogrammil ignoreerida kõike peale selle, mis asub pistikprogrammide kataloogi juurtes (ja mõnes võimalikus kataloogis, mille me loome) ning mõningaid põhifaile, mida oleme harjunud WordPressi installides nägema.

Osa sellest, mida näete, nagu wp-config.php või wp-content/backups, mida te tõenäoliselt kunagi pistikprogrammi kontekstis ei näe, kuid need on standardsed WordPressi ignoreerivad juhised, mida mulle meeldib käepärast hoida.

Märkate, et olen faili allossa lisanud ka hankija  ja helilooja lukufaili.

GrumPHP seadistamine

GrumPHP saab palju ära teha ja kui veetsite enne selle lugemist hoidlast aega uurides, siis tõenäoliselt teate seda. siiski kavatsen hoida selle võimalikult lahjana, nii et see annab juhised, mida ta vajab meie kasutatavate tööriistade jaoks, ja ei midagi muud.

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']

Lühidalt öeldes peab see läbi viima mitmesuguseid kontrolle:

  • turvalisus,
  • helilooja,
  • JSON,
  • XML,
  • Jaml,
  • PHP,
  • PHPCS,
  • PHP parser,
  • PHPMD,
  • ja veel.

Kui oleme kõik muu seadistamise lõpetanud, näitan teile kindlasti, kuidas see kõik kokku sobib. Kuid kõigepealt lõpetame ülejäänud utiliitide konfigureerimise.

PHPCS

See kasutab kahte eraldi faili – dist – faili ja XML- faili –, millest igaüks teenib erinevaid, kuigi väga kasulikke eesmärke.

Esimene fail php_cs.dist, mida näete hoidlas selle postituse lõpus, sisaldab päist, mida rakendatakse meie projekti kõikidele PHP-failidele. Samuti jõustab see mõned erinevad reeglid, mis parandavad koodi kvaliteeti.

Reeglid on iseenesestmõistetavad ja näete, mida see jõustab, vaadates lihtsalt läbi iga määratletud reegli .

<?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'
      ])) ;

Järgmisena soovite ülaltoodud faili täiendamiseks luua ka XML-faili. Pange tähele, et pakutavas failis kasutan seda oma töös Pressware’is. Lisaks kinnitab see ka testide kataloogi.

Praegu pole meil ühtegi ühikutesti kirjutatud, kuid kui otsustate need oma vidinasse lisada, on see valmis neid korralikult käsitlema.

<?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>

Siin täpsustan ainult väikese konfiguratsioonikomplekti, kuid ma olen leidnud, et see on minu vajaduste jaoks siiani piisav. Kui avastan rohkem või otsustan rohkem kasutada, värskendan kindlasti tulevaste postituste sisu.

PHPMD seadistamine

Ja lõpuks peame konfigureerima PHP Mess Detectori (või PHPMD). Õnneks kasutab see XML-faili, mis kasutab Composeri installitud paketis määratletud reeglistikke. Kõik, mida peame tegema, on viidata konfiguratsioonifailis olevale reeglile.

Teiseks teeme lühikese muutuja nime jaoks ka väikese välistuse, nagu näete järgmisest sisust :

<?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 kui kõik need on paigas, peaksime saama GrumPHP-d käsurealt uuesti käivitada ja omama veidi teistsuguseid tulemusi.

Jälle GrumPHP käivitamine

Sisestage oma terminali järgmine teave:

$ vendor/bin/grumphp run

Ja sa peaksid nägema midagi sellist:

WordPressi vidinad: alustades standarditest

Teised tulemused kui esimesel korral, ah? Põhjus on selles, et me rikume mõningaid reegleid ja standardeid, mis on PHP ja objektorienteeritud arenduse kaasaegne osa.

Ja seda me järgmises postituses ära koristame.

Tulekul

Kust siis selle objektorienteeritud olemus pärineb? Siiani oleme rääkinud vidinate API kasutamisest objektorienteeritud mudelina objektorienteeritud koodi kirjutamiseks WordPressis.

Osa sellest, mida oleme siiani teinud, on olnud täpselt see (rääkides selle põhimõtetest, vaadates, kuidas see on üles ehitatud ja palju muud).

Kuid nagu ma selle postituse alguses mainisin, annab koodikvaliteedi tööriistade paigaldamine meile kõigepealt aluse, mida saame kasutada katlaplaadi taastamiseks (mida peame GrumPHP näidatud punase koguse tõttu selgelt tegema).

Ja sellest alustame selle sarja järgmises postituses.

Sulle võib ka meeldida Veel autorilt

See veebisait kasutab teie kasutuskogemuse parandamiseks küpsiseid. Eeldame, et olete sellega rahul, kuid saate soovi korral loobuda. Nõustu Loe rohkem