Flux de lucru modern de dezvoltare WordPress cu stiva Roots

WordPress există de secole, cel puțin după standardele de internet, iar filozofia sa a fost întotdeauna să păstreze compatibilitatea cu versiunea anterioară. Acest accent pe compatibilitate este de înțeles, având în vedere numărul mare de site-uri web WordPress online astăzi. Cu toate acestea, deși acest lucru îi poate ajuta pe cei care încă folosesc medii vechi cu versiuni vechi PHP și MySQL (care reprezintă un risc de securitate în sine, dar acesta nu este subiectul articolului de astăzi), a făcut ca versiunile mai noi WordPress să nu folosească pe deplin cele mai recente capabilități PHP.

Acest lucru a făcut, de asemenea, mulți dezvoltatori WordPress să trăiască într-o bula WordPress, nefiind stimulați să învețe tehnologii de dezvoltare front-end noi și moderne și, uneori, să rămână blocați în „modul vechi” de a face lucrurile.

Puteți adopta un flux de lucru de dezvoltare modernă pentru WordPress?

Cu siguranță că puteți, iar stiva WordPress Roots este aici pentru a vă ajuta să vă dezvoltați ca în 2019, cu trei instrumente uimitoare:

• Sage ca temă de pornire,
• Bedrock ca o placă modernă WordPress,
• Trellis pentru a gestiona implementarea și furnizarea în diferite medii.

Echipa Roots are, de asemenea, două instrumente suplimentare în dezvoltare: Acorn, un cadru de construire a pluginurilor și Clover, un plugin de tip boilerplate. Datorită faptului că ambele sunt în alfa, nu sunt incluse în acest articol, dar cu siguranță ar trebui să fii cu ochii pe ele.

Ce este exact stiva de rădăcini

Cunoscută inițial ca tema Roots, a fost o temă de pornire HTML5 solidă, menită să ofere un punct de plecare mai curat pentru noile site-uri web WordPress. De-a lungul timpului, a evoluat într-un set complet de instrumente, trecând prin toate tehnologiile și standardele web moderne majore (de la Grunt la Gulp și Webpack, LESS și SCSS, NPM și Yarn, Bootstrap, standardele de codare PSR-2 și principiul DRY), forțând astfel dezvoltatorii WordPress care l-au adoptat să învețe continuu și să rămână la curent cu ceea ce au de oferit tehnologiile moderne de dezvoltare front-end.

Astăzi, Roots a devenit un set complet de instrumente în expansiune continuă, menite să vă ajute să construiți site-uri WordPress mai bune, urmând întregul ciclu, de la dezvoltare până la punere în scenă și producție, și făcându-vă un dezvoltator mai bun, forțându-vă să ieșiți din confort. zonă oferită de așa-numita bulă WordPress.

Dar haideți să aruncăm o privire la cele trei instrumente principale pe care le oferă, care sunt acestea și de ce ar trebui să vă gândiți să le utilizați.

Roots Sage 9

Roots Sage 9 este ultima iterație a unei teme de pornire WordPress întreținute profesional, lansată inițial doar ca Roots în 2011. Pe parcursul vieții sale, a trecut prin multe schimbări, îmbunătățiri și reconsiderări ale celor mai bune practici, pentru a deveni în sfârșit ceea ce astăzi este un punct de plecare excelent pentru a introduce fluxul de lucru modern de dezvoltare front-end pentru dezvoltarea WordPress.

Ceea ce încearcă Sage să facă este să adopte un model MVC (Model-View-Controller) în care vizualizările și controlerul sunt complet separate; acest lucru ne permite să reutilizam Vizualizări, care nu trebuie neapărat să „știe” de unde provin datele, ci pur și simplu așteaptă ca un Controller să le furnizeze câteva date pentru afișare.

Controlerul inclus cu Sage 9 nu este controlerul real cu care ați putea fi deja familiarizat în alte cadre precum Laravel, principala diferență este că Sage 9 Controller utilizează o rutare bazată pe șablon în loc de o rutare bazată pe URL. Practic, lăsați WordPress să se ocupe de rutarea URL și scrieți controlere pentru fișierele șablon.

