încerc să introduc git-ul în workflow-ul zilnic și sunt curios dacă mai sunt și alții pe aici care se ocupă în paralel de câteva zeci de site-uri construite pe wordpress și folosesc git.
Un pic de context: lucrez mai mult pe mentenanță și am câteva sute de site-uri în administrare (majoritatea construite cu wordpress), dar câteva zeci active mai des. Am evitat să folosesc git pentru aceste taskuri pentru că mi s-a părut un timp în plus irosit cu crearea unui repository pentru fiecare site în parte. Însă, pentru a exersa lucrul cu git am realizat că trebuie să-l introduc în munca de zi cu zi, altfel uit comenzile.
aveți câteva tips&tricks legate de cum aș putea optimiza workflow-ul.
Eu m-am gândit în felul următor:
folosesc gitlab pentru a crea un proiect pentru fiecare site în parte.
dacă pentru un anumit site, am dezvoltat și unul sau mai multe pluginuri custom, creez proiecte separate pentru acestea.
și apoi fluxul clasic, pentru fiecare modificare, fac push / commit în repository, și apoi trimit în producție prin ssh/ftp (la unele site-uri nu am decât acces ftp).
Regula de bază: nu pui în repo cod ce nu este al tău (e.g. core-ul WP, plugin-uri publice etc).
În funcție de cât de diferite sunt site-urile tale, poți avea un repo/site sau mai multe site-uri într-un singur repo. E.g. dacă ai 10 site-uri care folosesc fix aceleași plugin-uri și aceeași temă nu are rost să le spargi în mai multe repo-uri.
Plecăm de la câteva premise:
proiectul se numește devforum;
tot codul custom pentru acest proiect va sta în foldere prefixate devforum-
Acestea fiind spuse, structurez repo-ul după cum urmează:
root: wp-content/ (i.e. aici ai rulat git init, deci aici ai folderul .git)
pun TOT în.gitignore : /* după care exclud așa:
!/themes/devforum-*
!/plugins/devforum-*
!/mu-plugins/devforum*
PS: pentru că .gitignore nu știe să facă glob recursiv vei avea nevoie de niște gimnastică extra, de genul:
!/themes/
/themes/*
!/themes/devforum-*
Despre plugin-uri custom:
Fiecare plugin custom se duce într-un repo separat. Ulterior, în funcție de cum instalezi/actualizezi plugin-urile:
folosești un plugin care intermediază actualizările de pe repo-uri private (de exemplu ăsta)
Despre deployment
Depinde foarte mult de ecosistemul în care ești, ce fel de acces ai etc, dar ideal este să automatizezi cât mai mult.
Dacă ai doar FTP, există unelte de genul phploy. Transferul fișierelor prin FTP este cel mai lent și te poți aștepta ca un deploy să dureze ORE.
Dacă ai SSH și vrei doar să pui fișierele pe server, Rsync sau SCP;
Dacă ai nevoie de pași intermediari (e.g. compilare pentru CSS/JS) un pipeline CI/CD care face pașii intermediari apoi execută pasul 1 sau 2 de mai sus.
În mod ideal, nu înlocuiești fișierele existente ci le adaugi într-un folder nou, după care faci un symlink. În felul ăsta câștigi două treburi:
Nu îți pică site-ul când faci deploy
poți face revert la versiunea anterioară dacă ceva merge prost.
in repository tin doar ceea ce este custom (dezvoltat de mine)
daca se intampla ca un plugin custom sa devina necesar in mai multe proiecte, abia atunci il mut intr-un repository separat si il instalez via composer in proiectele respective.
Pentru deploy folosesc:
Deployer - il foloseam deja pentru Laravel, asa ca l-am adoptat si pentru proiectele WordPress (are o multitudine de recipes + iti poti face si propriile recipes); nu suporta deploy via FTP
Github Actions / Gitlab CI/CD - in cazul in care vreau sa rulez Deployer din pipeline: CI/CD | Deployer
Dacă unele plugin-uri sunt folosite doar la unele site-uri, ai două opțiuni:
ori pui toate plugin-urile pe toate site-urile și activezi doar ce-ți trebuie
ori pui fiecare plugin într-un repo și instalezi doar ce-ți trebuie
Fiecare opțiune poate funcționa OK sau poate nu, depinde de nevoile tale.
dacă tu ești admin pentru toate instanțele și ești singurul care poate activa plugin-uri, atunci e OK prima variantă. Altfel, este o chestiune de timp ca cineva să activeze plugin-ul care nu trebuie;
dacă sunt clienți diferiți și au nevoie de plugin-uri custom pentru fiecare, cel mai probabil nu vrei plugin-urile unui client la un alt client;
dacă ai un site (sau mai multe site-uri identice și pentru același client), atunci a pune fiecare plugin în repo separat este overkill.
În trecut (ani de zile) am avut ceva probleme cu structura bedrock și l-am tot evita. L-am încercat iar la ultimul proiect și până acum e totul OK
Eu mă gândeam la următorul lucru: pentru fiecare site să fac câte un repo în care să includ doar tema. Astfel încât să pot urmări modificările făcute. (Am un sistem separat care face backup automat la tot site-ul, inclusiv baza de date.)
Iar pentru pluginurile custom să creez, la fel, câte un repo. Chiar dacă folosesc un plugin la un singur site sau la mai multe.
Am impresia că faci aceeași greșeală pe care am făcut-o și eu când am început cu Git. Și anume: Git nu este backup. Este versionare. Poate că se intersectează unele proprietăți, dar sunt lucruri diferite. (menționez asta pentru că e posibil să ai anumite așteptări )
Ce nu am atins în răspunsul inițial: baza de date nu stă în repo. Adițional, din experiența mea, nu ai nevoie de o sincronizare foarte desă a bazei de date între medii (decât dacă vrei să reproduci vreun bug ciudat). La mine, de obicei trec luni de zile între sincronizări (also, pe blogul ăsta supermișto e un articol despre cum să faci cu assets).
Dincolo de asta: abordarea ta e OK. Încearcă, vezi dacă e ceva ce nu se potrivește nevoilor tale, adaptează (eventual întreabă, dacă te împiedici pe undeva).
Ca idee: cred că este util să adaptezi workflow-ul la nevoile tale (nu invers).
momentan, încerc doar să mă familiarizez cu git-ul și să-l introduc în workflow-ul zilnic. Ulterior, după ce-l voi folosi zi de zi, în proiecte reale, cred că îmi voi da seama mai bine de unele lucruri.
încă îmi e un pic neclar cum l-aș putea folosi în proiectele unde am acces doar la ftp, dar voi încerca phploy să văd cum funcționează.
Mie problema principala in a introduce git-ul in flow-ul de development wordpress este ca nu poti controla modificarile facute in baza de data. In marea parte site-urile wordpress au o gramada de elemente de design, configuratie etc definite in baza de date. Stiu ca au existata la un moment dat niste tentative de module care sa versioneze modificarile din baza de date wordpress dar nu prea functionau cu module doar wordpress curat.
Ai fix aceeași problemă în orice sistem ce include o bază de date, nu este specific WP
O probleme mult mai mari la WP mi se pare că este faptul că ține o grămadă de date serializate în DB, iar treaba asta face imposibilă rularea unui search-replace în sql dump; este nevoie să rulezi wp search-replace ... în CLI, proces ce poate dura câteva ore bune la DB mari.
Dar, așa cum am zis, sincronizarea bazei de date este necesară rareori, deci nu cred că este o problemă foarte mare.
O anecdotă cu legătură: am avut un client pentru scurt timp care insista să treacă prin procesul dev → staging → production cu tot. Inclusiv cu conținutul.
Am încercat să-i explic de mai multe ori că procesul ăsta e util atunci când faci schimbări într-o parte și le poți propaga automat în celelalte părți.
Răspunsul era același: „nu, trebuie să ne asigurăm că rezolvăm problema”. I-am explicat de câteva ori că rezolvarea unui bug în layout-ul din staging în Elementor [1] nu face decât să dubleze efortul, pentru că fix aceiași pași vor trebui făcuți și în producție. Și că nu-i garantează nimeni că pașii ăia vor fi respectați întocmai.
Nu a mers și pace, a trebuit să ne despărțim.
nu mai știu dacă era Elementor sau Divi, dar parcă Elementor… ↩︎
Da si nu daca ai un Elementor si clientul face modificari in baza de date in paralel cu ce lucrezi tu pe dev este distractie maxima sa faci un merge. Problema asta nu o ai in sistemele unde informatia este tinuta in fisiere de configurare si nu in db sau unde macar ai o tablela separata pentru partea de elementor de exemplu si nu este o varza in acelasi loc in DB impreuna cu postari, comenzi si alte informatii. Pe de alta parte nici ce isi dorea clientul nu este chiar aberant realitatea este ca daca lucrezi la un woocomerce si vrei sa faci update-uri vizuale dar si de functionalitate lucrurile se complica destul de mult.
Sincer astept cu nerabdare momentul in care wordpress va rezolva problema bazei de date.
Sunt curios cum se procedează în alte CMS-uri. Tu cum ai stoca informații pentru o pagină astfel încât să fie ușor editabile din UI? (ia în considerare și versionarea și performanța)
De Drupal nu m-am atins în ultimi 10+ ani, Joomla 15+. Am interacționat sumar cu Typo3/Contao, care ținea inclusiv markup în DB (deși nu sunt sigur dacă așa e by design sau doar programatorii de dinaintea mea au făcut asta) și cu un CMS obscur al cărui nume nu mi-l aduc aminte (dar era Cold Fusion) dar care ținea și el cam totul în DB.
si eu sunt curios cum rezolva alti devi problema db
intr-o perioada aveam niste proiecte drupal pentru care scriam exclusiv cod - de la definirea unui content type, la tot felul de views si reguli… totul in module cu sectiuni corecte de install / update / etc.
au fost cele mai fara stress treceri pe live ever
dar era nevoie de ceva disciplina (cu asta te obisnuiesti repede) si de timp (aici e de fapt problema… si mai ales sa ai clientul care si-l permite si plateste).
in rest, continutul se importa din fisiere (in general) sau chiar se edita live (nu prea conta pentru ca nu faceam editari de continut pe dev, deci db se sinconiza exclusiv prin download, nu prin upload).
e o procedura cu care sunt confortabil in drupal (in caz de nevoie), dar pe care n-am prea reusit sa o aplic in wp (nici nu am multa experienta cu wp dev).
totusi, as vrea sa se poata mai comod de atat
ps. am trecut (acum multi ani - pe vremea cand versionarea era svn, nu git) si prin experienta siteurilor custom (dupa design / cms propriu) pe care “le operam” direct live in momente critice (din fericire fara incidente majore - ba chiar imi dau seama acum cat de multe puteau merge rau… si totusi s-au aliniat corect).
un script de export/import nu exista pentru asa ceva? ceva asemanator unui seed/migrari (stiu ca nu-i acelasi lucru), dar specializat pe tipul asta de date.
Din cauză că orice plugin poate altera datele în aproximativ orice punct este ceva mai dificil să implementezi asta automat și într-un mod în care te poți baza.
Este realizabil, dar nu cred că se poate face într-un mod universal și reutilizabil ci trebuie adaptat fiecărui site în parte.
)
