Terminalul din cPanel: cum îl folosiți pentru WP-CLI și administrare

Terminalul din cPanel: cum îl folosiți pentru WP-CLI și administrare, adică pentru tot ce durează minute din panoul WordPress și secunde din linia de comandă: actualizări, căutare și înlocuire în baza de date, curățare, copii de siguranță, verificarea integrității fișierelor. Terminalul rulează în browser, fără client SSH și fără chei, cu drepturile contului dumneavoastră, și este unealta cea mai subfolosită din cPanel.

Ghidul acoperă activarea, comenzile WP-CLI pe care le folosim la fiecare intervenție, operațiunile de administrare care nu țin de WordPress, scripturile și limitele, plus lista scurtă de comenzi pe care nu le rulați niciodată pe un site în producție.

Terminalul din cPanel: cum îl folosiți pentru WP-CLI și administrare

Activarea și primul contact

Secțiunea Advanced, Terminal. La prima deschidere, cPanel cere acceptarea unui avertisment: comenzile greșite pot strica contul. Dacă unealta lipsește, furnizorul o poate activa din Feature Manager în WHM; unele găzduiri o dezactivează implicit. Terminalul este un shell bash obișnuit, în dosarul personal al contului; sesiunea se închide la închiderea filei, iar comenzile lungi trebuie lansate cu nohup sau în screen, altfel se opresc odată cu fila.

pwd                    # /home/contul-dumneavoastra
ls -la                 # ce e în dosarul personal
wp --version           # WP-CLI e instalat?
php -v                 # versiunea PHP din terminal (poate diferi de cea a site-ului)

Dacă wp lipsește, descărcați-l în dosarul personal și folosiți-l de acolo:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar && mkdir -p ~/bin && mv wp-cli.phar ~/bin/wp
echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc && source ~/.bashrc

WP-CLI: comenzile pe care le folosim la fiecare site

Toate comenzile se rulează din dosarul site-ului (cd ~/public_html sau subdosarul lui). WP-CLI citește wp-config.php și lucrează direct cu baza de date, deci merge și când panoul de administrare nu se mai încarcă.

Stare și inventar

wp core version
wp plugin list --fields=name,status,version,update
wp theme list
wp user list --role=administrator
wp option get siteurl && wp option get home

Actualizări, cu copie înainte

wp db export ~/backup/baza-$(date +%F).sql
wp core update && wp core update-db
wp plugin update --all
wp theme update --all
wp core verify-checksums && wp plugin verify-checksums --all

Ultima linie confirmă că fișierele descărcate sunt cele originale; este și verificarea de malware pe care o descriem în ghidul despre detectarea și eliminarea malware-ului. Procedura completă de actualizare, cu testare, este în ghidul despre actualizarea WordPress, a temelor și a modulelor.

Căutare și înlocuire în baza de date

Comanda care justifică singură terminalul: după schimbarea domeniului, trecerea la HTTPS sau clonarea pe un subdomeniu, adresele vechi din baza de date (inclusiv cele din setări serializate, pe care un UPDATE SQL le-ar strica) se înlocuiesc corect:

wp search-replace 'http://vechi.ro' 'https://nou.ro' --dry-run     # arată ce ar schimba
wp search-replace 'http://vechi.ro' 'https://nou.ro' --skip-columns=guid --report-changed-only

Curățare și întreținere

wp transient delete --all
wp cache flush
wp post delete $(wp post list --post_status=trash --format=ids) --force
wp post list --post_type=revision --format=ids | xargs -r wp post delete --force
wp db optimize
wp media regenerate --only-missing

Reviziile și datele temporare ocupă, pe site-urile vechi, mai mult decât conținutul; ce se poate șterge fără risc este descris în ghidul despre optimizarea bazelor de date WordPress.

Când panoul de administrare nu mai merge

wp plugin deactivate --all                   # ecran alb după un modul
wp theme activate twentytwentyfive           # tema stricată
wp user update admin --user_pass='parola-noua-lunga'   # parolă pierdută
wp maintenance-mode activate                 # pe durata intervenției

Cazul ecranului alb, cu diagnosticul pas cu pas, este în articolul despre rezolvarea ecranului alb în WordPress.

Administrare dincolo de WordPress

Fișiere și arhive