Adăugând câteva grade de complexitate întregului proces de dezvoltare, Sage 9 s-ar putea să nu fie cea mai bună alegere pentru a începe pentru începători, deoarece veți avea destul de mult de învățat pentru a-l stăpâni în cele din urmă și a fi capabil să îl utilizați în producție: corect gestionarea dependenței și a activelor, versiunea codului, o nouă structură de proiect, un nou motor de șablon derivat din Laravel, principiul DRY (Don’t Repeat Yourself) și va trebui să respectați standarde stricte de codare, care sunt puțin diferite de ceea ce WordPress recomandă; dar dacă sunteți un dezvoltator experimentat, poate fi un avantaj excelent.

Dacă doriți să mergeți all-in cu Sage, țineți cont de acest sfat de la Ben Word, unul dintre dezvoltatorii echipei Roots:

Sage nu este un cadru de temă, este o temă de pornire. Rareori ar trebui să fie nevoie să-l actualizați și, de obicei, nu ar trebui să creați teme secundare din acesta. Fiind o temă de pornire, Sage este menită să fie folosită ca punct de plecare într-un nou proiect.

Dar deasemenea:

Dacă Underscores este un avans de 1.000 de ore, Sage este un avans de 10.000 de ore.

Structura fișierelor și folderelor cu Sage

Structura fișierelor și folderelor din Sage este puțin diferită de ceea ce suntem obișnuiți să vedem în alte teme de pornire, cum ar fi Underscores, sau chiar în versiunea majoră anterioară a Sage 8.

Iată ce veți găsi imediat după instalarea Sage:

 ├── app/ # it contains all the PHP code of your theme │ ├── controllers/ # your Controllers, it already contains a few │ │ # examples to use as a starting point │ ├── admin.php # setup for the WordPress theme customizer │ ├── filters.php # a good place to group all your theme │ │ # filter hooks │ ├── helpers.php # for various helper functions you want │ │ # to reuse in your theme │ └── setup.php # the main theme setup file ├── config/ # theme configuration files ├── dist/ # all built theme assets, never edit this! ├── resources/ # original theme assets, edit this instead! │ ├── assets/ # all front-end assets │ │ ├── build/ # Webpack and ESLint config │ │ ├── fonts/ # theme fonts │ │ ├── images/ # theme images │ │ ├── scripts/ # theme JS scripts │ │ ├── styles/ # theme SCSS stylesheets │ │ └── config.json # settings for compiled assets │ ├── views/ # all theme Blade templates │ │ ├── layouts/ # base Blade templates │ │ └── partials/ # partial Blade templates │ ├── functions.php # Composer autoloader and theme includes, │ │ # normally you should not edit this unless │ │ # you know what you're doing │ ├── index.php # required by WordPress but left blank │ │ # intentionally, never edit this! │ ├── screenshot.png # the screenshot used in the WordPress admin │ └── style.css # required by WordPress, it should contain │ # only the theme meta information ├── vendor/ # Composer packages, never edit this! ├── composer.json # autoloading for `app/` files ├── composer.lock # Composer lock file, never edit this └── package.json # Node.js dependencies and scripts

În plus, alte fișiere utilizate de editorii de cod și IDE-uri, cum ar fi .editorconfig, .eslintrc.js, .stylelintrc.js, phpcs.xml etc.

Iată o prezentare rapidă a cerințelor de bază pentru Sage 9:

• WordPress >= 4.7
• PHP >= 7.1.3 (cu php-mbstring activat)
• Compozitor
• Node.js >= 8.0.0
• Fire

Roca de bază

Bedrock este ca WordPress pe steroizi!

Dacă Sage vă îmbunătățește dezvoltarea temei, Bedrock îmbunătățește întreaga instalare WordPress. O face prin furnizarea unui proiect modern , cu o structură de foldere și securitate îmbunătățite (de exemplu, prin faptul că nu aveți fișierele de configurare în rădăcina site-ului), fișiere de configurare și ENV și o gestionare adecvată a dependenței (da, inclusiv pluginuri și teme WordPress) .

