WordPressi vidinad: ümbertöötamine, 1. osa

Viimane postitus sisaldas palju teavet koodikvaliteedi tööriistade seadistamise kohta teie WordPressi arenduskeskkonnas, kuid need on vajalikud, kui kavatseme teha palju ümbertegemist.

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

Ausalt öeldes pean neid vajalikuks, kui kavatsete teha mis tahes arendustegevust, seega on vaja näidata, kuidas neid seadistada.

Sellest hoolimata näitab eelmine postitus, kui palju tööd oleme enda jaoks ära näinud, eks?

Nüüd alustame WordPressi vidina katlaplaadi ümbertöötamisega.

See mitte ainult ei paranda koodi kvaliteeti, vaid tutvustab meile ka mõningaid objektorienteeritud põhimõtteid, mida saame rakendada oma vidinate loomisel ja mida saame rakendada tulevastes WordPressi arendustegevuses.

WordPressi vidina katlaplaat: ümberkujundamine, 1. osa

Võib-olla on minu jaoks kõige põnevam viia see hoidla kaasaegsetele standarditele. Kui vaatate GitHubi põhiharu selle postituse ajal (või hoidla ajalugu hiljem), näete, et see on kuus aastat vana.

See asi on kuus aastat vana (selle postituse ajal).

Interneti-aastatel on see pikk aeg, kas pole?

Igatahes teeme oma ümberkujundamispüüdlustes mõningaid asju:

• luua haru, millest edasi töötada, enne kui ühendate selle tagasi põhiharuga,
• failide ühtsema korraldamise viisi rakendamine,
• kodeerimisstandardite värskendamine, et järgida seda, mis on PSR-iga rohkem kooskõlas,
• ja veel.

Panen selle nüüd välja, sest tõenäoliselt ei jõua me selles postituses selle kõige juurde, kuid käsitleme palju. Nii et alustame sellega.

1 Arendusharu loomine

Eeldades, et teie kohalikus masinas on hoidla koopia, mis peaks teil olema pärast viimast postitust, on esimene asi, mida peame tegema, looma haru, millest oma tööd teha.

Parim tava on mitte töötada põhiharuga. Selle asemel tuleks koodi uusima stabiilse versiooni juurutamiseks alati kasutada juhtseadet.

Selleks sisestage oma terminali järgmine käsk:

$ git checkout -b develop

See loob uue kohaliku filiaali. Seda pole veel GitHubisse ega teie kaughoidlasse üles tõstetud (ükskõik, kus te seda ka ei hoiaks).

Järgmisena sisestage järgmine käsk:

$ git push --set-upstream origin develop

See viib arendusharu üles kaughoidlasse. Kui see on tehtud, peaksite nägema kõiki muudatusi, mille me teie kaughoidlas viimases postituses rakendasime.

Kui kasutate GitHubi, peaks see välja nägema umbes selline:

Kui kasutate mõnda muud teenust, peaks see siiski sarnane välja nägema. See tähendab, et kataloogistruktuur peaks olema sama, kuid see, kuidas see brauseris välja näeb, on erinev.

Märkus filiaali kohta

Pidage meeles, et selle haru eesmärk on teha kogu oma töö. Nii ei sega me põhiharu, millest paljud inimesed tõmbavad.

Selguse huvides, võib-olla ei tõmba sellest keegi. Võib-olla saavad. Sellest hoolimata on siin tutvustatud tavade eesmärk näidata, kuidas projekti käivitada lähtekoodi ja koodikvaliteedi tööriistade abil, et saaksite luua paremaid projekte enda, oma ettevõtte ja muu jaoks.

2 Failide ümberkorraldamine

Esimene asi, mida peaksime tegema, on failid ümber korraldada, et need jäljendaksid moodsamat struktuuri. Annan endast parima, et õigustada otsuseid, mida ma selle projekti jaoks teeme; kuid võite vabalt valida, kuidas soovite seda teha.

Minu tehtud otsused mõjutavad lõppkokkuvõttes esmast Boilerplate’i. See, mille valite, mõjutab seda, kuidas saate seda oma igapäevases töös kasutada või kuidas otsustate projektiga tervikuna edasi liikuda.

