WordPress Block Theme kontra Classic Theme: Ang Tapat na Paghahambing

Buksan ang folder ng tema mo. Kung may templates directory ito na may index.html sa loob, kasama ang theme.json sa ugat, block theme ang mayroon ka. Kung may index.php ito katabi ng mga file gaya ng header.php at footer.php, at ipinapakita ng admin sidebar mo ang Appearance tapos Customizer, classic theme ang mayroon ka.

Ang iisang pagkakaibang iyon sa istruktura ang nagpapasya kung sino ang makakapagbago ng ano sa site mo, saan nakaimbak ang mga pagbabagong iyon, at aling kalahati ng plugin ecosystem ng WordPress ang gagana nang normal.

Ang 30-segundong pagkilala

Palatandaan	Classic theme	Block theme
Pangunahing template file	index.php	templates/index.html
Header at footer	header.php, footer.php	parts/header.html, parts/footer.html
Global na konpigurasyon	functions.php	theme.json (kasama ang opsyonal na functions.php)
Menu sa admin	Appearance > Customizer	Appearance > Editor
Saan nase-save ang mga edit	Mga file sa disk	Database, bilang wp_template posts
Widgets screen	Nariyan	Wala

Nagpapasya ang WordPress sa pamamagitan ng paghahanap ng templates/index.html. Ang temang may theme.json pero may PHP templates pa rin ay itinuturing pa ring classic — karaniwan ang gitnang kalagayang ito at may pangalan ito, na tatalakayin sa ibaba.

Kung may shell access ka, isang command lang ang kailangan:

wp eval 'var_dump( wp_is_block_theme() );'

Ang WP-CLI ang pinakamabilis na pagsusuri sa site na hindi ikaw ang gumawa, lalo na kapag itinago ng page builder ang karaniwang mga admin menu.

Ano ang nagbabago para sa taong nag-e-edit ng site

Sa classic theme, ang header, footer, sidebar, kulay at logo ay nasa likod ng Customizer, at ang makukuha mo lang ay ang mga kontrol na pinili ng gumawa ng tema. Kung hindi nagrehistro ang tema ng kontrol para sa footer copyright text, wala talagang kontrol. Mag-e-edit ka ng PHP file o tatanggapin mo na lang ito.

Sa block theme, ipinapakita ng Site Editor ang buong pahina. Ang header, footer, ang loop, ang 404 page, ang layout ng resulta ng paghahanap — pawang mga block, at mababago lahat ng taong hindi pa nakakita ng PHP. Iyan ang tunay na pangunahing tampok, at malaki talaga ito.

Ang kapalit ay mababago rin ang lahat ng taong hindi pa nakakita ng PHP. Kayang burahin ng kliyente ang pamagat ng site sa header nang alas-dos ng madaling araw at walang version history sa disk na pagbabalikan — ang revisions lang ng Site Editor. Posible ang pagsasara nito gamit ang block locking at sa pamamagitan ng paghihigpit kung sino ang makakarating sa editor, pero kusang-loob na trabaho ito na kailangan mong tandaang gawin.

Dalawang mas maliit na pagkawala ang nararamdaman sa praktika: walang Widgets screen ang block themes (napalitan ng template parts at blocks ang widget areas), at napalitan ng Navigation block ang klasikong menus, na nag-iimbak ng mga item nito bilang hiwalay na uri ng nilalaman sa halip na sa pamilyar na Menus screen.

Ano ang nagbabago para sa developer

Gumagamit ang classic themes ng PHP template hierarchy. Sinusundan ng WordPress ang isang kilalang tanikala para sa bawat request — single-{post-type}.php, tapos single.php, tapos singular.php, tapos index.php — at tumatakbo ang file mo, tumatawag ng get_header(), pinapatakbo ang The Loop, at naglilimbag ng markup na kontrolado mo hanggang sa huling karakter.

<?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(); ?>

Ginagamit ng block themes ang parehong pangalan sa hierarchy pero may .html na extension, at block markup ang laman ng file — HTML na may block delimiters sa loob ng comments — at walang template tags:

<!-- 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"} /-->

Tatlong bunga ang agad na nararanasan ng mga developer:

Hindi kailanman tumatakbo ang get_header() at get_footer(). Anumang naka-hook sa mga action na iyon, sa isang plugin man o sa lumang child theme, ay tahimik na walang gagawin. Umaandar pa rin ang wp_head at wp_footer, kaya nakakaligtas ang karamihan ng enqueueing, pero hindi ang mga hook na para sa header.