Pentru a o descrie într-o singură frază, am putea spune că Bedrock este un proiect WordPress autonom care automatizează instalarea fișierelor de bază și a pluginurilor necesare.

Structura fișierelor și folderelor

Dacă te uiți la o instalație de bază Bedrock, s-ar putea să te simți pierdut la început. Bedrock separă fișierele web, de configurare și de dependență în propriile foldere. Iată cum arată structura osoasă goală:

 ├── config/ # WordPress configuration files │ ├── environments/ # configuration files for other │ │ │ # environments, they will override │ │ │ # production configuration │ │ ├── development.php # overrides for WP_ENV === 'development' │ │ └── staging.php # overrides for WP_ENV === 'staging' │ └── application.php # main configuration for production │ # environment, it's the equivalent of │ # the wp-config.php file ├── vendor/ # Composer packages, never edit this! ├── web/ # the new root folder of the webserver │ ├── app/ # your new wp-content folder │ ├── wp/ # WordPress core files, never edit this! │ ├── index.php # WordPress view bootstrapper │ └── wp-config.php # required by WordPress, never edit this! ├── .env # all environment variables: db name, │ # user and password, salts, current │ # environment, site urls, and others ├── composer.json # here you can manage versions of │ # WordPress, plugins and other │ # dependencies └── composer.lock # Composer lock file, never edit this

Plus câteva fișiere mai puțin importante.

Cerințele de bază sunt:

• PHP >= 7.1
• Compozitor

Spalier

Trellis este o stivă LEMP modernă pentru a vă gestiona serverele de dezvoltare, punere în scenă și producție fără probleme, având ca scop menținerea lor cât mai asemănătoare între ele („paritate de dezvoltare și producție”). Aceasta înseamnă că, dacă site-ul dvs. personalizat WordPress funcționează în mediul dvs. de dezvoltare, este sigur să presupuneți că va funcționa și în producție și puteți implementa cu încredere.

Pentru dezvoltarea locală, Trellis folosește Vagrant, cu un simplu vagrant up veți avea o mașină virtuală care rulează un mediu modern adecvat.

Aprovizionarea și implementarea în mediile dvs. de organizare și producție sunt gestionate cu manualele Ansible, care sunt fișiere YAML care îi spun lui Ansible ce trebuie să facă.

Structura de foldere sugerată cu spalier

Trellis are o structură de foldere sugerată compusă din doar două subdirectoare:

 ├── trellis/ # the clone of the Trellis repository └── site/ # the Bedrock-based WordPress website

Aș recomanda să-l lași așa, dar poate fi personalizat în funcție de preferințele și nevoile tale.

Cerințe pentru spalier

• Compozitor
• Virtualbox >= 4.3.10
• Vagabond >= 2.1.0

De ce ar trebui să-l folosești

Dacă WordPress funcționează deja așa cum este, de ce ar trebui să treceți la o stivă mai complexă și să petreceți o perioadă considerabilă de timp pentru a-l stăpâni? Pentru că există avantaje evidente și unele mai puțin evidente. Să încercăm să vedem care sunt.

O temă de pornire agnostică a cadrului

Prea multe teme de pornire WordPress te obligă să folosești un cadru CSS specific pe care s-ar putea să nu-ți placă sau chiar să-l cunoști, dar Sage este complet agnostic de cadru. În timpul instalării, veți avea opțiunea de a include automat Bootstrap 4, Bulma, Foundation, Tachions, Tailwind CSS sau nici un cadru dacă doriți să începeți de la zero sau să folosiți altceva (Sfat: în ultimul timp începe să-mi placă Tailwind CSS foarte mult).

SFAT PRO: pe o mașină Windows, este posibil să primiți mesajul „Modul TTY nu este acceptat pe platforma Windows” în timpul instalării și nu veți putea alege un cadru sau configura Sage. Va trebui să rulați aceste trei comenzi manual din folderul cu teme dacă doriți să profitați de configurația automată:

 $ vendor\bin\sage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendor\bin\sage config # to specify your theme's dev URL and # theme directory. $ vendor\bin\sage preset # to set up the theme with one of the # supported frameworks or no # framework at all.

