Temă bloc vs temă clasică în WordPress: comparația cinstită

Deschide folderul temei. Dacă are un director templates cu un index.html înăuntru, plus un theme.json în rădăcină, ai o temă bloc. Dacă are index.php alături de fișiere precum header.php și footer.php, iar bara laterală din administrare îți arată Aspect apoi Personalizare, ai o temă clasică.

Această singură diferență de structură decide cine poate schimba ce pe site-ul tău, unde se stochează acele schimbări și care jumătate din ecosistemul de pluginuri WordPress se comportă normal.

Identificarea în 30 de secunde

Semn	Temă clasică	Temă bloc
Fișierul de șablon rădăcină	index.php	templates/index.html
Antet și subsol	header.php, footer.php	parts/header.html, parts/footer.html
Configurare globală	functions.php	theme.json (plus functions.php opțional)
Meniu de administrare	Aspect > Personalizare	Aspect > Editor
Unde se salvează modificările	Fișiere pe disc	Baza de date, ca articole wp_template
Ecranul de widgeturi	Există	Lipsește

WordPress decide căutând templates/index.html. O temă care livrează un theme.json, dar își păstrează șabloanele PHP, este tot clasică — acea stare intermediară este frecventă și are un nume, despre care vorbim mai jos.

Dacă ai acces la shell, o singură comandă lămurește lucrurile:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI este cea mai rapidă verificare pe un site pe care nu l-ai construit tu, mai ales când un page builder a ascuns meniurile obișnuite din administrare.

Ce se schimbă pentru cel care editează site-ul

Într-o temă clasică, antetul, subsolul, bara laterală, culorile și logo-ul stau în spatele Personalizatorului, iar tu ai doar controalele pe care autorul temei a decis să le construiască. Dacă tema nu a înregistrat un control pentru textul de copyright din subsol, nu există niciun control. Fie editezi un fișier PHP, fie te împaci cu situația.

Într-o temă bloc, Editorul de site expune toată pagina. Antet, subsol, bucla de articole, pagina 404, layout-ul rezultatelor de căutare — totul este blocuri, totul poate fi editat de cineva care nu a văzut PHP în viața lui. Asta este adevărata funcție-vedetă și este cu adevărat importantă.

Costul este că totul poate fi editat de cineva care nu a văzut PHP în viața lui. Un client poate șterge titlul site-ului din antet la 2 noaptea și nu există niciun istoric de versiuni pe disc din care să recuperezi — doar reviziile proprii ale Editorului de site. Se pot bloca lucruri, prin blocarea blocurilor și prin restricționarea accesului la editor, dar este muncă opțională, pe care trebuie să-ți amintești să o faci.

Alte două pierderi mai mici, care se simt în practică: temele bloc nu au ecran de widgeturi (zonele de widgeturi sunt înlocuite de părți de șablon și blocuri), iar meniurile clasice sunt înlocuite de blocul Navigare, care își stochează elementele ca tip de conținut separat, nu în ecranul de Meniuri cu care ești obișnuit.

Ce se schimbă pentru dezvoltator

Temele clasice folosesc ierarhia de șabloane PHP. WordPress rezolvă o cerere pe un lanț cunoscut — single-{post-type}.php, apoi single.php, apoi singular.php, apoi index.php — iar fișierul tău rulează, apelează get_header(), execută Bucla și scrie markup pe care îl controlezi caracter cu caracter.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

Temele bloc folosesc aceleași nume din ierarhie, dar cu extensia .html, iar fișierul conține markup de blocuri — HTML cu delimitatori de bloc scriși în comentarii — și nu există etichete de șablon:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Trei consecințe pe care dezvoltatorii le simt imediat:

get_header() și get_footer() nu rulează niciodată. Orice este atașat acelor acțiuni, într-un plugin sau într-o temă child veche, nu face nimic, în tăcere. wp_head și wp_footer se declanșează în continuare, deci majoritatea enqueue-urilor supraviețuiesc, dar hook-urile specifice antetului nu.

