Widget WordPress: refactoring, parte 6

Dovresti essere esperto nel refactoring che stiamo facendo per quanto riguarda il WordPress Widget Boilerplate. In caso contrario, ti consiglio di recuperare il ritardo sulla serie fino a questo momento:

• leggendo il post precedente ,
• o leggendo l’intera serie fino a questo punto,
• e guardando il ramo di sviluppo del progetto su GitHub.

Per quanto riguarda la base di codice, siamo a buon punto in questo momento. Abbiamo iniziato a refactoring gran parte del codice in classi più piccole e più mirate. E abbiamo appena impostato un registro in modo da poter iniziare a lavorare con istanze di oggetti in tutto il plug-in senza la necessità di un accoppiamento eccessivo.

Ma c’è ancora un problema che stiamo affrontando e riguarda gli spazi dei nomi e il caricamento automatico. Ne ho parlato un po’ un paio di anni fa, ma non per quanto riguarda Composer.

Ed è quello che vedremo in questo post.

The WordPress Widget Boilerplate: Refactoring, Parte 6

Nel secondo post di questa serie, abbiamo iniziato a parlare di Composer. Se chiedi alla maggior parte degli sviluppatori PHP (inclusi quelli che lavorano su WordPress), è probabile che sentirai che Composer è un gestore di pacchetti o un gestore di dipendenze.

In breve, è un modo per noi di portare librerie di terze parti nel nostro progetto e quindi utilizzare le loro funzionalità (quindi non dobbiamo scrivere il nostro codice per farlo).

Ma c’è un’altra funzionalità che Composer offre che è di immensa utilità soprattutto quando si utilizzano molte classi e non si desidera utilizzare le istruzioni require_once in tutta la base di codice.

E questo è il caricatore automatico.

Il caricatore automatico definito

Direttamente dal manuale:

Per le librerie che specificano le informazioni di caricamento automatico, Composer genera un vendor/autoload.phpfile. Puoi semplicemente includere questo file e iniziare a utilizzare le classi fornite da quelle librerie senza alcun lavoro aggiuntivo:

Se hai seguito il codice finora, vedrai che in realtà stiamo già utilizzando il caricatore automatico generato da Composer.

Per prima cosa, abbiamo definito la configurazione necessaria :

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

Quindi abbiamo iniziato a includerlo nel bootstrap del plugin (che finalizziamo oggi):

Ma c’è un problema qui: come carichiamo solo le classi di cui abbiamo bisogno per la distribuzione?

Per dirla in altro modo: ci sono molte librerie che stiamo usando in fase di sviluppo per assicurarci di scrivere codice di alta qualità e conforme agli standard. Ma non vogliamo distribuire 10 MB di dati a coloro che utilizzano il nostro progetto.

Invece, dobbiamo includere solo i file richiesti, giusto? E per farlo, dobbiamo assicurarci di generare un caricatore automatico che possiamo includere che faccia proprio questo.

Per prima cosa, ti mostrerò il comando, quindi spiegherò cosa fa:

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

Questo genererà proprio ciò di cui abbiamo bisogno per far funzionare il nostro progetto in un ambiente di produzione. Ecco cosa fa ogni bandiera:

• installazione del compositore. Questo installa semplicemente tutte le dipendenze. Se ne hai già un certo numero nella directory del fornitore, questo rimuoverà tutti tranne quelli richiesti.
• no-dev. Ciò impedirà a Composer di installare i pacchetti nella sezione require-dev dei suoi file di configurazione (vale a dire, le dipendenze che stiamo usando con GrumPHP).
• no-ansi. Ciò impedisce che si verifichi qualsiasi output ANSI. Potrebbe non interessarti eseguirlo o meno. Se scegli di eseguire un tipo di distribuzione automatica, utilizzalo; in caso contrario, può essere omesso dal comando.
• nessuna interazione. Questo è un altro flag che viene utilizzato specificamente per gli ambienti in cui si desidera creare automaticamente il progetto e non è necessario impegnarsi con domande, output e cose del genere.
• ottimizza-caricatore automatico. In breve, questo genera un caricatore automatico più veloce. Potrebbe volerci un po’ di tempo per l’esecuzione a seconda delle dimensioni del tuo progetto, ma ripaga quando avvii il tuo lavoro.
• nessun progresso. Ciò nasconde la barra di avanzamento dalla visualizzazione nel terminale. Potresti davvero voler vedere questo e, se è così, è fantastico; tuttavia, alcuni ambienti potrebbero non gestire bene determinati caratteri (come backspace).
• prefer-dist. Ciò assicurerà che i pacchetti installati vengano eseguiti utilizzando la versione di distribuzione (rispetto a qualcosa che è meno stabile).

Ancora interessato?