Un proces de construcție modern

Cu Webpack, inclus în Sage, nu va mai trebui să vă gândiți la compilarea activelor, concatenarea și minimizarea codului JavaScript și CSS, optimizarea imaginilor, verificarea erorilor JavaScript și de stil și gestionarea bibliotecilor externe. Procesul de construire se va ocupa de toate acestea cu o simplă yarn build (sau yarn build:production dacă doriți ca activele dvs. să fie optimizate pentru utilizarea în producție), producând toate fișierele statice din folderul tema /dist/ .

PHP modern și cerințe

Versiunea PHP minimă pe care puteți rula WordPress este PHP 5.2.4, aceasta va asigura compatibilitatea cu versiunea anterioară tuturor acelor utilizatori care își rulează site-urile web într-un mediu vechi, dar versiunile vechi de PHP (<= 7.0) au ajuns oficial la End Of Viață, deci nu mai sunt acceptate și vă pot expune site-ul la vulnerabilități de securitate și probleme de performanță.

Atât Sage, cât și Bedrock necesită o versiune corectă a PHP 7.1 (deși dacă aveți opțiunea de a alege 7.3, vă rugăm să faceți acest lucru).

De asemenea, Sage 9 adoptă pe deplin standardele de codare PSR-2 (cea mai utilizată și acceptată codare

standardele utilizate în comunitatea PHP), care sunt puțin diferite de standardele de codare WordPress, dar vă permit să aveți un cod mai curat și mai ușor de întreținut, mai ales dacă lucrați în echipă sau trebuie să vă împărtășiți codul cu alții.

Dependențe și management de pachete mai bun

Stiva Roots folosește în mare măsură Composer pentru a gestiona toate dependențele și pachetele, inclusiv nucleul WordPress, pluginurile și temele. Aceasta ar putea fi o problemă dacă utilizați instrumente terță parte pentru a gestiona actualizările WordPress (cum ar fi ManageWP, MainWP sau InfiniteWP), dar cineva ar putea argumenta că a avea totul sub controlul versiunii vă oferă mai mult control și face mai ușor să reveniți la o activitate anterioară. versiunea dacă ceva nu merge bine.

În plus, Sage folosește Yarn ca manager de pachete și dependențe pentru codul aplicației și pentru a lansa procesul de construire.

Fișiere șablon mai bune

WordPress nu are un adevărat motor de șabloane, așa că, pentru a compensa, Sage a adoptat Laravel's Blade și urmează principiul DRY: Don't Repeat Yourself.

Așa arată fișierul șablon implicit single.blade.php, doar 6 linii de cod:

 @extend('layouts.app') @section('content') @while(have_posts()) @php the_post() @endphp @include('partials.content-single-'.get_post_type()) @endwhile @endsection

Motorul de șablon Blade separă complet vizualizările și controlerele, iar sintaxa sa este mai elegantă, concisă, mai ușor de citit și mai ușor de scris decât doar etichetele PHP. Regula de bază aici este să nu lăsați tot codul PHP din fișierele șablon (sau cel puțin să încercați).

Un alt avantaj al utilizării Blade este moștenirea șablonului: un șablon de bază de aspect (prestabilit este /resources/views/layouts/app.blade.php ) definește blocuri care conțin elementele comune ale site-ului web, care sunt apoi moștenite de șabloanele sale secundare. Moștenirea șabloanelor este excelentă pentru a elimina marcajele repetate din șabloanele individuale și pentru a menține lucrurile USCATE.

Sincronizare browser

Prin rularea yarn start , veți lansa o sesiune Browsersync. Browsersync este un modul pentru testarea sincronizată a browserului în timpul dezvoltării. Acesta va urmări modificările aduse activelor dvs. front-end și, lucrând împreună cu Webpack, va injecta automat modificările în sesiunea dvs. de browser.

Implementare WordPress rapidă, ușoară și sigură