Kataloogide värskendamine

Üks asi, mida ma üritan teha, on oma kataloogid lahti murda, et need oleksid võimalikult selged. See tähendab, et proovin teha järgmist:

• luua JavaScripti ja stiilitabelite jaoks varade kataloog,
• luua src kataloog kõigi PHP-failide jaoks,
• luua rahvusvaheliste failide jaoks keelekataloog,
• hoidke kõik muud failid hoidla juurtes, nii et teistel oleks lihtne koos kaasasoleva README-ga jälgida.

Selleks eemaldan ja teisaldan esmalt mõned asjad. Olen püüdnud korraldada seda kindlas järjekorras:

1. Ma eemaldan faili README.txt. Seda faili kasutatakse standardse README mallina, kui kavatsete koodi WordPressi pistikprogrammide hoidlasse esitada, kuid see pole vajalik selleks, mida ma Boilerplate’i jaoks tahan.
2. Nimetan plugin.php ümber Plugin .php-ks, et järgida PSR-i tavasid.
3. Nimetan langi ka ümber keelteks.
4. Ma loon varade kataloogi ja teisaldan seejärel css- ja js -kataloogid sellesse kataloogi. Ma loon igasse nendesse kataloogidesse arendaja alamkataloogi, kus saame töötada Sassi ja minimeerimata JavaScripti failidega (mõlemad tulevad sarja hiljem).
5. Pärast seda loon src kataloogi ja teisaldan vaadete laaditabeli sellesse kataloogi.
6. Nimetan vaated ümber ka vaadeteks ja kirjutan ka selles sisalduvad failid suurtähtedega.
7. Lõpuks tõstan kõik kataloogi juure. See tähendab, et widget-boilerplate kaob ja kõik failid asuvad hoidla juurkataloogis.

Neid samme on palju, kuid need on väikesed. Mulle meeldib need kõigepealt paika panna, et oleks selge, mis selle osa ülejäänud osas juhtub.

Eemaldage README

Selleks sisestage lihtsalt vidina-boilerplate kataloogi juurest oma terminali järgmine käsk:

$ rm readme.txt

See eemaldab faili. Kui sisestate terminali järgmise käsu:

$ git status

Peaksite nägema midagi sellist:

Olen selle fänn, et erinevad ülestõstetud muudatused oleksid selged ja ülevaatlikud, et oleks lihtsam neid ükshaaval tagasi kerida. Nii et lähme edasi ning pühendume ja lükkame selle muudatuse edasi.

Sisestage järgmised:

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

See käsib Gitil faili eemaldada, lisada muudatuste komplekti ühe muudatuse, kinnitada selle ilma koodikvaliteedi tööriistu käivitamata (sest me ei pea seda praegu tegema, muidu see ebaõnnestub) ja lükkab selle edasi. kaughoidla arendusharusse.

Nüüd, kui see on tehtud, nimetame mõned failid ümber.

Failide ümbernimetamine

Selle juures ei nimeta me mitte ainult pistikprogrammi .php faili, vaid ka teisi PHP-faile. Need on failid, mida saab loogiliselt rühmitada samasse muudatuste komplekti, seega on mõistlik seda teha.

Nii et sisestage oma terminalist järgmised käsud:

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

Seda tehes pole me failides veel muudatusi teinud, seega pole midagi siduda. Liigume edasi kataloogide ümbernimetamisega.

Loo kataloogid; Nimeta kataloogid ümber

Nii nagu tegime failide puhul, loome uue varade kataloogi. Sisestage terminalis järgmine käsk:

$ mkdir assets

Järgmisena tahame teisaldada css- ja js -kataloogid sellesse kataloogi, nii et sisestage terminali ka järgmine:

$ mv css assets
$ mv js assets

Ja nimetame keelekataloogi ümber Keelteks, sisestades järgmise käsu:

$ mv lang Languages

Lõpuks nimetame vaate ümber vaateks:

$ mv views Views

Siinkohal oleme teinud kõik, mis võimalik, praegu põhikataloogis olevate failidega. Peame siiski oma eeltöödeldud varade jaoks alamkataloogid ette valmistama.