Se sei davvero curioso di ottimizzare il caricatore automatico per progetti al di fuori di questo post, ti consiglio di leggere questa pagina nella documentazione di Composer. Non rientra nell’ambito di ciò che stiamo facendo qui, ma potrebbe tornare utile con altri lavori che hai ora o che farai in futuro.

Com’è questo aspetto in Boilerplate?

Se stai lavorando su Boilerplate sul tuo computer locale, potresti vedere qualcosa del genere:

Ma se esegui il comando incluso sopra, vedrai qualcosa del genere:

Questa è una grande differenza e questo è un piccolo progetto. Immagina di fare qualcosa di molto più grande che verrà eseguito in produzione.

Parlando per esperienza, posso dirti che i progetti possono raggiungere rapidamente 20 MB o più di dipendenze se stai utilizzando una varietà di librerie di terze parti per cose come la registrazione, le richieste HTTP e gli strumenti di qualità del codice.

Includeremo nella nostra directory dei fornitori?

Le persone spesso diranno che non dovresti includere la directory del fornitore nel controllo del codice sorgente e con una buona ragione: può essere enorme.

Anche la documentazione di Composer parla di questo:

La procedura migliore è quindi fare in modo che tutti gli sviluppatori utilizzino Composer per installare le dipendenze. Allo stesso modo, il server di compilazione, CI, gli strumenti di distribuzione ecc. Dovrebbero essere adattati per eseguire Composer come parte del bootstrap del progetto.

Allora cosa dovremmo fare? Abbiamo bisogno del caricatore automatico e abbiamo bisogno di determinate dipendenze perché i nostri utenti non sapranno eseguire (né dovrebbero eseguire!) Composer ogni volta che scaricano il nostro lavoro.

A causa della natura di WordPress e del lavoro che stiamo facendo, dovremo impegnare la directory del fornitore ma solo con requisiti molto determinati.

1. Creeremo un ramo che verrà utilizzato per il rilascio (lo chiameremo in modo creativo rilascio e potremo unirci lo sviluppo quando necessario).
2. Ci assicureremo che la directory del fornitore non faccia parte del file gitignore; tuttavia, ci assicureremo che le directory .git all’interno della directory del fornitore vengano ignorate (che possono comunque occupare molto spazio).

Quindi eseguiamo ogni passaggio e vediamo come appare quando abbiamo finito.

Creazione del ramo di rilascio

Per creare un nuovo ramo dall’interno del terminale, immettere il seguente comando :

$ git checkout -b release

Questo prenderà tutto il codice su cui stiamo lavorando e quindi creerà un nuovo ramo con esso. Poiché questo sarà il ramo che useremo per agire come quello che useranno i nostri utenti (parleremo di master in un prossimo post).

Innanzitutto, rivedi il tuo file composer.json e assicurati che includa quanto segue:

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

Ora dobbiamo assicurarci di eseguire il comando Composer sopra per assicurarci che nient’altro che ciò di cui abbiamo bisogno sia nella directory del fornitore.

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

Ora dobbiamo aggiornare gitignore.

Aggiornare ciò che ignoriamo

E se hai seguito sia la serie che il post fino a qui, allora sai che assomiglierà a questo (potrebbe includere più o meno ma dovrebbe includere almeno questo).

Per me, questo sembra il seguente :

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

A seconda che tu stia utilizzando un terminale o un client, vedrai che ci sono nuovi file di cui eseguire il commit (dalla directory del fornitore, in particolare). Quindi aggiungi quelli al tuo ramo.

Quindi salva le modifiche. Potrebbe essere necessario specificare quanto segue se si lavora nel terminale:

$ git push --set-upstream origin release

E con ciò, il tuo codice dovrebbe funzionare ed essere disponibile su GitHub (o qualsiasi servizio di controllo del codice sorgente che stai utilizzando). Puoi vedere cosa ho a disposizione qui.

Aggiunta di funzionalità

Ora che abbiamo tutti i pezzi necessari a posto, è ora di iniziare a usare Composer, il caricatore automatico, le nostre classi astratte e il nostro Registro per iniziare ad aggiungere alcune funzionalità di base a WordPress Widget Boilerplate in modo da avere qualcosa da mostrare per il nostro lavoro .

Per i più curiosi, in questo momento ho intenzione di mantenere le filiali organizzate come tali:

• master sarà ciò che è disponibile per chiunque voglia creare un widget WordPress,
• lo sviluppo è strettamente per gli sviluppatori include coloro che sanno come usare Composer e gli argomenti discussi in questo post,
• release è ciò che verrà utilizzato per fornire una demo funzionante.

Per ora, però, rivedi ciò che è trattato in questo post e lo riprenderemo nel prossimo post.