Baza de date bate fișierele tale. În clipa în care cineva salvează un șablon în Editorul de site, WordPress stochează acea versiune ca articol wp_template și o servește în locul fișierului tău. Poți edita fișierul HTML toată după-amiaza și să vezi zero schimbări pe front-end. Ștergerea personalizării pentru acel șablon readuce versiunea din fișier. Aceasta este cea mai frecventă sesizare de tip „mi s-a stricat tema bloc” și nu este un bug.

Stilizarea se mută în theme.json. Culorile, scara de spațiere, tipografia și valorile implicite per bloc sunt declarate ca date, nu ca CSS, iar WordPress generează CSS-ul. Este mai curat și mult mai consecvent — până când ai nevoie de ceva ce schema nu poate exprima, moment în care oricum scrii CSS și te lupți cu specificitatea împotriva regulilor generate.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

Verifică valoarea lui version față de versiunea de WordPress pe care rulezi — schema a fost revizuită de mai multe ori, iar copierea unui număr de versiune dintr-un tutorial vechi produce setări ignorate în tăcere.

Reține că functions.php nu dispare. Temele bloc îl folosesc în continuare pentru enqueue-uri, pentru înregistrarea intrărilor add_image_size, pentru tipuri de conținut personalizate și pentru orice altceva ține de PHP. Doar că faci mult mai puțină muncă de șabloane acolo.

Ce câștigi de fapt și ce pierzi de fapt

Trecerea la blocuri îți aduce: control din editor asupra întregii pagini, consecvență de design impusă de theme.json, mai puține fișiere de întreținut și stiluri care se potrivesc între editor și front-end mult mai des decât au reușit vreodată temele clasice.

Trecerea la blocuri te costă: controlul direct asupra markup-ului generat, personalizarea simplă prin hook-uri, compatibilitatea cu orice presupune șabloane PHP și siguranța că aspectul site-ului stă în controlul versiunilor.

Ultimul punct merită subliniat. Într-o temă clasică, git log îți spune ce s-a schimbat. Într-o temă bloc, o parte semnificativă din aspectul site-ului stă în baza de date, unde pipeline-ul tău de deploy nici măcar nu se uită.

Când o temă clasică este în continuare răspunsul corect

• Site-ul este condus de un page builder. Elementor, Divi, Beaver Builder și altele preiau ele însele partea de șabloane. Punerea unei teme bloc dedesubt adaugă un al doilea sistem de șabloane care nu face nimic.
• Markup-ul trebuie să fie exact. Biblioteci de componente făcute la comandă, markup strict pentru accesibilitate, cerințe neobișnuite de schema — ceea ce generează blocurile este limitat, iar lupta cu ele costă mai mult decât scrisul de PHP.
• Multe șabloane din pluginuri. Pluginurile de membership, LMS, directoare și extensiile mai vechi de comerț livrează frecvent suprascrieri de șabloane PHP. Multe au acum echivalente cu blocuri; multe nu au.
• Site-ul este gata și funcționează. O temă cu cinci ani de personalizări acumulate nu are cale de upgrade spre blocuri, ci doar o reconstrucție. „Este abordarea mai nouă” nu este un motiv de business.
• Nimeni în afară de tine nu îl va edita. Beneficiul principal al Editorului de site este să dai controlul celor care nu sunt dezvoltatori. Dacă nu există non-dezvoltatori, plătești costurile pentru un beneficiu pe care nu îl folosește nimeni.

Calea de mijloc, hibridă

O temă clasică poate adăuga un theme.json și primește sistemul de stiluri globale, presetările de culoare și spațiere și stilizare consecventă în editor — păstrându-și în același timp șabloanele PHP și Personalizatorul. WordPress nu numește asta temă bloc, iar Editorul de site rămâne indisponibil, dar obții aproape tot beneficiul de sistem de design cu o fracțiune din muncă.

Pentru un site existent care merge bine în mare parte, aceasta este de obicei prima mișcare corectă. Adaugă theme.json, definește-ți paleta și spațierea, șterge CSS-ul pe care îl înlocuiește și vezi apoi dacă mai vrei și restul.