WordPress-widgets: Refactoring, del 1

Det förra inlägget innehöll mycket information om hur du ställer in kodkvalitetsverktyg i din WordPress-utvecklingsmiljö, men de är nödvändiga om vi ska göra mycket omfaktorer.

Men som jag nämnde i början av det här inlägget, ger läggande av kodkvalitetsverktyg oss först en grund som vi kan använda när vi refaktorerar boilerplate (vilket vi helt klart måste göra med tanke på mängden rött som visas av GrumPHP).

Ärligt talat ser jag dessa som nödvändiga om du ska göra någon typ av utveckling och därför måste du visa hur man ställer in dem.

Oavsett vilket visar det tidigare inlägget hur mycket arbete vi har lagt ner för oss, eller hur?

Nu ska vi börja med att omstrukturera WordPress Widget Boilerplate.

Detta kommer inte bara att förbättra kodkvaliteten utan också leda oss igenom några objektorienterade principer som vi kan tillämpa när vi bygger våra widgets och vi kan tillämpa i framtida WordPress-utvecklingsinsatser.

WordPress Widget Boilerplate: Refactoring, del 1

Det kanske mest spännande för mig är att få det här förrådet upp till modern standard. Om du tittar på mastergrenen i GitHub vid tidpunkten för detta inlägg (eller historien om förvaret senare), kommer du att se att den är sex år gammal.

Den här saken är sex år gammal (vid tidpunkten för detta inlägg).

Det är en lång tid i internetår, eller hur?

Hur som helst, i våra omstruktureringsansträngningar kommer vi att göra några saker:

• skapa en gren som du kan arbeta av innan den slås ihop igen i huvudgrenen,
• implementera ett mer sammanhållet sätt att organisera filer,
• uppdatera kodningsstandarderna för att följa det som är mer i linje med PSR,
• och mer.

Jag lägger ut det här nu eftersom vi troligen inte kommer att komma till allt i det här inlägget, men vi kommer att täcka mycket mark. Så med det sagt, låt oss börja.

1 Skapa en utvecklingsgren

Om du antar att du har en kopia av arkivet på din lokala dator, som du bör ha efter det sista inlägget, är det första vi behöver göra att skapa en gren som vi kan göra vårt arbete från.

Det är en bästa praxis att inte arbeta på mastergrenen. Istället bör mastern alltid användas för att distribuera den senaste stabila versionen av koden.

För detta ändamål anger du följande kommando i din terminal:

$ git checkout -b develop

Detta kommer att skapa en ny lokalavdelning. Det har ännu inte skjutits upp till GitHub eller ditt fjärrlager ännu (var du än förvarar det).

Skriv sedan in följande kommando:

$ git push --set-upstream origin develop

Detta kommer att driva utvecklingsgrenen upp till fjärrförvaret. När det är klart bör du kunna se alla ändringar som vi implementerade i det senaste inlägget i ditt fjärrlager.

Om du använder GitHub bör det se ut ungefär så här:

Om du använder en annan tjänst bör den fortfarande se likadan ut. Det vill säga att katalogstrukturen ska vara densamma, men hur den ser ut i webbläsaren kommer att variera.

En anteckning om filialen

Kom ihåg att syftet med denna gren är att vi ska göra allt vårt arbete. På så sätt stör vi inte mastergrenen från vilken många människor kommer att dra.

För att vara tydlig, kanske ingen kommer att dra sig ur detta. Kanske gör de det. Oavsett vilket är denna praxis som introduceras här menad att visa hur man kör ett projekt med hjälp av källkontroll och kodkvalitetsverktyg så att du kan bygga bättre projekt för dig själv, ditt företag och mer.

2 Omorganisera filer

Det första vi bör göra är att organisera om filerna så att de efterliknar en mer modern struktur. Jag ska göra mitt bästa för att motivera de beslut jag fattar för projektet när vi gör detta; ta dig dock friheter med hur du vill göra.

De beslut jag tar kommer i slutändan att påverka den primära Boilerplate. Vad du väljer att göra kommer att påverka hur du kan använda det i ditt dagliga arbete eller hur du väljer att gå vidare med projektet som helhet.

Uppdaterar kataloger

