Învârtirea locală a mai multor site-uri WordPress cu DevKinsta

Acest articol a fost susținut cu amabilitate de dragii noștri prieteni de la DevKinsta, care ajută atât de mulți dezvoltatori, web designeri și freelanceri să proiecteze, să dezvolte și să implementeze site-urile lor WordPress din toată lumea. Mulțumesc!

Când construim teme și pluginuri pentru WordPress, trebuie să ne asigurăm că funcționează bine în toate mediile diferite în care vor fi instalate. Uneori putem controla acest mediu atunci când creăm o temă pentru propriile noastre site-uri web, dar alteori nu putem, cum ar fi când distribuim pluginurile noastre prin intermediul depozitului public WordPress pentru ca oricine să le descarce și să o instaleze.

În ceea ce privește WordPress, posibilele combinații de medii pentru care să ne îngrijorăm includ:

• Diferite versiuni de PHP,
• Diferite versiuni de WordPress,
• Diferite versiuni ale editorului WordPress (alias editorul bloc),
• HTTPS activat/dezactivat,
• Multisite activat/dezactivat.

Să vedem cum este cazul. PHP 8.0, care este cea mai recentă versiune de PHP, a introdus modificări de ultimă oră față de versiunile anterioare. Deoarece WordPress încă acceptă oficial PHP 5.6, pluginul nostru poate avea nevoie să accepte 7 versiuni de PHP: PHP 5.6, plus PHP 7.0 până la 7.4, plus PHP 8.0. Dacă pluginul necesită o caracteristică specifică a PHP, cum ar fi proprietățile tastate (introduse în PHP 7.4), atunci va trebui să accepte acea versiune de PHP (în acest caz, PHP 7.4 și PHP 8.0).

În ceea ce privește versiunea în WordPress, acest software în sine poate introduce ocazional modificări de ultimă oră, cum ar fi actualizarea la o versiune mai nouă de jQuery în WordPress 5.6. În plus, fiecare lansare majoră a WordPress introduce noi funcții (cum ar fi noul editor Gutenberg, introdus în versiunea 5.0), care ar putea fi necesare pentru produsele noastre.

Editorul de blocuri nu face excepție. Dacă temele și pluginurile noastre conțin blocuri personalizate, testarea lor pentru toate versiunile diferite este imperativă. Cel puțin, trebuie să ne îngrijorăm cu privire la două versiuni de Gutenberg: cea livrată în nucleul WordPress și cea disponibilă ca plugin independent.

În ceea ce privește atât HTTPS, cât și multisite, temele și pluginurile noastre se pot comporta diferit, în funcție de activarea sau nu. De exemplu, este posibil să dorim să dezactivăm accesul la un punct final REST atunci când nu folosim HTTPS sau să oferim capabilități extinse super-administratorului de pe site-ul multiplu.

Aceasta înseamnă că există multe medii posibile pentru care trebuie să ne îngrijorăm. Cum ne descurcăm?

Descoperirea Mediilor

Tot ceea ce poate fi automatizat, trebuie să fie automatizat. De exemplu, pentru a testa logica temelor și pluginurilor noastre, putem crea un proces de integrare continuă care rulează un set de teste pe mai multe medii. Automatizarea elimină o mare parte din durere.

Cu toate acestea, nu ne putem baza doar pe mașinile care fac toată munca pentru noi. Va trebui, de asemenea, să accesăm un site WordPress de testare pentru a vedea dacă, după o actualizare a software-ului, temele noastre arată în continuare așa cum s-a dorit. De exemplu, dacă Gutenberg își actualizează sistemul global de stiluri sau modul în care se comportă un bloc de bază, dorim să verificăm dacă produsele noastre nu au fost afectate de schimbare.

Câte medii diferite trebuie să sprijinim? Să presupunem că vizam 4 versiuni de PHP (7.2 la 8.0), 5 versiuni de WordPress (5.3 la 5.7), 2 versiuni de Gutenberg (core/plugin), HTTPS activat/dezactivat și multisite activat/dezactivat. Totul se ridică la un total de 160 de medii posibile. E mult prea mult de gestionat.

Pentru a simplifica lucrurile, în loc să producem un site pentru fiecare combinație posibilă, îl putem reduce la o mână de medii care, în general, cuprind toate proprietățile diferite.

De exemplu, putem produce aceste cinci medii:

1. PHP 7.2 + WP 5.3 + Gutenberg core + HTTPS + multisite
2. PHP 7.3 + WP 5.4 + plugin Gutenberg + HTTPS + multisite
3. PHP 7.4 + WP 5.5 + plugin Gutenberg + fără HTTPS + fără multisite
4. PHP 8.0 + WP 5.6 + Gutenberg core + HTTPS + fără multisite
5. PHP 8.0 + WP 5.7 + Gutenberg core + fără HTTPS + fără multisite

Învârtirea a 5 site-uri WordPress este ușor de gestionat, dar nu este ușor, deoarece implică provocări tehnice, în special activarea diferitelor versiuni de PHP și furnizarea de certificate HTTPS.