Enne selle tegemist on aga hea harjumus käivitada kiire giti olekukontroll, et näha, mis on olemas, mida saab muudatuste komplekti lisada. Kui teie hoidla sarnaneb minu omaga, näete tõenäoliselt järgmist:

Sel juhul arvan, et on okei lisada kõik ühte muudatuskomplekti koos kommentaariga, mis näitab, et oleme failid ümber nimetanud ja teisaldanud.

Võite erineda ja kui jah, siis on see täiesti korras. Teie käsud erinevad veidi minu omadest, kuid mul on oma kohustuse jaoks järgmised käsud:

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

Nüüd meie eeltöödeldud failide alamkataloogide juurde.

Looge alamkataloogid

Looge CSS-i kataloogis alamkataloog nimega dev ja tühi fail nimega admin.scss ja widget.scss, kuna me töötame nende failidega sarjas hiljem.

Järgmisena lisage JavaScripti kataloogi dev kataloog ja lisage nendele failidele tühjad failid admin.js ja widget.js failid. Kui tunnete nii soovi, võite teisaldada olemasolevad failid arendajakataloogidesse, kuna need on failid, mida me kasutame oma arendusfailide alusena.

See on valikuline samm; aga ma olen seda teinud, sest nii eelistan tööd teha. Siin on käskude komplekt, mille olen käivitanud.

css -i kataloogist…

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

Eespool olen loonud oma stiilitabelite jaoks dev kataloogi, nimetanud need ümber Sassi failideks ja teisaldanud need dev kataloogi.

Enne edasiliikumist olgu nüüd hea aeg giti oleku kontrollimiseks ja stiilitabelitega seotud muudatuste tegemiseks:

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

Nüüd js -i kataloogist…

$ mkdir dev
$ mv *.js dev

Kuna me ei pea seotud failide failitüüpe muutma, saame need lihtsalt uude kataloogi teisaldada.

Lõpetuseks teeme sama asja ja vaatame, kas on mingeid muudatusi, mida saaksime kiire giti olekukontrolli kaudu (mis peaks olema). Siin on nimekiri käskudest, mida ma muudatuste kinnitamiseks ja edastamiseks käivitasin:

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

Oleme peaaegu valmis. Jääb üle vaid teatud kataloogid hoidla juure teisaldada ja põhikataloog ümber nimetada src. Nii et teeme seda nüüd.

Teisalda kataloogid juure

Sisuliselt peame widget-boilerplate kataloogist välja teisaldama kõik peale pistikprogrammi faili ja kataloogi Views ning me peame widget-boilerplate ümber nimetama src.

Kõlab lihtsalt, eks? See on päris otsekohene. Widget-boilerplate’i kataloogist :

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

Seejärel teen muudatuse GitHubis, kasutades järgmist:

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

Nüüd on meil loodud palju kaasaegsem kataloogistruktuur. Seda näed siin minu arendusharus.

Mõni sõna OOP-i kohta

Ja nüüd, kui meil on see kõik paigas, saame hakata koodi kirjutama. Kuid ärge eksige: osa objektorienteeritud programmeerimisest on ka objektorienteeritud analüüs ja objektorienteeritud disain.

See, mida me selles postituses tegime, on sisuliselt objektorienteeritud arhitektuurse disaini rakendamine, mis põhineb pistikprogrammi kokkusobivuse analüüsil.

Järgmine osa on aga koodi värskendamine, et vabaneda kogu punasest, mida oleme koodi nuusutamisel näinud.

Järgmises postituses

Järgmise postituse peamine eesmärk on jätkata kodeerimisstandardite värskendamist, et oleksime lahendanud kõik meie IDE või käsureal kasutatavate koodikvaliteedi tööriistade tekitatud probleemid.

Meil peaks olema ka palju puhtam ja paremini organiseeritud hoidla ning me peaksime olema valmis oma töö tagasi põhiharusse liitma.

Praegu aga veenduge enne jätkamist, et oleksite kõigega ülaltoodud asjadega hästi hakkama saanud, kuna see on vajalik ülejäänud töö jaoks, mis meid ees ootab.