WordPress Block Theme बनाम Classic Theme: ईमानदार तुलना

अपने theme का folder खोलिए। अगर उसमें templates डायरेक्टरी है जिसके अंदर index.html है, और जड़ में theme.json है, तो आपके पास block theme है। अगर उसमें index.php के साथ header.php और footer.php जैसी फ़ाइलें हैं, और आपके admin sidebar में Appearance फिर Customizer दिखता है, तो आपके पास classic theme है।

बनावट का यही एक फ़र्क़ तय करता है कि आपकी साइट पर कौन क्या बदल सकता है, वे बदलाव कहाँ सहेजे जाते हैं, और WordPress के plugin तंत्र का कौन सा आधा हिस्सा सामान्य रूप से काम करेगा।

30 सेकंड की पहचान

संकेत	Classic theme	Block theme
जड़ की template फ़ाइल	index.php	templates/index.html
Header और footer	header.php, footer.php	parts/header.html, parts/footer.html
वैश्विक config	functions.php	theme.json (साथ में वैकल्पिक functions.php)
Admin menu	Appearance > Customizer	Appearance > Editor
बदलाव कहाँ सहेजे जाते हैं	डिस्क पर फ़ाइलों में	Database में, wp_template posts के रूप में
Widgets स्क्रीन	मौजूद	अनुपस्थित

WordPress यह फ़ैसला templates/index.html ढूँढकर करता है। जो theme theme.json भेजता है पर अपने PHP templates रखे रहता है, वह अब भी classic ही माना जाता है — यह बीच की स्थिति आम है और इसका एक नाम है, जिस पर नीचे बात है।

अगर आपके पास shell access है, तो एक command से बात ख़त्म:

wp eval 'var_dump( wp_is_block_theme() );'

जो साइट आपने नहीं बनाई, उस पर सबसे तेज़ जाँच WP-CLI ही है, ख़ासकर तब जब किसी page builder ने आम admin menus छिपा रखे हों।

साइट संपादित करने वाले के लिए क्या बदलता है

Classic theme में header, footer, sidebar, रंग और logo सब Customizer के पीछे रहते हैं, और आपको सिर्फ़ वही controls मिलते हैं जो theme लेखक ने बनाने का फ़ैसला किया। अगर theme ने footer के copyright text के लिए कोई control register नहीं किया, तो control है ही नहीं। या तो आप PHP फ़ाइल संपादित कीजिए, या जैसा है वैसा ही झेलिए।

Block theme में Site Editor पूरा पेज खोलकर सामने रख देता है। Header, footer, loop, 404 पेज, search results का layout — सब blocks हैं, और सब कुछ ऐसा व्यक्ति भी संपादित कर सकता है जिसने कभी PHP नहीं देखी। यही असली मुख्य सुविधा है, और यह वाक़ई बड़ी है।

क़ीमत यह है कि सब कुछ ऐसा व्यक्ति भी संपादित कर सकता है जिसने कभी PHP नहीं देखी। कोई क्लाइंट रात दो बजे header से साइट का शीर्षक मिटा सकता है, और डिस्क पर ऐसा कोई version history नहीं जिससे उसे वापस लाया जाए — सिर्फ़ Site Editor की अपनी revisions हैं। Block locking से और editor तक पहुँच सीमित करके चीज़ों को बाँधा जा सकता है, पर यह अलग से किया जाने वाला काम है जो आपको याद रखना पड़ता है।

दो छोटे नुक़सान जो व्यवहार में चुभते हैं: block themes में Widgets स्क्रीन नहीं होती (widget areas की जगह template parts और blocks ले लेते हैं), और classic menus की जगह Navigation block आ जाता है, जो अपने items को जाने-पहचाने Menus स्क्रीन के बजाय एक अलग content type में सहेजता है।

Developer के लिए क्या बदलता है

Classic themes PHP template hierarchy इस्तेमाल करती हैं। WordPress किसी request को एक जानी-पहचानी शृंखला में हल करता है — single-{post-type}.php, फिर single.php, फिर singular.php, फिर index.php — और आपकी फ़ाइल चलती है, get_header() बुलाती है, The Loop चलाती है, और ऐसा markup छापती है जिसका हर अक्षर आपके नियंत्रण में है।

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

Block themes उन्हीं hierarchy नामों का इस्तेमाल करती हैं पर .html एक्सटेंशन के साथ, और फ़ाइल में block markup होता है — comments में block delimiters वाली HTML — और कोई 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"} /-->

तीन नतीजे developers को तुरंत मिलते हैं:

get_header() और get_footer() कभी चलते ही नहीं। किसी plugin या पुराने child theme में उन actions से जुड़ी हर चीज़ चुपचाप कुछ नहीं करती। wp_head और wp_footer अब भी चलते हैं, इसलिए ज़्यादातर enqueueing बच जाती है, पर header-विशिष्ट hooks नहीं बचते।