Dorim să creăm site-uri WordPress cu ușurință, chiar dacă avem cunoștințe limitate despre sisteme. Și vrem să o facem rapid, deoarece avem de făcut munca noastră de dezvoltare și proiectare. Cum putem face acest lucru?

Gestionarea site-urilor WordPress locale cu DevKinsta

Din fericire, crearea site-urilor WordPress locale nu este dificilă în zilele noastre, deoarece putem evita munca manuală și, în schimb, ne putem baza pe un instrument care automatizează procesul pentru noi.

DevKinsta este exact acest tip de instrument. Permite lansarea unui site WordPress local cu un efort minim, pentru orice configurație dorită. Site-ul va fi creat în mai puțin timp necesar pentru a bea o ceașcă de cafea. Și cu siguranță costă mai puțin decât o ceașcă de cafea: DevKinsta este 100% gratuit și disponibil pentru utilizatorii de Windows, macOS și Ubuntu .

După cum sugerează și numele, DevKinsta a fost creat de Kinsta, unul dintre cei mai importanți furnizori de găzduire din spațiul WordPress. Scopul lor este de a simplifica procesul de lucru cu proiecte WordPress, fie pentru designeri sau dezvoltatori, freelanceri sau agenții. Cu cât ne putem configura mai ușor mediul, cu atât ne putem concentra mai mult pe propriile teme și pluginuri, cu atât produsele noastre vor fi mai bune.

Magia care alimentează DevKinsta este Docker, software-ul care permite izolarea unei aplicații de mediul său prin intermediul containerelor. Cu toate acestea, nu trebuie să știm despre Docker sau containere: DevKinsta ascunde complexitatea de bază, așa că putem lansa site-ul WordPress doar prin apăsarea unui buton.

În acest articol, vom explora cum să folosim DevKinsta pentru a lansa cele 5 instanțe WordPress locale diferite pentru a testa un plugin și ce caracteristici frumoase avem la dispoziție.

Lansarea unui site WordPress cu DevKinsta

Imaginile de mai sus arată DevKinsta când îl deschideți pentru prima dată. Prezintă 3 opțiuni pentru crearea unui nou site WordPress local:

1. Site WordPress nou
   Utilizează configurația implicită, inclusiv cea mai recentă versiune WordPress și PHP 8.
2. Import de la Kinsta
   Clonează configurația de pe un site existent găzduit la MyKinsta.
3. Site personalizat
   Utilizează o configurație personalizată, oferită de dvs.

Dacă apăsați pe opțiunea #1, veți produce literalmente un site WordPress local fără măcar să vă gândiți la asta. Aș putea explica puțin mai departe dacă aș putea; chiar nu este mai mult decât atât.

Dacă se întâmplă să fiți utilizator Kinsta, atunci apăsând pe opțiunea #2 vă permite să importați direct un site din MyKinsta, inclusiv un dump al bazei de date. (Btw, funcționează și în direcția opusă: modificările locale în DevKinsta pot fi împinse către un site de realizare în MyKinsta.)

În cele din urmă, când apăsăm pe opțiunea #3, putem specifica ce configurație personalizată să folosim pentru site-ul WordPress local.

Să apăsăm butonul pentru opțiunea #3. Ecranul de configurare va arăta astfel:

Câteva intrări sunt doar pentru citire. Acestea sunt opțiuni care sunt fixate în prezent, dar vor fi configurate cândva în viitor. De exemplu, serverul web este setat în prezent la Nginx, dar se lucrează la adăugarea Apache.

Opțiunile pe care le putem configura în prezent sunt următoarele:

• Numele site-ului (din care se calculează adresa URL locală),
• versiunea PHP,
• Numele bazei de date,
• HTTPS activat/dezactivat,
• Titlul site-ului WordPress,
• Versiunea WordPress,
• E-mailul administratorului, numele de utilizator și parola,
• Multisite activat/dezactivat.

După ce am completat aceste informații pentru primul meu site WordPress local, numit „GraphQL API on PHP 80”, și am făcut clic pe „Create site”, tot ceea ce i-a luat DevKinsta pentru a crea site-ul a fost doar 2 minute. Apoi, mi se prezintă ecranul de informații pentru site-ul nou creat:

Noul site WordPress este disponibil sub propriul domeniu local graphql-api-on-php80.local . Făcând clic pe butonul „Deschide site-ul”, putem vizualiza noul nostru site în browser:

Am repetat acest proces pentru toate mediile necesare diferite și voila, cele 5 site-uri WordPress locale au fost puse în funcțiune în cel mai scurt timp. Acum, lista inițială a ecranului DevKinsta în jos toate site-urile mele:

Folosind WP-CLI

Din configurația necesară pentru mediile mele, până acum am satisfăcut toate elementele, cu excepția unuia: instalarea Gutenberg ca plugin.

Să facem asta în continuare. Putem instala un plugin obișnuit prin intermediul adminului WP, pe care îl putem accesa făcând clic pe butonul „Administrator WP” din ecranul de informații ale site-ului, așa cum se vede în imaginea de mai sus.

