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\u00f9 piccole e pi\u00f9 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\u00e0 di un accoppiamento eccessivo.<\/p>\n
Ma c’\u00e8 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,<\/a> ma non per quanto riguarda Composer.<\/p>\n Ed \u00e8 quello che vedremo in questo post.<\/p>\n Nel secondo post di questa serie<\/a>, abbiamo iniziato a parlare di Composer. Se chiedi alla maggior parte degli sviluppatori PHP (inclusi quelli che lavorano su WordPress), \u00e8 probabile che sentirai che Composer \u00e8 un gestore di pacchetti o un gestore di dipendenze.<\/p>\n In breve, \u00e8 un modo per noi di portare librerie di terze parti nel nostro progetto e quindi utilizzare le loro funzionalit\u00e0 (quindi non dobbiamo scrivere il nostro codice per farlo).<\/p>\n Ma c’\u00e8 un’altra funzionalit\u00e0 che Composer offre che \u00e8 di immensa utilit\u00e0 soprattutto quando si utilizzano molte classi e non si<\/strong> desidera utilizzare le istruzioni require_once in tutta la base di codice.<\/p>\n E questo \u00e8 il caricatore automatico.<\/p>\n Direttamente dal manuale:<\/a><\/p>\n Per le librerie che specificano le informazioni di caricamento automatico, Composer genera un Se hai seguito il codice finora, vedrai che in realt\u00e0 stiamo gi\u00e0 utilizzando il caricatore automatico generato da Composer.<\/p>\n Per prima cosa, abbiamo definito la configurazione necessaria<\/a> :<\/p>\n Quindi abbiamo iniziato a includerlo nel bootstrap del plugin<\/a> (che finalizziamo oggi):<\/p>\n Ma c’\u00e8 un problema qui: come carichiamo solo le classi di cui abbiamo bisogno per la distribuzione?<\/p>\n Per dirla in altro modo: ci sono molte librerie che stiamo usando in fase di sviluppo per assicurarci di scrivere codice di alta qualit\u00e0 e conforme agli standard. Ma non vogliamo distribuire 10 MB di dati a coloro che utilizzano il nostro progetto.<\/p>\n 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.<\/p>\n Per prima cosa, ti mostrer\u00f2 il comando<\/a>, quindi spiegher\u00f2 cosa fa:<\/p>\n Questo generer\u00e0 proprio ci\u00f2 di cui abbiamo bisogno per far funzionare il nostro progetto in un ambiente di produzione. Ecco cosa fa ogni bandiera:<\/p>\n Se sei davvero curioso di ottimizzare il caricatore automatico per progetti al di fuori di questo post, ti consiglio di leggere questa pagina<\/a> nella documentazione di Composer. Non rientra nell’ambito di ci\u00f2 che stiamo facendo qui, ma potrebbe tornare utile con altri lavori che hai ora o che farai in futuro.<\/p>\n Se stai lavorando su Boilerplate sul tuo computer locale, potresti vedere qualcosa del genere:<\/p>\n Ma se esegui il comando incluso sopra, vedrai qualcosa del genere:<\/p>\n Questa \u00e8 una grande differenza e questo \u00e8 un piccolo progetto. Immagina di fare qualcosa di molto pi\u00f9 grande che verr\u00e0 eseguito in produzione.<\/p>\n Parlando per esperienza, posso dirti che i progetti possono raggiungere rapidamente 20 MB o pi\u00f9 di dipendenze se stai utilizzando una variet\u00e0 di librerie di terze parti per cose come la registrazione, le richieste HTTP e gli strumenti di qualit\u00e0 del codice.<\/p>\n Le persone spesso diranno che non dovresti includere la directory del fornitore nel controllo del codice sorgente e con una buona ragione: pu\u00f2 essere enorme.<\/p>\n Anche la documentazione di Composer parla di questo:<\/a><\/p>\n La procedura migliore \u00e8 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.<\/p>\n<\/blockquote>\n Allora cosa dovremmo fare? Abbiamo bisogno del caricatore automatico e abbiamo bisogno di determinate dipendenze perch\u00e9 i nostri utenti non sapranno eseguire (n\u00e9 dovrebbero eseguire!) Composer ogni volta che scaricano il nostro lavoro.<\/p>\n A causa della natura di WordPress e del lavoro che stiamo facendo, dovremo impegnare la directory del fornitore ma solo con requisiti molto determinati.<\/p>\n Quindi eseguiamo ogni passaggio e vediamo come appare quando abbiamo finito.<\/p>\n Per creare un nuovo ramo dall’interno del terminale, immettere il seguente comando<\/a> :<\/p>\n Questo prender\u00e0 tutto il codice su cui stiamo lavorando e quindi creer\u00e0 un nuovo ramo con esso. Poich\u00e9 questo sar\u00e0 il ramo che useremo per agire come quello che useranno i nostri utenti (parleremo di master<\/strong> in un prossimo post).<\/p>\n Innanzitutto, rivedi il tuo file composer.json e assicurati che includa quanto segue:<\/p>\n Ora dobbiamo assicurarci di eseguire il comando Composer sopra per assicurarci che nient’altro che ci\u00f2 di cui abbiamo bisogno sia nella directory del fornitore<\/strong>.<\/p>\n Ora dobbiamo aggiornare gitignore.<\/p>\n E se hai seguito sia la serie che il post fino a qui, allora sai che assomiglier\u00e0 a questo (potrebbe includere pi\u00f9 o meno ma dovrebbe includere almeno questo).<\/p>\n Per me, questo sembra il seguente<\/a> :<\/p>\n 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.<\/p>\n Quindi salva le modifiche<\/a>. Potrebbe essere necessario specificare quanto segue se si lavora nel terminale:<\/p>\n E con ci\u00f2, 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<\/a>.<\/p>\n Ora che abbiamo tutti i pezzi necessari a posto, \u00e8 ora di iniziare a usare Composer, il caricatore automatico, le nostre classi astratte e il nostro Registro per iniziare ad aggiungere alcune funzionalit\u00e0 di base a WordPress Widget Boilerplate in modo da avere qualcosa da mostrare per il nostro lavoro .<\/p>\n Per i pi\u00f9 curiosi, in questo momento ho intenzione di mantenere le filiali organizzate come tali:<\/p>\n Per ora, per\u00f2, rivedi ci\u00f2 che \u00e8 trattato in questo post e lo riprenderemo nel prossimo post.<\/p>\nThe WordPress Widget Boilerplate: Refactoring, Parte 6<\/h2>\n
Il caricatore automatico definito<\/h3>\n
\n
vendor\/autoload.php<\/code>file. Puoi semplicemente includere questo file e iniziare a utilizzare le classi fornite da quelle librerie senza alcun lavoro aggiuntivo:<\/p>\n<\/blockquote>\n{\n \"name\": \"wordpress-widget-boilerplate\/wordpress-widget-boilerplate\",\n \"description\": \"An organized, maintainable boilerplate for building widgets using WordPress best practices.\",\n \"type\": \"wordpress-plugin\",\n \"license\": \"GPL-3.0-or-later\",\n \"homepage\": \"https:\/\/github.com\/tommcfarlin\/WordPress-Widget-Boilerplate\",\n \"authors\": [\n {\n \"name\": \"Tom McFarlin\",\n \"email\": \"tom@pressware.co\",\n \"homepage\": \"https:\/\/pressware.co\"\n }\n ],\n \"support\": {\n \"issues\": \"https:\/\/github.com\/tommcfarlin\/WordPress-Widget-Boilerplate\/issues\"\n },\n \"config\": {\n \"preferred-install\": \"dist\",\n \"platform\": {\n \"php\": \"7.1\"\n }\n },\n \"repositories\": [\n {\n \"type\": \"composer\",\n \"url\": \"https:\/\/wpackagist.org\"\n }\n ],\n \"require\": {\n \"php\": \"7.1\",\n \"composer\/installers\": \"^1.4\"\n },\n \"require-dev\": {\n \"friendsofphp\/php-cs-fixer\": \"^2.13.1\",\n \"jakub-onderka\/php-parallel-lint\": \"^1.0.0\",\n \"phpmd\/phpmd\": \"^v2.6.0\",\n \"nikic\/php-parser\": \"^4.0\",\n \"ocramius\/proxy-manager\": \"^2.0.0\",\n \"phpro\/grumphp\": \"^0.13.1\"\n },\n \"scripts\": {\n \"test\": [\n \".\/vendor\/bin\/grumphp run\"\n ]\n },\n \"minimum-stability\": \"stable\"\n }<\/code><\/pre>\n<?php\n\n\/\/ Include the autoloader.\n\/\/ TODO: Note this has not yet been defined.\nrequire_once __DIR__. '\/inc\/autoload.php';\n<\/code><\/pre>\n$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist<\/code><\/pre>\n\n
Ancora interessato?<\/h4>\n
Com’\u00e8 questo aspetto in Boilerplate?<\/h2>\n
![\"Widget](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161015-61e719e23bf2d.png\")
<\/a><\/p>\n![\"Widget](\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161015-61e719e5afd5a.png\")
<\/a><\/p>\nIncluderemo nella nostra directory dei fornitori?<\/h2>\n
\n
\n
Creazione del ramo di rilascio<\/h3>\n
$ git checkout -b release<\/code><\/pre>\n\"autoload\": {\n \"psr-4\": {\n \"WordPressWidgetBoilerplate\": \"src\/\",\n \"WordPressWidgetBoilerplateSubscriber\": \"src\/Subscriber\/\",\n \"WordPressWidgetBoilerplateUtilities\": \"src\/Utilities\/\",\n \"WordPressWidgetBoilerplateViews\": \"src\/Views\/\"\n }\n},<\/code><\/pre>\n$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist<\/code><\/pre>\nAggiornare ci\u00f2 che ignoriamo<\/h3>\n
*.DS_Store\n*.log\nwp-config.php\nwp-content\/advanced-cache.php\nwp-content\/backup-db\/\nwp-content\/backups\/\nwp-content\/blogs.dir\/\nwp-content\/cache\/\nwp-content\/upgrade\/\nwp-content\/uploads\/\nwp-content\/mu-plugins\/\nwp-content\/wp-cache-config.php\nwp-content\/plugins\/hello.php\n\n\/.htaccess\n\/license.txt\n\/readme.html\n\/sitemap.xml\n\/sitemap.xml.gz\n\n\/vendor\/**\/.git\n\/vendor\/bin\ncomposer.lock\n<\/code><\/pre>\n$ git push --set-upstream origin release<\/code><\/pre>\nAggiunta di funzionalit\u00e0<\/h2>\n
\n