Nananalo ang database laban sa mga file mo. Sa sandaling may mag-save ng template sa Site Editor, iniimbak ng WordPress ang bersyong iyon bilang wp_template post at ito ang inihahain sa halip na ang file mo. Pwede mong i-edit ang HTML file buong hapon at walang kahit anong magbabago sa harap. Ang pagbura sa kustomisasyon ng template na iyon ang nagbabalik sa bersyon ng file. Ito ang pinakakaraniwang ulat na sira raw ang block theme, at hindi ito bug.

Lumilipat sa theme.json ang pag-eestilo. Ang kulay, spacing scale, typography at per-block defaults ay idinedeklara bilang datos sa halip na CSS, at ang WordPress na ang gumagawa ng CSS. Mas malinis ito at mas pare-pareho — hanggang sa kailanganin mo ng isang bagay na hindi kayang ipahayag ng schema, at doon ay sumusulat ka na rin naman ng CSS at nakikipaglaban sa specificity ng mga nabuong rule.

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

Suriin ang halaga ng version laban sa WordPress release na ginagamit mo — nabago na nang ilang beses ang schema at ang pagkopya ng version number mula sa lumang tutorial ay lumilikha ng settings na tahimik na binabalewala.

Pansinin na hindi nawawala ang functions.php. Ginagamit pa rin ito ng block themes para sa enqueueing, pagrerehistro ng add_image_size entries, custom post types, at anupamang PHP. Mas kaunti lang ang templating na ginagawa mo roon.

Ano ang talagang napapala mo, at ano ang talagang nawawala

Ang napapala mo sa paglipat sa block: kontrol ng editor sa buong pahina, pagkakapare-pareho ng disenyo na ipinatutupad ng theme.json, mas kaunting file na aalagaan, at mga estilong mas madalas magkatugma sa editor at sa harap kaysa sa naabot ng classic themes.

Ang nawawala sa iyo sa paglipat sa block: tuwirang kontrol sa output markup, tuwirang kustomisasyon batay sa hooks, pagkakatugma sa anumang umaasa sa PHP templates, at ang katiyakang nasa version control ang itsura ng site.

Nararapat diinan ang huli. Sa classic theme, sinasabi sa iyo ng git log kung ano ang nagbago. Sa block theme, malaking bahagi ng itsura ng site ay nakatira sa database kung saan hindi tumitingin ang deployment pipeline mo.

Kailan pa rin tamang sagot ang classic theme

• May page builder na nagpapatakbo ng site. Ang Elementor, Divi, Beaver Builder at katulad ay sila na mismo ang humahawak ng templating. Ang paglalagay ng block theme sa ilalim nila ay nagdadagdag ng pangalawang sistema ng templating na walang ginagawa.
• Kailangang eksakto ang markup. Mga pasadyang component library, mahigpit na accessibility markup, hindi pangkaraniwang schema — nakakulong ang output ng block sa kung ano ang inilalabas ng mga block, at mas mahal ang makipagbuno rito kaysa sumulat ng PHP.
• Mabigat ang templating ng plugin. Ang membership, LMS, directory at mas lumang commerce extensions ay madalas may sariling PHP template overrides. Marami na ang may katumbas na block ngayon; marami rin ang wala.
• Tapos na at gumagana ang site. Ang temang may limang taon nang naipong kustomisasyon ay walang daan paakyat sa block, muling pagbuo lang. Ang bagong paraan ito ay hindi dahilang pangnegosyo.
• Wala nang ibang mag-e-edit nito kundi ikaw. Ang pangunahing pakinabang ng Site Editor ay ang pagbibigay ng kontrol sa hindi developer. Kung walang hindi developer, binabayaran mo ang gastos para sa pakinabang na walang gumagamit.

Ang gitnang landas na hybrid

Kayang magdagdag ng classic theme ng theme.json at makuha ang global styles system, ang color at spacing presets, at ang tugmang estilo sa editor — habang pinananatili ang PHP templates at Customizer nito. Hindi ito tinatawag ng WordPress na block theme, at nananatiling hindi magagamit ang Site Editor, pero makukuha mo ang halos lahat ng pakinabang ng design system sa kapiraso lamang ng trabaho.

Para sa umiiral nang site na maayos naman, ito ang kadalasang tamang unang hakbang. Magdagdag ng theme.json, tukuyin ang palette at spacing mo, burahin ang CSS na napapalitan nito, at tingnan kung gusto mo pa ang natitira.