du -sh ~/public_html/* | sort -rh | head          # ce ocupă spațiul
find ~/public_html -type f -mtime -2 -name "*.php" # fișiere PHP modificate în ultimele 2 zile
tar -czf ~/backup/site-$(date +%F).tar.gz -C ~/public_html --exclude='wp-content/cache' .
unzip -q tema-noua.zip -d ~/public_html/wp-content/themes/
find ~/public_html -type d -exec chmod 755 {} + && find ~/public_html -type f -exec chmod 644 {} +

Arhivele mari se dezarhivează în secunde din terminal, unde File Manager expiră; permisiunile se corectează în masă după regulile din ghidul despre chmod și chown.

Baze de date

mysql -u cont_utilizator -p cont_baza -e "SHOW TABLE STATUS" | awk '{print $1, $7}' | sort -k2 -rn | head
mysqldump -u cont_utilizator -p cont_baza | gzip > ~/backup/cont_baza-$(date +%F).sql.gz
gunzip -c ~/backup/cont_baza-2026-09-01.sql.gz | mysql -u cont_utilizator -p cont_baza

Exportul și importul din terminal nu au limitele de dimensiune ale phpMyAdmin; comparația este în ghidul despre importul și exportul prin phpMyAdmin.

Jurnale și diagnostic

tail -n 50 ~/public_html/error_log
grep -c " 404 " ~/access-logs/exemplu.ro
curl -sI https://www.exemplu.ro/ | head -n 15
top -u $USER -n 1 | head -n 20

Scripturi și cron

Orice secvență pe care o repetați devine un script în ~/bin, cu permisiuni 700, rulat din Cron Jobs: copia zilnică (export plus arhivă, cu rotație), verificarea săptămânală a sumelor de control, curățarea lunară a reviziilor. Un exemplu de script de copie și programarea lui sunt în ghidul despre programarea sarcinilor cron în cPanel. Scripturile primesc calea completă spre wp (~/bin/wp sau /usr/local/bin/wp), fiindcă în cron PATH-ul este minimal.

Trei intervenții reale, din terminal

Un magazin cu 12.000 de produse, mutat pe HTTPS, afișa conținut mixt pe jumătate din pagini: adresele http ale imaginilor erau în baza de date, în descrieri și în setări serializate. wp search-replace cu --dry-run a arătat 41.000 de înlocuiri în 14 tabele; rularea reală a durat 40 de secunde. Din panou, ar fi însemnat un modul suplimentar și o oră.

Un site de prezentare nu se mai deschidea după actualizarea automată a unui modul de formulare (ecran alb). wp plugin deactivate nume-modul din terminal a readus site-ul în 10 secunde; apoi wp plugin update cu versiunea corectată, a doua zi.

Un blog cu 900 de articole avea baza de date de 1,4 GB, din care 1,1 GB revizii și date temporare expirate. Ștergerea reviziilor mai vechi de 90 de zile și a datelor temporare, plus wp db optimize, au adus-o la 280 MB; copiile de siguranță zilnice au devenit de cinci ori mai mici.

Alias-uri care economisesc timp

Pentru comenzile pe care le repetați, definiți prescurtări în ~/.bashrc: un alias pentru intrarea în dosarul site-ului, unul pentru exportul bazei cu data în nume, unul pentru verificarea sumelor de control. WP-CLI acceptă și un fișier wp-cli.yml în dosarul personal, cu calea implicită a site-ului, ca să nu mai fie nevoie de cd. Pe conturile cu mai multe site-uri, aliasurile WP-CLI (@site1, @site2, definite în același fișier) permit comenzi de tipul wp @site1 plugin update --all, fără să schimbați dosarul.

Limitele terminalului din cPanel

• Rulează cu drepturile contului: nu puteți instala pachete, reporni servicii sau citi fișierele altor conturi.
• Versiunea PHP din terminal poate fi alta decât cea a site-ului; pentru WP-CLI, forțați-o cu calea completă spre binarul potrivit (de exemplu /opt/cpanel/ea-php83/root/usr/bin/php ~/bin/wp) dacă apar erori de compatibilitate.
• Sesiunea se închide cu fila; pentru comenzi lungi, screen sau nohup, dacă sunt permise.
• Limitele de resurse ale contului se aplică și aici; un mysqldump pe o bază de 2 GB poate atinge I/O-ul și încetini site-ul; rulați-l noaptea.
• Fără client SSH, nu aveți rsync spre alt server decât dacă rsync și cheile sunt configurate în cont.

Terminalul și securitatea contului

Accesul la terminal înseamnă acces complet la fișierele contului; activați-l doar pentru utilizatorii care au nevoie și protejați contul cPanel cu al doilea factor, fiindcă oricine intră în panou intră și în terminal. Istoricul comenzilor (~/.bash_history) păstrează tot ce ați tastat, inclusiv parolele scrise în comenzi; folosiți opțiunea -p fără parolă (comanda o cere interactiv) și fișierul ~/.my.cnf cu permisiuni 600 pentru credențialele bazei de date. Restul măsurilor pentru cont sunt în ghidul despre securitatea contului cPanel.

Ce nu faceți din terminal pe un site în producție

1. rm -rf pe o cale scrisă din memorie; listați întâi cu ls, apoi ștergeți.
2. wp search-replace fără --dry-run înainte și fără export înainte.
3. chmod -R 777 „ca să meargă”.
4. wp db reset sau wp site empty, fără să fiți sigur că sunteți în dosarul site-ului corect (cd greșit este cauza clasică).
5. Rularea ca root, dacă aveți acces la server: WP-CLI și scripturile PHP se rulează ca utilizatorul contului, altfel fișierele create aparțin lui root și site-ul dă erori de permisiuni.

Cu aceste reguli, terminalul reduce o intervenție de o oră din panou la cinci minute, și face posibile lucruri pe care panoul nu le poate face deloc. Comenzile Linux de bază, dincolo de WordPress, sunt adunate în articolul despre comenzile Linux de bază pentru administratori, iar contextul general al panoului în ghidul pentru începători în cPanel.

Surse

• Manualul WP-CLI: instalarea, configurarea și principiile de utilizare.
• Lista comenzilor WP-CLI: fiecare comandă cu opțiunile ei.