Database आपकी फ़ाइलों को हरा देता है। जिस पल कोई Site Editor में कोई template सहेजता है, WordPress उस संस्करण को wp_template post के रूप में रख लेता है और आपकी फ़ाइल की जगह वही परोसता है। आप पूरी दोपहर HTML फ़ाइल संपादित करते रह सकते हैं और front end पर शून्य बदलाव देखेंगे। उस template का customization हटाते ही फ़ाइल वाला संस्करण लौट आता है। “मेरी block theme टूट गई” वाली सबसे आम रिपोर्ट यही है, और यह bug नहीं है।

Styling theme.json में चली जाती है। रंग, spacing scale, typography और per-block defaults CSS के बजाय डेटा के रूप में घोषित होते हैं, और CSS WordPress बनाता है। यह साफ़-सुथरा और कहीं ज़्यादा एकरूप है — जब तक आपको कोई ऐसी चीज़ न चाहिए जो schema व्यक्त नहीं करता, और तब आप वैसे भी CSS लिख रहे होते हैं और generated rules के ख़िलाफ़ specificity की लड़ाई लड़ रहे होते हैं।

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

version की value को उस WordPress रिलीज़ के हिसाब से जाँच लीजिए जिस पर आप हैं — schema एक से ज़्यादा बार बदला है, और किसी पुराने tutorial से version number copy कर लेने से ऐसी settings बनती हैं जो चुपचाप अनदेखी रह जाती हैं।

ध्यान रहे कि functions.php ग़ायब नहीं होती। Block themes उसे अब भी enqueueing, add_image_size entries register करने, custom post types और बाक़ी हर PHP काम के लिए इस्तेमाल करती हैं। बस templating का काम वहाँ बहुत कम रह जाता है।

असल में क्या मिलता है, और असल में क्या जाता है

Block चुनने पर मिलता है: पूरे पेज पर editor का नियंत्रण, theme.json से लागू होने वाली design एकरूपता, संभालने के लिए कम फ़ाइलें, और ऐसी styles जो editor और front end के बीच classic themes के मुक़ाबले कहीं ज़्यादा बार मेल खाती हैं।

Block चुनने पर जाता है: output markup पर सीधा नियंत्रण, सीधा-सादा hook-आधारित customization, PHP templates मान लेने वाली हर चीज़ के साथ अनुकूलता, और यह भरोसा कि साइट की दिखावट version control में रहती है।

आख़िरी बात पर ज़ोर देना ज़रूरी है। Classic theme में git log आपको बता देता है कि क्या बदला। Block theme में साइट की दिखावट का एक बड़ा हिस्सा database में रहता है, जहाँ आपकी deployment pipeline झाँकती तक नहीं।

Classic theme कब भी सही जवाब है

• साइट कोई page builder चला रहा है। Elementor, Divi, Beaver Builder और इन जैसे tools templating ख़ुद संभाल लेते हैं। उनके नीचे block theme डालने से एक दूसरा templating तंत्र जुड़ जाता है जो कुछ करता ही नहीं।
• Markup बिल्कुल सटीक चाहिए। ख़ास तौर पर बनाई गई component libraries, कड़े accessibility markup, असामान्य schema ज़रूरतें — block का output इस बात से बँधा है कि blocks क्या निकालते हैं, और उससे लड़ने की क़ीमत PHP लिखने से ज़्यादा पड़ती है।
• भारी plugin templating। Membership, LMS, directory और पुराने commerce extensions अक्सर PHP template overrides भेजते हैं। कई के block विकल्प अब मौजूद हैं; कई के नहीं।
• साइट बन चुकी है और चल रही है। पाँच साल के जमा हुए customization वाले theme के पास block तक जाने का कोई upgrade रास्ता नहीं है, सिर्फ़ दोबारा बनाना है। “यह नया तरीक़ा है” कोई कारोबारी वजह नहीं है।
• आपके अलावा कोई इसे संपादित नहीं करेगा। Site Editor का मुख्य फ़ायदा नियंत्रण ग़ैर-developers को सौंपना है। अगर कोई ग़ैर-developer है ही नहीं, तो आप ऐसे फ़ायदे की क़ीमत चुका रहे हैं जिसे कोई इस्तेमाल नहीं करता।

बीच का hybrid रास्ता

Classic theme में theme.json जोड़ा जा सकता है, जिससे उसे global styles प्रणाली, रंग तथा spacing presets, और एकरूप editor styling मिल जाती है — और उसके PHP templates तथा Customizer बने रहते हैं। WordPress इसे block theme नहीं कहता, और Site Editor उपलब्ध नहीं होता, पर design-system का ज़्यादातर फ़ायदा आपको काम के एक अंश में मिल जाता है।

जो साइट पहले से ठीक-ठाक चल रही है, उसके लिए आम तौर पर यही सही पहला क़दम है। theme.json जोड़िए, अपना palette और spacing तय कीजिए, जो CSS इससे बदल गई उसे हटा दीजिए, और फिर देखिए कि बाक़ी चीज़ें आपको चाहिए भी या नहीं।