Sub capotă: serverul web, PHP și baza de date

Modulul 1: Cum funcționează WordPress · Timp de citire: 8 minute

Obiectiv de învățare: După această lecție veți putea explica pas cu pas cum devine o cerere de pagină în WordPress o pagină HTML și unde scurtează un cache acest traseu.

Concepte-cheie: server web (LiteSpeed, Apache, nginx), PHP, MariaDB/MySQL, interogare (query), index.php, ierarhia șabloanelor, dinamic vs static, TTFB

O pagină statică și una dinamică

La o pagină statică, fiecare pagină există ca fișier gata făcut pe server. Serverul web preia fișierul și îl trimite. Acest lucru este rapid și simplu, dar fiecare modificare înseamnă un fișier nou.

WordPress este dinamic: pagina există doar în momentul în care cineva o solicită. Nu există un fișier contact.html. Există o bucată de text în baza de date, o temă cu șabloane și o grămadă de cod PHP care le combină pe cele două. Acest lucru oferă comoditate (modificați textul direct din browser), dar necesită calcule la fiecare vizită. Dacă înțelegeți aceste calcule, veți înțelege mai târziu și de ce o site web este lentă, de ce caching-ul contează atât de mult și de ce o actualizare PHP poate strica ceva.

Călătoria unei cereri de pagină

Să presupunem că un vizitator deschide https://example.com/contact/. Se întâmplă următoarele:

1. DNS: browserul caută adresa IP a domeniului example.com (vezi cursul de DNS). Acesta stabilește o conexiune securizată cu adresa respectivă.
2. Server web: pe server rulează un server web, de exemplu LiteSpeed, Apache sau nginx. Acesta primește cererea. Dacă există un fișier sau un folder real cu acel nume (o imagine, o foaie de stiluri), îl trimite direct. Dacă nu, se aplică regula din .htaccess (la LiteSpeed și Apache) sau din configurația nginx: „dă tot ce nu există către index.php”.
3. PHP: index.php este un fișier PHP. Serverul web îl lasă să fie executat de PHP, limbajul de programare în care este scris WordPress. PHP încarcă mai întâi wp-config.php (setările, cu datele bazei de date), apoi restul WordPress-ului, apoi toate modulele (pluginurile) active și tema activă.
4. Baza de date: WordPress verifică ce conținut corespunde adresei /contact/ și pune întrebări bazei de date (MariaDB sau MySQL): ce pagină are slug-ul contact, care sunt setările site-ului, ce meniu îi corespunde? O astfel de întrebare se numește interogare (query). O pagină simplă necesită deja zeci de interogări; cu module (pluginuri) pot ajunge la sute.
5. Temă: WordPress alege ce șablon al temei formatează pagina. Acest lucru funcționează conform ierarhiei șabloanelor: pentru o pagină cu slug-ul contact, WordPress caută mai întâi un șablon page-contact, apoi page-<id> (numărul paginii), apoi page, apoi singular și în final index. Primul care există câștigă.
6. HTML înapoi: rezultatul este o pagină HTML pe care PHP o dă serverului web, iar serverul web browserului.
7. Browserul citește HTML-ul și apoi mai preia foile de stiluri, scripturile, fonturile și imaginile. Acestea sunt fișiere obișnuite, deci vin direct de la serverul web (sau dintr-un cache).

Între pasul 2 și pasul 6 se află timpul necesar serverului pentru a genera pagina. Acest lucru se reflectă în TTFB (time to first byte, timp până la primul octet): timpul dintre cerere și primul octet al răspunsului. La o site web bine configurată, acesta este mult sub o secundă. În modulul 6 veți măsura chiar dumneavoastră acest lucru.

De ce contează fiecare modul (plugin)

La pasul 3 sunt încărcate toate modulele (pluginurile) active, la fiecare cerere. Chiar dacă acel modul (plugin) nu face nimic pe această pagină. Un modul (plugin) pentru o galerie foto este așadar încărcat și atunci când cineva deschide pagina dumneavoastră de contact. Fiecare modul (plugin) poate efectua interogări suplimentare, poate încărca cod suplimentar și poate adăuga scripturi suplimentare paginii.

Acest lucru explică două aspecte pe care le veți întâlni mai des în acest curs:

• Mai puține module (pluginuri) înseamnă de obicei mai rapid. Nu pentru că numărul în sine contează, ci pentru că fiecare modul (plugin) poate efectua lucrări la fiecare cerere.
• Un singur modul (plugin) stricat poate bloca întreaga site. Dacă la pasul 3 ceva merge greșit (de exemplu, un modul (plugin) care nu funcționează cu noua versiune PHP), PHP nu ajunge niciodată la pasul 6. Vizitatorul primește o pagină albă sau mesajul „A apărut o eroare critică pe acest site web” (lecția 5.4).

De unde provin PHP și baza de date