En av de saker jag försöker göra är att bryta ner mina kataloger, så att de är så tydliga som möjligt. Det betyder att jag försöker göra följande:

• skapa en tillgångskatalog för JavaScript och stilmallar,
• skapa en src- katalog för alla PHP-filer,
• skapa en språkkatalog för internationaliseringsfiler,
• behåll alla andra filer i roten av förvaret, så det är lätt för andra att följa med den medföljande README.

För att göra detta ska jag först ta bort och flytta några saker. Jag har försökt organisera detta i en viss ordning:

1. Jag ska ta bort filen README.txt. Den här filen används som en standard README-mall om du ska skicka kod till WordPress Plugin Repository, men det är inte nödvändigt för vad jag vill ha för Boilerplate.
2. Jag kommer att byta namn på plugin.php till Plugin .php för att följa PSR-konventioner.
3. Jag kommer också att byta namn på lang till språk.
4. Jag ska skapa en tillgångskatalog och flytta och sedan flytta css- och js- katalogerna till den katalogen. Jag kommer att skapa en dev -underkatalog i var och en av dessa kataloger där vi kan arbeta med Sass och unminifierade JavaScript-filer (som båda kommer senare i serien).
5. Efter det skapar jag en src- katalog och flyttar visningsformatmallen till den katalogen.
6. Jag kommer också att byta namn på vyer till vyer och även versaler i filerna som finns i den.
7. Slutligen ska jag flytta upp allt till roten av katalogen. Detta innebär att widget-boilerplate kommer att försvinna och alla filer kommer att finnas i rotkatalogen för förvaret.

Det är många steg, men de är små. Jag gillar att lägga ut dem först så att det är tydligt vad som kommer att hända under resten av det här avsnittet.

Ta bort README

För att göra detta, skriv bara in följande kommando i din terminal från roten av widget-boilerplate- katalogen:

$ rm readme.txt

Detta tar bort filen. Om du anger följande kommando i din terminal:

$ git status

Du borde se något sånt här:

Jag är ett fan av att se till att de olika förändringarna som drivs upp är tydliga och koncisa så att det är lättare att rulla tillbaka dem en i taget. Så låt oss gå vidare och engagera oss och driva på denna förändring.

Skriv följande:

$ git rm README.txt
$ git add. $ git commit -n -m "Removing the original README.txt template."
$ git push

Detta kommer att berätta för Git att ta bort filen, lägga till den enda ändringen i ändringsuppsättningen, utföra den utan att köra några kodkvalitetsverktyg (eftersom vi inte behöver göra det just nu, annars kommer det att misslyckas), och kommer att driva det till fjärrförvarets utvecklingsgren.

Nu när vi har gjort det, låt oss gå vidare och byta namn på några filer.

Byta namn på filer

Medan vi håller på kommer vi inte bara byta namn på plugin .php-filen utan även de andra PHP-filerna. Det här är filer som logiskt kan grupperas i samma ändringsuppsättning, så det är vettigt att gå vidare och göra det.

Så från din terminal, skriv in följande kommandon:

$ mv plugin.php Plugin.php
$ mv views/admin.php views/Admin.php
$ mv views/widget.php views/Widget.php

När vi gör detta har vi inte gjort några ändringar i filer ännu, så det finns inget att binda. Låt oss gå vidare med att byta namn på kataloger.

Skapa kataloger; Byt namn på kataloger

Precis som vi gjorde med filerna, låt oss gå vidare och skapa en ny tillgångskatalog. Ange följande kommando i din terminal:

$ mkdir assets

Därefter vill vi flytta css- och js- katalogerna till den katalogen så skriv in följande i terminalen också:

$ mv css assets
$ mv js assets

Och låt oss byta namn på lang – katalogen till Språk genom att ange följande kommando:

$ mv lang Languages

Låt oss slutligen byta namn på vyn till Views:

$ mv views Views

Vid det här laget har vi gjort allt vi kan med de filer som för närvarande finns i huvudkatalogen. Vi behöver dock fortfarande förbereda underkataloger för våra förbearbetade tillgångar.

Innan du gör det är det dock en god vana att köra en snabb git-statuskontroll för att se vad som finns som kan läggas till i en ändringsuppsättning. Om ditt förråd är som mitt, kommer du sannolikt att se något i stil med följande:

I det här fallet tycker jag att det är okej att lägga till allt i en enda ändringsuppsättning med en kommentar som indikerar att vi har bytt namn och flyttat filer.

Du kan skilja dig åt och i så fall är det helt okej. Dina kommandon kommer att skilja sig lite från mina men här är vad jag har för mitt engagemang:

$ git add. $ git commit -n -m "Creating new directories; Renaming files."
$ git push

Nu, vidare till underkatalogerna för våra förbearbetade filer.

Skapa underkataloger

I CSS-katalogen, skapa en underkatalog som heter dev och skapa en tom fil som heter admin.scss och widget.scss eftersom vi kommer att arbeta med dessa filer senare i serien.

Lägg sedan till en dev- katalog till JavaScript-katalogen och lägg till tomma admin.js -filer och widget.js- filer till dessa filer. Om du känner dig så benägen kan du flytta de redan existerande filerna till dev – katalogerna eftersom det här är filerna som vi kommer att använda som grund för våra utvecklingsfiler.

Det är ett valfritt steg; men jag har gått vidare och gjort det eftersom det är så jag föredrar att arbeta. Här är uppsättningen av kommandon som jag har kört.

Från css- katalogen…

$ mkdir dev
$ mv admin.css admin.scss && mv widget.css widget.scss
$ mv *.scss dev

Ovan har jag skapat dev- katalogen för mina stilmallar, döpt om dem till Sass-filer och flyttat dem till dev- katalogen.

Innan du går vidare, låt det nu vara en bra tid att göra en git-statuskontroll och genomföra ändringar relaterade till stilmallarna:

$ git add. $ git commit -n -m "Renaming and moving stylesheets into a dev directory."
$ git push

Nu, från js- katalogen…

$ mkdir dev
$ mv *.js dev

Eftersom vi inte behöver ändra filtypen för de associerade filerna kan vi helt enkelt flytta dem till den nya katalogen.

Slutligen, låt oss göra samma sak och se om det finns några ändringar som vi kan driva upp genom en snabb git-statuskontroll (vilket det borde finnas). Här är en lista över de kommandon jag körde för att utföra och driva mina ändringar:

$ git add. $ git commit -n -m "Adding a JavaScript dev directory and moving the development files."
$ git push

Vi är nästan klara. Allt som återstår att göra är att flytta vissa kataloger till roten av förvaret och byta namn på kärnkatalogen till src. Så låt oss göra det nu.

Flytta kataloger till roten

I huvudsak måste vi flytta allt utom plugin-filen och Views – katalogen från widget-boilerplate- katalogen, och vi måste byta namn på widget-boilerplate till src.

Låter enkelt, eller hur? Det är ganska okomplicerat. Från widget-boilerplate- katalogen:

$ mv assets .. && mv languages ..
$ cd ..
$ mv widget-boilerplate src

Sedan gör jag ändringen till GitHub med följande:

$ git add. $ git commit -n -m "Reorganizing the directory structure."
$ git push

Nu har vi en mycket modernare katalogstruktur inrättad. Du kan se det här i min utvecklingsgren.

Ett ord om OOP

Och nu när vi har allt detta på plats kan vi börja skriva kod. Men missa dig inte: En del av objektorienterad programmering är också objektorienterad analys och objektorienterad design.

Vad vi har gjort i det här inlägget är i huvudsak att tillämpa en objektorienterad arkitektonisk design baserad på analysen av hur pluginet passar ihop.

Nästa del är dock att uppdatera koden för att bli av med allt rött vi har sett när vi sniffade vår kod.

I nästa inlägg

Det primära målet med nästa inlägg är att fortsätta med att uppdatera kodningsstandarderna så att vi har löst alla problem som orsakas av vår IDE eller genom kodkvalitetsverktygen vi kör på kommandoraden.

Vi borde också ha ett mycket renare, mer organiserat förråd och vara i en position där vi är redo att slå samman vårt arbete tillbaka till huvudgrenen.

För nu, se dock till att du har ett bra grepp om allt ovan innan du fortsätter eftersom det är nödvändigt att förstå för resten av det arbete vi har framför oss.