Și mai bine, DevKinsta este livrat cu WP-CLI deja instalat, astfel încât să putem interacționa cu site-ul WordPress prin interfața de linie de comandă.

În acest caz, trebuie să avem cunoștințe minime despre Docker. Executarea unei comenzi într-un container se face astfel:

 docker exec {containerName} /bin/bash -c '{command}'

Parametrii necesari sunt:

• Containerul lui DevKinsta se numește devkinsta_fpm .
• Comanda WP-CLI pentru a instala și activa un plugin este wp plugin install {pluginName} --activate --path={pathToSite} --allow-root
• Calea către site-ul WordPress, în cadrul containerului, este /www/kinsta/public/{siteName} .

Punând totul împreună, comanda de instalare și activare a pluginului Gutenberg pe site-ul WordPress local este aceasta:

 docker exec devkinsta_fpm /bin/bash -c 'wp plugin install gutenberg --activate --path=/www/kinsta/public/MyLocalSite --allow-root'

Explorarea caracteristicilor

Există câteva funcții utile disponibile pentru site-urile noastre WordPress locale.

Prima este integrarea cu Adminer, un instrument similar cu phpMyAdmin, pentru a gestiona baza de date. Cu acest instrument, putem prelua și edita direct datele printr-o interogare SQL personalizată. Făcând clic pe butonul „Manager baze de date”, pe ecranul cu informații despre site, se va deschide Adminer într-o nouă filă de browser:

A doua caracteristică demnă de remarcat este integrarea cu Mailhog, instrumentul popular de testare a e-mailului. Datorită acestui instrument, orice e-mail trimis de pe site-ul WordPress local nu este de fapt trimis, ci este capturat și afișat în căsuța de e-mail:

Făcând clic pe un e-mail, putem vedea conținutul acestuia:

Accesarea fișierelor de instalare locale

După instalarea site-ului WordPress local, folderul acestuia care conține toate fișierele sale (inclusiv nucleul WordPress, temele și pluginurile instalate și elementele media încărcate) va fi disponibil public:

• Mac și Linux: sub /Users/{username}/DevKinsta/public/{siteName} .
• Windows: sub C:\Users\{username}\DevKinsta\public\{siteName} .

(Cu alte cuvinte: fișierele site-ului WordPress local pot fi accesate nu numai prin containerul Docker, ci și prin sistemul de fișiere din sistemul nostru de operare, cum ar fi utilizarea PC-ul meu pe Windows, Finder în Mac sau orice terminal.)

Acest lucru este foarte convenabil, deoarece oferă o comandă rapidă pentru instalarea temelor și pluginurilor pe care le dezvoltăm, accelerându-ne munca.

De exemplu, pentru a testa o modificare a unui plugin în toate cele 5 site-uri locale, în mod normal ar trebui să mergem la administratorul WP de pe fiecare site și să încărcăm noua versiune a pluginului (sau, alternativ, să folosim WP-CLI).

Având acces la folderul site-ului, totuși, putem clona pur și simplu pluginul din depozitul său, direct sub wp-content/plugins :

 $ cd ~/DevKinsta/public/MyLocalSite/wp-content/plugins $ git clone [email protected]:leoloso/MyAwesomePlugin.git

În acest fel, putem doar să git pull pentru a actualiza pluginul nostru la cea mai recentă versiune, făcându-l imediat disponibil pe site-ul WordPress local:

 $ cd MyAwesomePlugin $ git pull

Dacă vrem să testăm pluginul în curs de dezvoltare pe o altă ramură, putem face, în mod similar, un git checkout :

 git checkout some-branch-with-new-feature

Deoarece este posibil să avem mai multe site-uri cu medii diferite, putem automatiza această procedură prin executarea unui script bash, care repetă site-urile WordPress locale și, pentru fiecare, execută un git pull pentru pluginul instalat în:

 #!/bin/bash iterateSitesAndGitPullPlugin(){ cd ~/DevKinsta/public/ for file in * do if [ -d "$file" ]; then cd ~/DevKinsta/public/$file/wp-content/plugins/MyAwesomePlugin git pull fi done } iterateSitesAndGitPullPlugin

Concluzie

Când proiectăm și dezvoltăm temele și pluginurile noastre WordPress, dorim să ne putem concentra pe munca noastră reală, cât mai mult posibil. Dacă putem automatiza configurarea mediului de lucru, atunci putem investi timpul și energia suplimentară în produsul nostru.

Aceasta este ceea ce face posibilă DevKinsta. Putem deschide un site WordPress local prin simpla apăsare a unui buton și putem crea multe site-uri cu medii diferite în doar câteva minute.

DevKinsta este dezvoltat și susținut activ. Dacă întâmpinați vreo problemă sau aveți întrebări, puteți să răsfoiți documentația sau să mergeți la forumul comunității, unde creatorii DevKinsta vă vor ajuta.

Toate acestea, gratuit. Sună bine? Dacă da, descărcați DevKinsta și deschideți site-urile WordPress locale.