PHP și baza de date rulează pe serverul furnizorului dumneavoastră de găzduire. De obicei, alegeți chiar dumneavoastră versiunea PHP în panoul de control (la DirectAdmin aceasta se numește Select PHP version, vezi lecția 8.4). Baza de date este creată în timpul instalării; instalatorul face adesea acest lucru pentru dumneavoastră (lecția 2.2).

Câteva lucruri de reținut:

• Versiunea PHP: fiecare versiune nouă de PHP este mai rapidă și mai sigură, dar codul vechi poate eșua pe ea. wordpress.org recomandă în prezent PHP 8.3 sau mai nou (stare noiembrie 2026).
• Baza de date: wordpress.org recomandă MariaDB 10.11 sau mai nou, sau MySQL 8.0 sau mai nou. MariaDB este o ramificație a MySQL; pentru WordPress nu există nicio diferență.
• Baza de date se află de obicei pe același server (DB_HOST este atunci localhost). La găzduirea de dimensiuni mai mari, aceasta se poate afla pe un server separat.

Cache: scurtarea traseului

Dacă o sută de vizitatori solicită aceeași pagină de contact, WordPress o generează din nou de o sută de ori, fără cache. De fiecare dată aceleași interogări, același șablon, același HTML. Un cache de pagini păstrează HTML-ul după prima dată. Următorul vizitator primește versiunea salvată: pașii 3 până la 6 inclusiv sunt eliminați.

Zonder cache:  browser > webserver > PHP > WordPress + plugins > database > thema > HTML
Met cache:     browser > webserver > opgeslagen HTML

Acesta este motivul pentru care caching-ul oferă cel mai mare câștig de viteză (lecția 6.2). Acest lucru explică și o confuzie des întâlnită: „am modificat textul, dar văd versiunea veche.” În acest caz primiți o versiune salvată; după golirea cache-ului veți vedea noua versiune.

Nu totul poate proveni dintr-un cache. Un administrator autentificat, un coș de cumpărături sau o pagină de finalizare a comenzii sunt diferite pentru fiecare vizitator. Un modul (plugin) de cache bun le exclude.

Antete: ce vă comunică serverul

Fiecare răspuns al unui server web începe cu antete (headers), înainte de HTML. Nu le vedeți pe pagină, dar le puteți vedea în instrumentele de dezvoltare ale browserului dumneavoastră (F12, fila Rețea, faceți clic pe prima cerere). Un exemplu:

HTTP/2 200
server: LiteSpeed
content-type: text/html; charset=UTF-8
link: <https://example.com/wp-json/>; rel="https://api.w.org/"
x-litespeed-cache: hit

• server indică ce server web răspunde.
• link cu wp-json dezvăluie că este vorba de WordPress.
• x-litespeed-cache: hit înseamnă că această pagină a provenit din cache-ul LiteSpeed. Alte cache-uri folosesc alte denumiri, precum x-cache: HIT sau cf-cache-status: HIT la Cloudflare.

Nu trebuie să memorați aceste rânduri pe de rost. Dar cine știe să le citească poate găsi multe probleme singur.

Rezumat

• WordPress generează fiecare pagină în momentul cererii: server web, PHP, module (pluginuri), bază de date, temă, HTML.
• La fiecare cerere sunt încărcate toate modulele (pluginurile) active; un singur modul (plugin) stricat poate opri întreaga site.
• Ierarhia șabloanelor stabilește ce șablon al temei formatează o pagină.
• Un cache de pagini elimină efortul de calcul oferind HTML salvat. Utilizatorii autentificați și coșurile de cumpărături nu trebuie să fie în acel cache.
• Antetele unui răspuns indică ce server web răspunde și dacă pagina a provenit dintr-un cache.

Test (quiz)

Exercițiu

Exercițiu A1.2: Citiți antetele site-ului dumneavoastră. Deschideți propria dumneavoastră site (sau wordpress.org) cu instrumentele de dezvoltare ale browserului dumneavoastră (F12, fila Rețea, reîmprospătați pagina, faceți clic pe prima cerere). Completați ce server web apare în antetul server (sau „niciunul” dacă nu există) și dacă există un antet care indică faptul că pagina a provenit dintr-un cache (ce nume și ce valoare). Programul solicită aceeași pagină și compară.

Lecturi suplimentare

Aceste articole descriu pașii din panourile WebOké; în alte panouri funcționează similar.

• Manual DirectAdmin 1.9: Noțiuni explicate: domain, subdomain, pointer, DNS, mailbox și database
• Manual DirectAdmin 14.1: Alegerea versiunii de PHP (Select PHP version)
• Curs gratuit de DNS 1.4: Călătoria unei interogări DNS
• Ierarhia șabloanelor (developer.wordpress.org, Engleză): https://developer.wordpress.org/themes/basics/template-hierarchy/