{"id":231395,"date":"2022-12-15T15:13:00","date_gmt":"2022-12-15T12:13:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=231395"},"modified":"2022-12-15T15:16:20","modified_gmt":"2022-12-15T12:16:20","slug":"widget-wordpress-refactoring-parte-1","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/it\/widget-wordpress-refactoring-parte-1\/","title":{"rendered":"Widget WordPress: refactoring, parte 1"},"content":{"rendered":"\n<p><strong><a href=\"https:\/\/wordpress.mediadoma.com\/it\/widget-wordpress-a-partire-dagli-standard\/\" title=\"L'ultimo post\">L&#8217;ultimo post<\/a><\/strong> include molte informazioni sulla configurazione degli strumenti di qualit\u00e0 del codice nel tuo <strong><a href=\"https:\/\/tommcfarlin.com\/tag\/wordpress-development-environment\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">ambiente di sviluppo WordPress<\/a><\/strong>, ma sono necessari se faremo molto refactoring.<\/p>\n<blockquote>\n<p>Ma come ho detto all&#8217;inizio di questo post, la creazione di strumenti per la qualit\u00e0 del codice ci fornisce innanzitutto una base che possiamo utilizzare durante il refactoring del boilerplate (cosa che dobbiamo chiaramente fare data la quantit\u00e0 di rosso mostrata da GrumPHP).<\/p>\n<\/blockquote>\n<p>Onestamente, li vedo come necessari se hai intenzione di fare qualsiasi tipo di sviluppo, da qui la necessit\u00e0 di mostrare come configurarli.<\/p>\n<p>Indipendentemente da ci\u00f2, il post precedente mostra quanto lavoro abbiamo ritagliato per noi, giusto?<\/p>\n<p>Ora inizieremo con il refactoring di <strong><a href=\"https:\/\/github.com\/tommcfarlin\/WordPress-Widget-Boilerplate\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">WordPress Widget Boilerplate<\/a><\/strong>.<\/p>\n<p>Ci\u00f2 non solo migliorer\u00e0 la qualit\u00e0 del codice, ma ci guider\u00e0 anche attraverso alcuni principi orientati agli oggetti che possiamo applicare durante la creazione dei nostri widget e che possiamo applicare nei futuri sforzi di sviluppo di WordPress.<\/p>\n<h2>The WordPress Widget Boilerplate: Refactoring, Parte 1<\/h2>\n<p>Forse la cosa pi\u00f9 eccitante per me \u00e8 portare questo repository agli standard moderni. Se guardi il <strong><a href=\"https:\/\/github.com\/tommcfarlin\/WordPress-Widget-Boilerplate\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">ramo principale in GitHub<\/a><\/strong> al momento di questo post (o la cronologia del repository in seguito), vedrai che ha sei anni.<\/p>\n<p><a href=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161542-61e724d06f9bc.png\" data-rel=\"lightbox\"><img decoding=\"async\" class=\"SDStudio-light-box-enable SDStudio-editor-tools-md-imp\" src=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161542-61e724d06f9bc.png\" alt=\"Widget WordPress: refactoring, parte 1\"><\/a><\/p>\n<p>Questa cosa ha sei anni (al momento di questo post).<\/p>\n<p>\u00c8 molto tempo negli anni di Internet, non \u00e8 vero?<\/p>\n<p>Ad ogni modo, nei nostri sforzi di refactoring, faremo alcune cose:<\/p>\n<ul>\n<li>creare un ramo su cui lavorare prima di unirlo nuovamente al ramo principale,<\/li>\n<li>implementare un modo pi\u00f9 coerente di organizzare i file,<\/li>\n<li>aggiornare gli standard di codifica per seguire ci\u00f2 che \u00e8 pi\u00f9 in linea con PSR,<\/li>\n<li>e altro ancora.<\/li>\n<\/ul>\n<p>Lo spiego ora perch\u00e9 probabilmente non lo raggiungeremo tutto in questo post, ma tratteremo molto terreno. Quindi, detto questo, iniziamo.<\/p>\n<h3>1 Creazione di un ramo di sviluppo<\/h3>\n<p>Supponendo che tu abbia una copia del repository di sulla tua macchina locale, che dovresti avere dopo l&#8217;ultimo post, la prima cosa che dobbiamo fare \u00e8 creare un ramo di cui fare il nostro lavoro.<\/p>\n<p>\u00c8 buona norma non lavorare sul ramo principale. Invece, il master dovrebbe sempre essere usato per distribuire l&#8217;ultima versione stabile del codice.<\/p>\n<p>A tal fine, inserisci il seguente comando nel tuo terminale:<\/p>\n<pre><code>$ git checkout -b develop<\/code><\/pre>\n<p>Questo creer\u00e0 una nuova filiale locale. Non \u00e8 ancora stato inviato a GitHub o al tuo repository remoto (ovunque tu lo stia conservando).<\/p>\n<p>Quindi, inserisci il seguente comando:<\/p>\n<pre><code>$ git push --set-upstream origin develop<\/code><\/pre>\n<p>Questo spinger\u00e0 il ramo di sviluppo fino al repository remoto. Una volta fatto, dovresti essere in grado di vedere tutte le modifiche che abbiamo implementato nell&#8217;ultimo post nel tuo repository remoto.<\/p>\n<p>Se stai usando GitHub, dovrebbe assomigliare a questo:<\/p>\n<p><a href=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161542-61e724d38c4f4.png\" data-rel=\"lightbox\"><img decoding=\"async\" class=\"SDStudio-light-box-enable SDStudio-editor-tools-md-imp\" src=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161542-61e724d38c4f4.png\" alt=\"Widget WordPress: refactoring, parte 1\"><\/a><\/p>\n<p>Se stai utilizzando un altro servizio, dovrebbe comunque essere simile. Cio\u00e8, la struttura della directory dovrebbe essere la stessa, ma l&#8217;aspetto nel browser varier\u00e0.<\/p>\n<h4>Una nota sul ramo<\/h4>\n<p>Ricorda, lo scopo di questo ramo \u00e8 che facciamo tutto il nostro lavoro. In questo modo, non stiamo interferendo con il ramo principale da cui molte persone attireranno.<\/p>\n<p>Per essere chiari, forse nessuno tirer\u00e0 fuori da questo. Forse lo faranno. Indipendentemente da ci\u00f2, queste pratiche introdotte qui hanno lo scopo di mostrare come eseguire un progetto utilizzando il controllo del codice sorgente e strumenti di qualit\u00e0 del codice in modo da poter creare progetti migliori per te, la tua azienda e altro ancora.<\/p>\n<h3>2 Riorganizzazione dei file<\/h3>\n<p>La prima cosa che dovremmo fare \u00e8 riorganizzare i file, in modo che imitino una struttura pi\u00f9 moderna. Far\u00f2 del mio meglio per giustificare le decisioni che sto prendendo per il progetto mentre lo facciamo; tuttavia, sentiti libero di prenderti delle libert\u00e0 su come vuoi farlo.<\/p>\n<p>Le decisioni che prendo alla fine influenzeranno il Boilerplate primario. Ci\u00f2 che scegli di fare influenzer\u00e0 il modo in cui puoi utilizzarlo nel tuo lavoro quotidiano o come scegli di andare avanti con il progetto nel suo insieme.<\/p>\n<h3>Aggiornamento delle directory<\/h3>\n<p>Una delle cose che provo a fare \u00e8 scomporre le mie directory, in modo che siano il pi\u00f9 chiare possibile. Ci\u00f2 significa che provo a fare quanto segue:<\/p>\n<ul>\n<li>creare una directory degli <strong>asset<\/strong> per JavaScript e fogli di stile,<\/li>\n<li>creare una directory <strong>src<\/strong> per tutti i file PHP,<\/li>\n<li>creare una directory della <strong>lingua<\/strong> per i file di internazionalizzazione,<\/li>\n<li>mantieni tutti gli altri file nella radice del repository, quindi \u00e8 facile per gli altri seguirli insieme al README fornito.<\/li>\n<\/ul>\n<p>Per fare ci\u00f2, prima rimuover\u00f2 e sposter\u00f2 alcune cose. Ho provato a organizzare questo in un ordine particolare:<\/p>\n<ol>\n<li>Rimuover\u00f2 il file <strong>README.txt<\/strong>. Questo file viene utilizzato come modello README standard se intendi inviare codice al WordPress Plugin Repository, ma non \u00e8 necessario per quello che voglio per Boilerplate.<\/li>\n<li>Rinominer\u00f2 <strong>plugin.php<\/strong> in <strong>Plugin<em><\/em><\/strong> .php<em><\/em> per seguire le convenzioni PSR.<\/li>\n<li>Rinominer\u00f2 anche <strong>lang<\/strong> in <strong>lingue.<\/strong><\/li>\n<li>Creer\u00f2 una directory di <strong>asset e sposter\u00f2 e quindi sposter\u00f2 le directory<\/strong> <strong>css<\/strong> e <strong>js<\/strong> in quella directory. Creer\u00f2 una sottodirectory <strong>dev<\/strong> in ciascuna di queste directory in cui possiamo lavorare su Sass e file JavaScript non minimizzati (entrambi arriveranno pi\u00f9 avanti nella serie).<\/li>\n<li>Successivamente, creer\u00f2 una directory <strong>src e sposter\u00f2 il foglio di stile delle<\/strong> <strong>viste<\/strong> in quella directory.<\/li>\n<li>Rinominer\u00f2 anche <strong>le viste<\/strong> in <strong>Visualizzazioni<\/strong> e metter\u00f2 in maiuscolo anche i file in esso contenuti.<\/li>\n<li>Infine, sposter\u00f2 tutto nella radice della directory. Ci\u00f2 significa che <strong>widget-boilerplate<\/strong> scomparir\u00e0 e tutti i file risiederanno nella directory principale del repository.<\/li>\n<\/ol>\n<p>Questi sono molti passaggi, ma sono piccoli. Mi piace disporli prima in modo che sia chiaro cosa accadr\u00e0 nel resto di questa sezione.<\/p>\n<h4>Rimuovere il LEGGIMI<\/h4>\n<p>Per fare ci\u00f2, inserisci semplicemente il seguente comando nel tuo terminale dalla radice della directory <strong>widget-boilerplate<\/strong> :<\/p>\n<pre><code>$ rm readme.txt<\/code><\/pre>\n<p>Questo rimuover\u00e0 il file. Se inserisci il seguente comando nel tuo terminale:<\/p>\n<pre><code>$ git status<\/code><\/pre>\n<p>Dovresti vedere qualcosa del genere:<\/p>\n<p><a href=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161542-61e724d77468a.png\" data-rel=\"lightbox\"><img decoding=\"async\" class=\"SDStudio-light-box-enable SDStudio-editor-tools-md-imp\" src=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161542-61e724d77468a.png\" alt=\"Widget WordPress: refactoring, parte 1\"><\/a><\/p>\n<p>Sono un fan dell&#8217;assicurarmi che le varie modifiche apportate siano chiare e concise in modo che sia pi\u00f9 facile ripristinarle una alla volta. Quindi andiamo avanti e impegniamoci e spingiamo questo cambiamento.<\/p>\n<p>Digita il seguente:<\/p>\n<pre><code>$ git rm README.txt\n$ git add. $ git commit -n -m \"Removing the original README.txt template.\"\n$ git push<\/code><\/pre>\n<p>Questo dir\u00e0 a Git di rimuovere il file, aggiungere la singola modifica al set di modifiche, eseguirne il commit senza eseguire alcuno strumento di qualit\u00e0 del codice (perch\u00e9 non \u00e8 necessario farlo in questo momento, altrimenti fallir\u00e0) e lo spinger\u00e0 al ramo di <strong>sviluppo<\/strong> del repository remoto .<\/p>\n<p>Ora che abbiamo fatto, andiamo avanti e rinominiamo alcuni file.<\/p>\n<h4>Rinominare i file<\/h4>\n<p>Gi\u00e0 che ci siamo, non solo rinomineremo il file <strong>plugin<em><\/em><\/strong> .php<em><\/em> ma anche gli altri file PHP. Questi sono file che possono essere raggruppati logicamente nello stesso set di modifiche, quindi ha senso andare avanti e farlo.<\/p>\n<p>Quindi dal tuo terminale, inserisci i seguenti comandi:<\/p>\n<pre><code>$ mv plugin.php Plugin.php\n$ mv views\/admin.php views\/Admin.php\n$ mv views\/widget.php views\/Widget.php<\/code><\/pre>\n<p>In questo modo, non abbiamo ancora apportato modifiche ai file, quindi non c&#8217;\u00e8 nulla da confermare. Andiamo avanti con la ridenominazione delle directory.<\/p>\n<h4>Creare directory; Rinomina directory<\/h4>\n<p>Proprio come abbiamo fatto con i file, andiamo avanti e creiamo una nuova directory degli <strong>asset<\/strong>. Nel tuo terminale, inserisci il seguente comando:<\/p>\n<pre><code>$ mkdir assets<\/code><\/pre>\n<p>Successivamente, vogliamo spostare le directory <strong>css<\/strong> e <strong>js<\/strong> in quella directory, quindi inserire anche quanto segue nel terminale:<\/p>\n<pre><code>$ mv css assets\n$ mv js assets<\/code><\/pre>\n<p>E rinominiamo la directory <strong>lang in<\/strong> <strong>Lingue<\/strong> inserendo il seguente comando:<\/p>\n<pre><code>$ mv lang Languages<\/code><\/pre>\n<p>Infine, rinominiamo la <strong>vista<\/strong> in <strong>Visualizzazioni:<\/strong><\/p>\n<pre><code>$ mv views Views<\/code><\/pre>\n<p>A questo punto, abbiamo fatto tutto il possibile con i file attualmente nella directory principale. Tuttavia, dobbiamo ancora preparare le sottodirectory per le nostre risorse preelaborate.<\/p>\n<p>Prima di farlo, tuttavia, \u00e8 una buona abitudine eseguire un rapido controllo <strong>dello stato di git<\/strong> per vedere cosa esiste che pu\u00f2 essere aggiunto a un changeset. Se il tuo repository \u00e8 come il mio, \u00e8 probabile che vedrai qualcosa di simile al seguente:<\/p>\n<p><a href=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161542-61e724da758f2.png\" data-rel=\"lightbox\"><img decoding=\"async\" class=\"SDStudio-light-box-enable SDStudio-editor-tools-md-imp\" src=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-161542-61e724da758f2.png\" alt=\"Widget WordPress: refactoring, parte 1\"><\/a><\/p>\n<p>In questo caso, penso che sia giusto aggiungere tutto in un unico changeset con un commento che indica che abbiamo rinominato e spostato i file.<\/p>\n<p>Potresti essere diverso e, in tal caso, va benissimo. I tuoi comandi saranno leggermente diversi dai miei, ma ecco cosa ho per il mio commit:<\/p>\n<pre><code>$ git add. $ git commit -n -m \"Creating new directories; Renaming files.\"\n$ git push<\/code><\/pre>\n<p>Ora, alle sottodirectory per i nostri file preelaborati.<\/p>\n<h4>Crea sottodirectory<\/h4>\n<p>Nella directory CSS, crea una sottodirectory chiamata <strong>dev<\/strong> e crea un file vuoto chiamato <strong>admin.scss<\/strong> e <strong>widget.scss<\/strong> poich\u00e9 lavoreremo con questi file pi\u00f9 avanti nella serie.<\/p>\n<p>Quindi, aggiungi una directory <strong>dev<\/strong> alla directory JavaScript e aggiungi il file <strong>admin.js vuoto e i file<\/strong> <strong>widget.js<\/strong> a questi file. Se ti senti cos\u00ec incline, puoi spostare i file preesistenti nelle directory <strong>dev<\/strong> poich\u00e9 questi sono i file che useremo come base per i nostri file di sviluppo.<\/p>\n<p>Questo \u00e8 un passaggio facoltativo; tuttavia, sono andato avanti e l&#8217;ho fatto perch\u00e9 \u00e8 cos\u00ec che preferisco lavorare. Ecco l&#8217;insieme di comandi che ho eseguito.<\/p>\n<p>Dalla directory <strong>css<\/strong> &#8230;<\/p>\n<pre><code>$ mkdir dev\n$ mv admin.css admin.scss &amp;&amp; mv widget.css widget.scss\n$ mv *.scss dev<\/code><\/pre>\n<p>Sopra, ho creato la directory <strong>dev<\/strong> per i miei fogli di stile, li ho rinominati in file Sass e li ho spostati nella directory <strong>dev<\/strong>.<\/p>\n<p>Prima di andare avanti, ora \u00e8 un buon momento per fare un controllo <strong>dello stato di git<\/strong> e confermare le modifiche relative ai fogli di stile:<\/p>\n<pre><code>$ git add. $ git commit -n -m \"Renaming and moving stylesheets into a dev directory.\"\n$ git push<\/code><\/pre>\n<p>Ora, dalla directory <strong>js<\/strong> &#8230;<\/p>\n<pre><code>$ mkdir dev\n$ mv *.js dev<\/code><\/pre>\n<p>Dal momento che non dobbiamo modificare il tipo di file dei file associati, possiamo semplicemente spostarli nella nuova directory.<\/p>\n<p>Infine, facciamo la stessa cosa e vediamo se ci sono modifiche che possiamo spingere attraverso un rapido controllo <strong>dello stato di git<\/strong> (che dovrebbe esserci). Ecco un elenco dei comandi che ho eseguito per eseguire il commit e il push delle mie modifiche:<\/p>\n<pre><code>$ git add. $ git commit -n -m \"Adding a JavaScript dev directory and moving the development files.\"\n$ git push<\/code><\/pre>\n<p>Abbiamo quasi finito. Tutto ci\u00f2 che resta da fare \u00e8 spostare determinate directory nella radice del repository e rinominare la directory principale in <strong>src<\/strong>. Quindi facciamolo ora.<\/p>\n<h3>Sposta le directory nella radice<\/h3>\n<p>In sostanza, dobbiamo spostare tutto tranne il file del plug-in e la directory <strong>Views<\/strong> fuori dalla directory <strong>widget-boilerplate<\/strong> e dobbiamo rinominare <strong>widget-boilerplate<\/strong> in <strong>src<\/strong>.<\/p>\n<p>Sembra semplice, vero? \u00c8 piuttosto semplice. Dall&#8217;interno della directory <strong>widget-boilerplate<\/strong> :<\/p>\n<pre><code>$ mv assets .. &amp;&amp; mv languages ..\n$ cd ..\n$ mv widget-boilerplate src<\/code><\/pre>\n<p>Quindi eseguir\u00f2 il commit della modifica su GitHub utilizzando quanto segue:<\/p>\n<pre><code>$ git add. $ git commit -n -m \"Reorganizing the directory structure.\"\n$ git push<\/code><\/pre>\n<p>Ora abbiamo una struttura di directory molto pi\u00f9 moderna impostata. Puoi vederlo qui <strong><a href=\"https:\/\/github.com\/tommcfarlin\/WordPress-Widget-Boilerplate\/tree\/develop\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">nel mio ramo di sviluppo<\/a><\/strong>.<\/p>\n<h3>Una parola sull&#8217;OOP<\/h3>\n<p>E ora che abbiamo tutto questo a posto, possiamo iniziare a scrivere codice. Ma non fraintenderti: una parte della programmazione orientata agli oggetti \u00e8 anche analisi orientata agli oggetti e progettazione orientata agli oggetti.<\/p>\n<p>Quello che abbiamo fatto in questo post \u00e8 essenzialmente applicare un progetto architettonico orientato agli oggetti basato sull&#8217;analisi di come il plugin si adatta insieme.<\/p>\n<p>La parte successiva, tuttavia, sta aggiornando il codice per eliminare tutto il rosso che abbiamo visto annusando il nostro codice.<\/p>\n<h2>Nel prossimo post<\/h2>\n<p>L&#8217;obiettivo principale del prossimo post \u00e8 continuare con l&#8217;aggiornamento degli standard di codifica in modo da aver risolto tutti i problemi generati dal nostro IDE o tramite gli strumenti di qualit\u00e0 del codice che stiamo eseguendo dalla riga di comando.<\/p>\n<p>Dovremmo anche avere un repository molto pi\u00f9 pulito e organizzato ed essere in una posizione in cui siamo pronti per unire il nostro lavoro al ramo principale.<\/p>\n<p>Per ora, per\u00f2, assicurati di avere una buona padronanza di tutto quanto sopra prima di procedere poich\u00e9 \u00e8 necessario capire per il resto del lavoro che abbiamo davanti a noi.<\/p>\n<p><div id=\"PostUnique_PostSource\" style=\"padding-top: 50px\">Fonte di registrazione:  <a target=\"_blank\" rel=\"noopener nofollow\" href=\"\/\/tommcfarlin.com\" class=\"external external_icon\">tommcfarlin.com<\/a><\/div><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Questo non solo migliorer\u00e0 la qualit\u00e0 del codice, ma ci guider\u00e0 anche attraverso alcuni principi orientati agli oggetti che possiamo applicare durante la creazione dei nostri widget WordPress.<\/p>\n","protected":false},"author":1,"featured_media":235111,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[896,720,865],"tags":[1168],"class_list":["post-231395","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-codice","category-sviluppatore","category-wordpress-6","tag-affiai-it"],"_links":{"self":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/231395","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/comments?post=231395"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/231395\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media\/235111"}],"wp:attachment":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media?parent=231395"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/categories?post=231395"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/tags?post=231395"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}