{"id":2957,"date":"2026-07-04T15:23:11","date_gmt":"2026-07-04T15:23:11","guid":{"rendered":"https:\/\/www.serverspan.com\/blog\/"},"modified":"2026-07-11T13:24:59","modified_gmt":"2026-07-11T13:24:59","slug":"staging-wordpress-pe-vps-workflow-ul-complet-pentru-agentii","status":"publish","type":"post","link":"https:\/\/www.serverspan.ro\/blog\/staging-wordpress-pe-vps-workflow-ul-complet-pentru-agentii\/","title":{"rendered":"Staging WordPress pe VPS: workflow-ul complet pentru agen\u021bii"},"content":{"rendered":"\n

Un mediu de staging WordPress pe VPS este o copie complet\u0103 a site-ului de produc\u021bie, fi\u0219iere plus baz\u0103 de date, care ruleaz\u0103 la un URL separat, unde testezi actualiz\u0103ri de plugin-uri, modific\u0103ri de tem\u0103 \u0219i cod custom \u00eenainte ca acestea s\u0103 ating\u0103 site-ul live. Pe un VPS po\u021bi construi staging \u00een trei moduri: un cont de subdomeniu pe acela\u0219i server, o clon\u0103 gestionat\u0103 din panou prin DirectAdmin \u0219i Softaculous sau o instan\u021b\u0103 VPS separat\u0103 care oglinde\u0219te produc\u021bia. Acest ghid le acoper\u0103 pe toate trei, comenzile exacte pentru workflow-ul manual cu rsync \u0219i baz\u0103 de date, plus regulile de sincronizare care \u00eempiedic\u0103 staging-ul s\u0103 suprascrie datele live ale clien\u021bilor.<\/p>\n\n\n\n

De ce protejeaz\u0103 un mediu de staging o agen\u021bie<\/h2>\n\n\n\n

Staging-ul exist\u0103 ca s\u0103 absoarb\u0103 e\u0219ecurile care altfel s-ar \u00eent\u00e2mpla pe site-ul live al unui client pl\u0103titor. Cele mai frecvente: o actualizare de plugin care modific\u0103 schema bazei de date \u0219i las\u0103 frontend-ul cu ecran alb, o actualizare WooCommerce care intr\u0103 \u00een conflict cu o personalizare a checkout-ului, o trecere la o versiune nou\u0103 de PHP care scoate la iveal\u0103 cod depreciat \u00eentr-o tem\u0103 veche \u0219i o actualizare de page builder care rea\u0219az\u0103 silen\u021bios fiecare landing page.<\/p>\n\n\n\n

Pentru o agen\u021bie, calculul este simplu. Reproducerea unei actualiz\u0103ri defecte pe o copie cost\u0103 minute. Depanarea ei \u00een produc\u021bie cost\u0103 \u00eentreruperea \u00een sine, telefonul de la client \u0219i, de multe ori, o restaurare din backup care pierde comenzile sau formularele primite dup\u0103 ultimul snapshot. Dac\u0103 administrezi mai mult de c\u00e2teva site-uri client pe un singur server, workflow-ul din G\u0103zduirea a 20 de site-uri client pe un singur VPS<\/a> se \u00eembin\u0103 direct cu acesta.<\/p>\n\n\n\n

Trei arhitecturi de staging pe un VPS<\/h2>\n\n\n\n

Arhitectura corect\u0103 de staging depinde de c\u00e2t\u0103 izolare ai nevoie fa\u021b\u0103 de produc\u021bie, iar izolarea este exact ceea ce sacrific\u0103 variantele ieftine. O clon\u0103 \u00een subdirector \u00eemparte totul cu site-ul live. Un subdomeniu \u00eentr-un cont separat de panou \u00eemparte serverul, dar nu \u0219i site-ul. Un al doilea VPS nu \u00eemparte nimic.<\/p>\n\n\n\n

Arhitectur\u0103<\/th>Izolare<\/th>Realism<\/th>Riscul principal<\/th>Potrivit\u0103 pentru<\/th><\/tr><\/thead>
Subdirector pe acela\u0219i cont (example.com\/staging)<\/td>Zero: acela\u0219i pool PHP, acela\u0219i server de baze de date, acela\u0219i utilizator<\/td>Ridicat, stack identic<\/td>Un proces de staging sc\u0103pat de sub control consum\u0103 resursele produc\u021biei; crawlerele \u00eel g\u0103sesc u\u0219or<\/td>Doar teste rapide, punctuale<\/td><\/tr>
Subdomeniu \u00eentr-un cont separat (staging.example.com)<\/td>Izolare de procese \u0219i fi\u0219iere prin utilizator de sistem separat<\/td>Ridicat, stack identic<\/td>Resurse de server partajate; DNS \u0219i SSL trebuie configurate per site<\/td>Workflow-ul standard de agen\u021bie pe un singur VPS<\/td><\/tr>
Instan\u021b\u0103 VPS separat\u0103<\/td>Complet\u0103: kernel propriu, resurse proprii, IP propriu<\/td>Maxim, po\u021bi repeta \u0219i upgrade-uri de server<\/td>Costul unui al doilea server; mediile diverg dac\u0103 nu sunt \u00eentre\u021binute<\/td>Magazine cu venituri mari, clien\u021bi reglementa\u021bi, teste de \u00eenc\u0103rcare<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Varianta cu subdirector merit\u0103 un avertisment aparte. Pe o configura\u021bie implicit\u0103, staging-ul \u0219i produc\u021bia \u00eempart acela\u0219i pool PHP-FPM, deci un import greu pe staging sau un plugin blocat \u00eentr-o bucl\u0103 consum\u0103 exact workerii care servesc traficul live. Un test pe example.com\/staging poate dobor\u00ee example.com. Dac\u0103 o folose\u0219ti totu\u0219i, folose\u0219te-o pentru verific\u0103ri read-only, niciodat\u0103 pentru teste de \u00eenc\u0103rcare sau importuri mari.<\/p>\n\n\n\n

Regula de decizie: subdomeniul \u00eentr-un cont separat este varianta implicit\u0103 pentru agen\u021bii. Treci la un VPS separat c\u00e2nd site-ul clientului aduce suficient \u00eenc\u00e2t o or\u0103 de downtime cost\u0103 mai mult dec\u00e2t o lun\u0103 din al doilea server, sau c\u00e2nd trebuie s\u0103 repe\u021bi upgrade-uri de PHP \u0219i de baz\u0103 de date, lucru pe care staging-ul pe subdomeniu nu \u00eel poate face pentru c\u0103 \u00eemparte stack-ul de produc\u021bie.<\/p>\n\n\n\n

Staging manual cu rsync \u0219i un dump de baz\u0103 de date<\/h2>\n\n\n\n

Metoda manual\u0103 este o secven\u021b\u0103 \u00een patru p\u0103r\u021bi: copiezi fi\u0219ierele, faci dump \u0219i import la baza de date, rescrii URL-urile \u0219i izolezi copia. Func\u021bioneaz\u0103 pe orice VPS Linux cu acces SSH \u0219i \u00ee\u021bi d\u0103 un script repetabil \u00een locul unei dependen\u021be de plugin.<\/p>\n\n\n\n

\u00cenainte de orice, confirm\u0103 c\u0103 serverul poate \u021bine o a doua copie a site-ului. O clon\u0103 complet\u0103 dubleaz\u0103 spa\u021biul ocupat de acel site, iar r\u0103m\u00e2nerea f\u0103r\u0103 disc \u00een mijlocul copierii corupe clona:<\/p>\n\n\n\n

df -h \/home\ndf -ih \/home<\/code><\/pre>\n\n\n\n
Prima comand\u0103 verific\u0103 spa\u021biul liber, a doua verific\u0103 inode-urile libere. Site-urile WordPress cu cache-uri mari pot epuiza inode-urile \u00een timp ce spa\u021biul pe disc pare \u00een regul\u0103. Dac\u0103 oricare dep\u0103\u0219e\u0219te aproximativ 80 la sut\u0103 grad de utilizare, f\u0103 cur\u0103\u021benie \u00eenainte de clonare.<\/p>\n\n\n\n
Copiaz\u0103 fi\u0219ierele<\/h3>\n\n\n\n
Pe un server DirectAdmin, fiecare cont tr\u0103ie\u0219te \u00een \/home\/utilizator\/domains\/domeniu.tld\/public_html. Previzualizeaz\u0103 \u00eent\u00e2i copierea cu un dry run:<\/p>\n\n\n\n
rsync -a --dry-run --itemize-changes \\\n  --exclude 'wp-content\/cache\/' \\\n  \/home\/produser\/domains\/example.com\/public_html\/ \\\n  \/home\/staginguser\/domains\/staging.example.com\/public_html\/<\/code><\/pre>\n\n\n\n
Rezultatul corect este o list\u0103 de fi\u0219iere care ar fi transferate \u0219i nimic altceva. Erorile de permisiuni \u00eenseamn\u0103 c\u0103 nu rulezi cu drepturi suficiente pentru a citi sursa sau a scrie destina\u021bia. C\u00e2nd dry run-ul arat\u0103 corect, elimin\u0103 –dry-run \u0219i ruleaz\u0103 din nou. Excluderea directorului de cache p\u0103streaz\u0103 copia mai mic\u0103 \u0219i evit\u0103 transportarea unor intr\u0103ri de cache care refer\u0103 URL-urile de produc\u021bie. Dup\u0103 copiere, corecteaz\u0103 ownership-ul astfel \u00eenc\u00e2t contul de staging s\u0103 \u00ee\u0219i de\u021bin\u0103 fi\u0219ierele:<\/p>\n\n\n\n
chown -R staginguser:staginguser \/home\/staginguser\/domains\/staging.example.com\/public_html<\/code><\/pre>\n\n\n\n
Cloneaz\u0103 baza de date<\/h3>\n\n\n\n
F\u0103 dump la produc\u021bie cu un snapshot consistent, apoi import\u0103 \u00eentr-o baz\u0103 de date de staging separat\u0103, creat\u0103 prin DirectAdmin sau prin clientul mysql:<\/p>\n\n\n\n
mysqldump --single-transaction --quick prod_db > \/home\/produser\/prod_db.sql\nmysql staging_db < \/home\/produser\/prod_db.sql<\/code><\/pre>\n\n\n\n
Op\u021biunea –single-transaction \u00ee\u021bi d\u0103 un dump consistent al tabelelor InnoDB f\u0103r\u0103 s\u0103 blocheze site-ul live. Un dump care se termin\u0103 brusc, f\u0103r\u0103 linia final\u0103 de comentariu “Dump completed”, este trunchiat, de obicei din cauza discului plin sau a unei conexiuni \u00eentrerupte; nu \u00eel importa. Apoi \u00eendreapt\u0103 wp-config.php al site-ului de staging c\u0103tre baza de date \u0219i creden\u021bialele de staging. Nu l\u0103sa niciodat\u0103 wp-config.php de pe staging s\u0103 refere baza de date de produc\u021bie. Aceast\u0103 singur\u0103 gre\u0219eal\u0103 transform\u0103 fiecare test de staging \u00eentr-o modificare de produc\u021bie.<\/p>\n\n\n\n
Rescrie URL-urile f\u0103r\u0103 s\u0103 corupi datele serializate<\/h3>\n\n\n\n
WordPress stocheaz\u0103 URL-ul site-ului \u00een baza de date, inclusiv \u00een array-uri PHP serializate, unde lungimea \u0219irului este \u00eenregistrat\u0103 l\u00e2ng\u0103 \u0219ir. Un UPDATE brut \u00een SQL cu REPLACE() schimb\u0103 \u0219irul, dar nu \u0219i lungimea \u00eenregistrat\u0103, ceea ce corupe widget-urile, op\u021biunile temei \u0219i layout-urile de page builder. Folose\u0219te WP-CLI, care rescrie corect datele serializate:<\/p>\n\n\n\n
cd \/home\/staginguser\/domains\/staging.example.com\/public_html\nwp search-replace 'https:\/\/example.com' 'https:\/\/staging.example.com' --all-tables --dry-run\nwp search-replace 'https:\/\/example.com' 'https:\/\/staging.example.com' --all-tables<\/code><\/pre>\n\n\n\n
Dry run-ul raporteaz\u0103 c\u00e2te \u00eenlocuiri s-ar face per tabel. Un rezultat s\u0103n\u0103tos arat\u0103 majoritatea \u00eenlocuirilor \u00een wp_options, wp_posts \u0219i wp_postmeta. Zero \u00eenlocuiri peste tot \u00eenseamn\u0103 c\u0103 ai gre\u0219it URL-ul surs\u0103 (verific\u0103 http versus https \u0219i prefixul www cu wp option get siteurl). Verific\u0103 rezultatul:<\/p>\n\n\n\n
wp option get siteurl\nwp option get home<\/code><\/pre>\n\n\n\n
Ambele trebuie s\u0103 returneze URL-ul de staging \u00eenainte s\u0103 deschizi site-ul \u00een browser.<\/p>\n\n\n\n
Staging prin DirectAdmin \u0219i Softaculous<\/h2>\n\n\n\n
Pe serverele DirectAdmin, staging-ul gestionat din panou ruleaz\u0103 prin Softaculous, auto-installerul inclus \u00een planurile de web hosting cu DirectAdmin<\/a> de la ServerSpan. WP Toolkit, unealta descris\u0103 \u00een majoritatea tutorialelor de staging, este un produs pentru cPanel \u0219i Plesk \u0219i nu face parte dintr-o configura\u021bie DirectAdmin standard, motiv pentru care agen\u021biile care caut\u0103 ghiduri de staging pentru DirectAdmin nu g\u0103sesc mai nimic.<\/p>\n\n\n\n
Softaculous execut\u0103 din panou aceea\u0219i secven\u021b\u0103 descris\u0103 mai sus: cloneaz\u0103 fi\u0219ierele \u0219i baza de date c\u0103tre o loca\u021bie de staging aleas\u0103 de tine, rescrie URL-urile \u0219i poate \u00eempinge ulterior copia de staging \u00eenapoi pe live. Workflow-ul oficial este documentat \u00een documenta\u021bia de staging Softaculous<\/a>. Dou\u0103 precau\u021bii opera\u021bionale se aplic\u0103 indiferent de versiunea panoului. Prima: pasul de push-to-live suprascrie baza de date de produc\u021bie cu cea de staging, deci tot ce urmeaz\u0103 \u00een sec\u021biunea despre derivarea con\u021binutului se aplic\u0103 din plin. A doua: Softaculous gestioneaz\u0103 doar instal\u0103rile pe care le cunoa\u0219te; un site instalat manual trebuie importat \u00een Softaculous \u00eenainte ca butoanele de staging s\u0103 apar\u0103 pentru el.<\/p>\n\n\n\n
Staging-ul din panou este alegerea implicit\u0103 corect\u0103 pentru agen\u021biile care vor workflow-ul f\u0103r\u0103 s\u0103 \u00eentre\u021bin\u0103 scripturi. Metoda manual\u0103 r\u0103m\u00e2ne de \u0219tiut pentru c\u0103 func\u021bioneaz\u0103 acolo unde panoul nu poate: site-uri supradimensionate care expir\u0103 \u00een installer, re\u021bele multisite \u0219i servere f\u0103r\u0103 niciun panou.<\/p>\n\n\n\n
Staging cu plugin-uri \u0219i unde cedeaz\u0103 pe servere mici<\/h2>\n\n\n\n
Plugin-urile de staging precum WP Staging, BlogVault \u0219i Migrate Guru creeaz\u0103 sau g\u0103zduiesc o copie a site-ului din interiorul WordPress, iar sl\u0103biciunea lor principal\u0103 este c\u0103 ruleaz\u0103 ca PHP, sub acelea\u0219i limite ca site-ul pe care \u00eel copiaz\u0103. Pe un VPS mic sau pe un plan shared, clonarea unui site de 20 GB prin PHP love\u0219te max_execution_time, memory_limit \u0219i timeout-urile de cereri PHP-FPM. Simptomele: clone blocate la un anumit procent sau o copie care se termin\u0103, dar c\u0103reia \u00eei lipsesc fi\u0219iere din uploads.<\/p>\n\n\n\n
Unde se potrive\u0219te fiecare: WP Staging cloneaz\u0103 \u00eentr-un subdirector pe acela\u0219i server, ceea ce mo\u0219tene\u0219te riscul resurselor partajate descris mai devreme. BlogVault face staging pe propria infrastructur\u0103 cloud, ceea ce scoate \u00eenc\u0103rcarea de pe serverul t\u0103u, dar plaseaz\u0103 datele clientului la un ter\u021b, aspect de verificat fa\u021b\u0103 de acordul de prelucrare a datelor al clientului. Migrate Guru este construit pentru mutarea site-urilor \u00eentre hosturi, nu pentru \u00eentre\u021binerea unei copii de staging persistente, \u0219i este o op\u021biune gratuit\u0103 solid\u0103 pentru mutarea ini\u021bial\u0103 pe VPS-ul t\u0103u, acoperit\u0103 \u00een detaliu \u00een ghidul de migrare cPanel DirectAdmin<\/a>.<\/p>\n\n\n\n
Regula de decizie: plugin-urile sunt acceptabile pentru site-uri sub c\u00e2\u021biva gigabytes, pe servere la care nu ai acces SSH. Pe propriul VPS, rsync cu WP-CLI sau Softaculous fac aceea\u0219i treab\u0103 mai repede, f\u0103r\u0103 limitele PHP \u0219i f\u0103r\u0103 \u00eenc\u0103 un plugin de actualizat.<\/p>\n\n\n\n
Reguli de sincronizare a bazei de date care protejeaz\u0103 datele clien\u021bilor<\/h2>\n\n\n\n
Baza de date este jum\u0103tatea periculoas\u0103 a oric\u0103rui workflow de staging, pentru c\u0103 se schimb\u0103 \u00een ambele locuri deodat\u0103. \u00cen timp ce echipa ta testeaz\u0103 pe staging, site-ul live continu\u0103 s\u0103 primeasc\u0103 comenzi, comentarii, formulare \u0219i utilizatori noi. Un push complet de baz\u0103 de date de pe staging pe produc\u021bie \u0219terge tot. Aceasta este cea mai scump\u0103 gre\u0219eal\u0103 de staging pe care o poate face o agen\u021bie \u0219i este descoperit\u0103 mereu dup\u0103 fapt.<\/p>\n\n\n\n
Trei reguli o previn. Prima: sincronizeaz\u0103 baza de date complet\u0103 doar \u00eentr-o singur\u0103 direc\u021bie, de la produc\u021bie c\u0103tre staging, \u0219i re\u00eemprosp\u0103teaz\u0103 staging-ul chiar \u00eenainte de un ciclu de testare. A doua: nu \u00eempinge niciodat\u0103 wp_users \u0219i wp_usermeta de pe staging pe produc\u021bie; staging-ul acumuleaz\u0103 conturi de test \u0219i hash-uri de parole \u00eenvechite. A treia: pentru site-urile WooCommerce, nu \u00eempinge \u00een bloc wp_posts \u0219i wp_postmeta dup\u0103 testare, pentru c\u0103 acolo tr\u0103iesc comenzile (sau \u00een wc_orders pe magazinele care folosesc high-performance order storage). Dac\u0103 o modificare implic\u0103 \u0219i cod, \u0219i schem\u0103 de baz\u0103 de date, public\u0103 \u00eent\u00e2i codul \u0219i ruleaz\u0103 pe produc\u021bie rutina de migrare a plugin-ului, \u00een loc s\u0103 copiezi tabele.<\/p>\n\n\n\n
Pentru modific\u0103rile pur de con\u021binut, cum ar fi o pagin\u0103 reconstruit\u0103 pe staging \u0219i aprobat\u0103 de client, mut\u0103 doar acel element, nu baza de date: export\u0103 pagina respectiv\u0103 sau reconstruie\u0219te-o pe produc\u021bie \u00eentr-o fereastr\u0103 de mentenan\u021b\u0103. Push-urile selective de tabele par tentante \u0219i e\u0219ueaz\u0103 des, pentru c\u0103 WordPress \u00eempr\u0103\u0219tie o singur\u0103 modificare logic\u0103 \u00een mai multe tabele.<\/p>\n\n\n\n
DNS, SSL \u0219i cum \u021bii staging-ul \u00een afara rezultatelor de c\u0103utare<\/h2>\n\n\n\n
Un subdomeniu de staging are nevoie de trei lucruri: o \u00eenregistrare DNS, un certificat \u0219i control de acces. Creeaz\u0103 un A record pentru staging.example.com c\u0103tre IP-ul VPS-ului \u0219i confirm\u0103 propagarea \u00eenainte de a cere un certificat:<\/p>\n\n\n\n
dig +short A staging.example.com<\/code><\/pre>\n\n\n\n
Rezultatul corect este IP-ul serverului t\u0103u. Un rezultat gol \u00eenseamn\u0103 c\u0103 \u00eenregistrarea nu s-a propagat, iar o cerere Let’s Encrypt va pica la validare p\u00e2n\u0103 se propag\u0103. Pe un server DirectAdmin, Auto-SSL emite certificatul odat\u0103 ce domeniul rezolv\u0103; browserele trateaz\u0103 un staging cu certificat invalid ca ostil, iar comportamentul mixed-content difer\u0103 de produc\u021bie, a\u0219a c\u0103 testeaz\u0103 pe HTTPS real.<\/p>\n\n\n\n
Controlul de acces conteaz\u0103 mai mult dec\u00e2t presupun majoritatea echipelor. Bifa “descurajeaz\u0103 motoarele de c\u0103utare” din WordPress scrie doar un hint \u00een robots.txt, pe care Google \u00eel poate ignora la indexare dac\u0103 alte site-uri leag\u0103 spre acel URL. Un duplicat al site-ului clientului \u00een index creeaz\u0103 o problem\u0103 de con\u021binut duplicat pentru domeniul de produc\u021bie. Autentificarea HTTP basic rezolv\u0103 crawling-ul, indexarea \u0219i concuren\u021bii curio\u0219i dintr-un singur pas. Creeaz\u0103 un fi\u0219ier de parole \u0219i protejeaz\u0103 directorul de staging prin .htaccess (partea de Apache o gestioneaz\u0103 pe un stack DirectAdmin standard cu NGiNX plus Apache):<\/p>\n\n\n\n
htpasswd -c \/home\/staginguser\/.htpasswd agencyuser<\/code><\/pre>\n\n\n\n
AuthType Basic\nAuthName \"Staging\"\nAuthUserFile \/home\/staginguser\/.htpasswd\nRequire valid-user<\/code><\/pre>\n\n\n\n
\u021aine fi\u0219ierul .htpasswd \u00een afara public_html. Dac\u0103 un client trebuie s\u0103 vad\u0103 staging-ul, d\u0103-i propria linie de creden\u021biale \u00een loc s\u0103 le \u00eempar\u021bi pe ale tale, ca accesul s\u0103 poat\u0103 fi revocat per persoan\u0103 la finalul proiectului.<\/p>\n\n\n\n
Un workflow de deployment cu plan de rollback<\/h2>\n\n\n\n
Workflow-ul care scaleaz\u0103 \u00eentr-o echip\u0103 separ\u0103 codul de con\u021binut: codul circul\u0103 prin Git de la development la staging \u0219i apoi la produc\u021bie, \u00een timp ce baza de date se re\u00eemprosp\u0103teaz\u0103 \u00een direc\u021bia opus\u0103, de la produc\u021bie \u00een jos c\u0103tre staging. Versioneaz\u0103 tema \u0219i plugin-urile custom \u00eentr-un repository; exclude nucleul WordPress, plugin-urile ter\u021be, uploads \u0219i wp-config.php prin .gitignore. Plugin-urile ter\u021be r\u0103m\u00e2n fixate pe versiune \u0219i se actualizeaz\u0103 prin exact procesul de update pe care \u00eel testezi pe staging.<\/p>\n\n\n\n
Un release arat\u0103 atunci a\u0219a: re\u00eemprosp\u0103tezi staging-ul din produc\u021bie, publici branch-ul de cod pe staging cu git pull, rulezi actualizarea sau migrarea \u0219i testezi fluxurile critice (checkout, formulare, login), nu doar homepage-ul. \u00cenainte de a atinge produc\u021bia, ia snapshot-ul de rollback:<\/p>\n\n\n\n
wp db export pre-deploy-$(date +%F).sql --path=\/home\/produser\/domains\/example.com\/public_html<\/code><\/pre>\n\n\n\n
Stocheaz\u0103-l \u00een afara public_html, ca s\u0103 nu fie niciodat\u0103 desc\u0103rcabil. Apoi public\u0103 pe produc\u021bie \u0219i ruleaz\u0103 acelea\u0219i verific\u0103ri. Rollback-ul de cod este un git checkout la tag-ul anterior; rollback-ul bazei de date este un import al dump-ului pre-deploy, minus comenzile sosite \u00eentre timp, motiv pentru care dump-ul se ia cu secunde \u00eenainte de deploy, nu cu o sear\u0103 \u00eenainte. Un plan de rollback pe care nu l-ai repetat niciodat\u0103 pe staging este o ipotez\u0103, nu un plan. F\u0103 un exerci\u021biu de restaurare pe trimestru.<\/p>\n\n\n\n
Unde intr\u0103 hosting-ul administrat \u00een acest workflow<\/h2>\n\n\n\n
Tot ce este mai sus este munc\u0103 orientat\u0103 spre client, pe care o agen\u021bie trebuie s\u0103 o de\u021bin\u0103: ce se testeaz\u0103, c\u00e2nd se lanseaz\u0103, ce aprob\u0103 clientul. Stratul de dedesubt (actualiz\u0103ri de panou, mentenan\u021ba versiunilor PHP, tuning MariaDB, verificarea backup-urilor, re\u00eennoirea certificatelor, reguli de firewall) este administrare de server nediferen\u021biat\u0103, care nu produce nimic facturabil. Dac\u0103 un update DirectAdmin defect sau un certificat de staging expirat \u021bi-a m\u00e2ncat vreodat\u0103 o dup\u0103-amiaz\u0103 de agen\u021bie, stratul acela merit\u0103 delegat.<\/p>\n\n\n\n
Dac\u0103 preferi s\u0103 \u00ee\u021bi \u021bii echipa pe proiectele clien\u021bilor \u0219i s\u0103 predai stratul de server, serviciul de administrare servere DirectAdmin<\/a> de la ServerSpan acoper\u0103 monitorizarea, actualiz\u0103rile de securitate, optimizarea performan\u021bei \u0219i backup-urile pe VPS-ul pe care ruleaz\u0103 workflow-ul t\u0103u de staging. Pentru site-urile client mai mici, care nu justific\u0103 un server propriu, planurile de web hosting cu DirectAdmin includ Softaculous, deci workflow-ul de staging din panou descris \u00een acest ghid func\u021bioneaz\u0103 acolo f\u0103r\u0103 nicio administrare de server. Alegerea \u00eentre cele dou\u0103 porne\u0219te de la \u00eentrebarea acoperit\u0103 \u00een Shared hosting vs VPS: de ce ai nevoie cu adev\u0103rat \u00een 2026<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
Un mediu de staging WordPress pe VPS este o copie complet\u0103 a site-ului de produc\u021bie, fi\u0219iere plus baz\u0103 de date, care ruleaz\u0103 la un URL separat, unde testezi actualiz\u0103ri de plugin-uri, modific\u0103ri de tem\u0103 \u0219i cod custom \u00eenainte ca acestea s\u0103 ating\u0103 site-ul live. Pe un VPS po\u021bi construi staging \u00een trei moduri: un cont […]<\/p>\n","protected":false},"author":1,"featured_media":2954,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[16789,16778,16796,16790,16784,16785,16772,16787,16774,16775,16782,16795,16791,16779,16780,16788,16786,16794,16770,16792,16771,16793,16777,16773,16783,16769,16798,16797,16776,16799,16781],"class_list":["post-2957","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-virtual-servers","tag-administrare-directadmin-pentru-agentii","tag-alternativa-wp-toolkit-directadmin","tag-backup-baza-de-date-inainte-de-update","tag-certificat-ssl-pentru-staging","tag-clonare-site-wordpress-pe-vps","tag-comenzi-woocommerce-pierdute-staging","tag-cum-fac-staging-wordpress","tag-date-serializate-wordpress-inlocuire-url","tag-deployment-wordpress-sigur","tag-mediu-de-staging-wordpress","tag-mysqldump-wordpress","tag-plan-de-rollback-deployment-wordpress","tag-protejare-staging-cu-parola-htaccess","tag-push-to-live-softaculous","tag-rsync-copiere-site-wordpress","tag-server-pentru-agentie-web","tag-sincronizare-baza-de-date-staging-productie","tag-site-de-staging-indexat-de-google","tag-site-de-test-wordpress","tag-staging-a-suprascris-productia","tag-staging-pe-subdomeniu-wordpress","tag-staging-pentru-site-uri-client","tag-staging-softaculous-wordpress","tag-staging-wordpress-directadmin","tag-staging-wordpress-fara-plugin","tag-staging-wordpress-pe-vps","tag-update-wordpress-a-stricat-site-ul-preventie","tag-workflow-git-wordpress","tag-workflow-wordpress-pentru-agentii","tag-workflow-wordpress-pentru-agentii-2","tag-wp-cli-search-replace-2"],"_links":{"self":[{"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2957","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2957"}],"version-history":[{"count":2,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2957\/revisions"}],"predecessor-version":[{"id":3020,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/2957\/revisions\/3020"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=\/wp\/v2\/media\/2954"}],"wp:attachment":[{"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2957"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2957"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.serverspan.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2957"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}