Trellis oferă implementări WordPress fără timpi de nefuncționare. Când lansați o implementare, Trellis va clona depozitul dvs., va rula instalarea compozitorului și apoi va actualiza linkul simbolic la versiunea curentă, astfel încât să nu editeze niciodată direct fișierele care sunt difuzate în prezent în producție.

Când utilizați Bedrock, Trellis necesită, de asemenea, foarte puțină configurație.

Dezavantaje

Singurul dezavantaj al utilizării întregului stack Roots (în afară de a învăța lucruri noi, care nu ar trebui să fie deloc o problemă) este că trebuie să utilizați un furnizor de găzduire prietenos cu Trellis, cum ar fi Kinsta, o picătură DigitalOcean sau orice altă gazdă care acceptă cel puțin SSH, Composer și WP-CLI, împreună cu opțiunea de a actualiza calea rădăcină web.

Acest lucru lasă în afara jocului majoritatea găzduirii partajate ieftine și este ceva ce tu și/sau clientul tău trebuie să ții cont înainte de a începe un nou proiect.

Cum să începeți

Aceasta poate fi considerată o nouă interpretare a faimoasei „Instalare WordPress în 5 minute”, dar pentru dezvoltatorii moderni front-end. Adaugă câteva grade de complexitate pentru dezvoltarea ulterioară, dar în final, beneficiile pe care le poți obține merită cu siguranță.

Ne vom concentra pe adoptarea stivei complete (Sage, Bedrock și Trellis), dar puteți utiliza doar una sau orice combinație a acestora. Sage poate fi folosit ca punct de plecare pentru o temă de sine stătătoare pe orice instalare WordPress; Bedrock poate fi folosit cu orice temă WordPress doriți; și implementările Trellis sunt configurate pentru site-urile bazate pe Bedrock și se ocupă de tot ce este necesar, dar cu puțină reparație, poate fi personalizat pentru aproape orice nevoie.

Cum se creează un proiect nou

Configurarea unui nou proiect WordPress cu Trellis, Bedrock și Sage este destul de ușoară, la doar câteva linii de comandă distanță.

Instalați Trellis în folderul dorit (de exemplu, example.com ):

 $ mkdir example.com && cd example.com $ git clone --depth=1 [email protected]:roots/trellis.git $ rm -rf trellis/.git

Instalați Bedrock în subdosarul /site/ :

 $ composer create-project roots/bedrock site $ cd site/web/app/themes/

Instalați și construiți Sage:

 $ composer create-project roots/sage your-theme-name $ cd your-theme-name/ $ yarn && yarn build

Desfășurare

Implementarea în staging sau producție este și mai ușoară dacă ați configurat totul corect, conform documentației oficiale. Este la doar o linie de comandă distanță (a rulat din folderul example.com/trellis/ ):

 $ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"

De asemenea, puteți derula cu ușurință implementarea, doar rulați:

 $ ansible-playbook rollback.yml -e "site=<domain> env=<environment>

Sfaturi despre configurarea mediului de dezvoltare pe Windows

Dacă căutați pe Google despre cum să instalați și să utilizați stiva Roots, în special Trellis, veți găsi o mulțime de tutoriale axate pe Linux sau MacOS, dar sunt disponibile foarte puține informații pentru Windows, unde veți găsi două probleme principale: Ansible nu este disponibil pentru Windows, iar Vagrant este de obicei extrem de lent pe mașinile Windows.

Când m-am gândit inițial la acest articol, documentația oficială Trellis pentru Windows sugera să rulăm Ansible în interiorul mașinii virtuale Vagrant, dar acesta a fost un fel de hackery mod de a face lucrurile și nu era foarte de încredere.

De atunci, au actualizat documentația cu instrucțiuni adecvate despre configurarea totul cu WSL (Windows Subsystem for Linux), așa că nu este nevoie să reinventăm roata și să scrieți un tutorial despre aceasta. Este bine să știți că există trei pagini de instrucțiuni detaliate pas cu pas pe care le puteți urma înainte de a instala Trellis: Windows Setup, Windows Setup: Sage și Windows Setup: Trellis.

Codare fericită!