WordPress Block Theme بمقابلہ Classic Theme: کھرا موازنہ

اپنا تھیم فولڈر کھولیں۔ اگر اس میں templates ڈائریکٹری ہے جس کے اندر index.html ہے، اور جڑ میں theme.json ہے، تو آپ کے پاس block theme ہے۔ اگر اس میں index.php کے ساتھ header.php اور footer.php جیسی فائلیں ہیں، اور ایڈمن سائیڈبار میں Appearance پھر Customizer دکھتا ہے، تو آپ کے پاس classic theme ہے۔

ساخت کا یہی اکلوتا فرق طے کرتا ہے کہ آپ کی سائٹ پر کون کیا بدل سکتا ہے، وہ تبدیلیاں کہاں محفوظ ہوتی ہیں، اور WordPress کی پلگ اِن دنیا کا کون سا نصف حصہ معمول کے مطابق برتاؤ کرے گا۔

تیس سیکنڈ کی پہچان

نشانی	Classic theme	Block theme
جڑ کی ٹیمپلیٹ فائل	index.php	templates/index.html
ہیڈر اور فوٹر	header.php، footer.php	parts/header.html، parts/footer.html
گلوبل کنفیگ	functions.php	theme.json (اور اختیاری طور پر functions.php)
ایڈمن مینیو	Appearance > Customizer	Appearance > Editor
تبدیلیاں کہاں محفوظ ہوتی ہیں	ڈسک پر فائلوں میں	ڈیٹابیس میں، wp_template پوسٹس کے طور پر
Widgets اسکرین	موجود	غائب

WordPress یہ فیصلہ templates/index.html کو ڈھونڈ کر کرتا ہے۔ جو تھیم theme.json تو رکھتی ہے مگر اپنے PHP ٹیمپلیٹس بھی برقرار رکھتی ہے، وہ اب بھی classic ہی شمار ہوتی ہے — یہ درمیانی حالت عام ہے اور اس کا ایک نام ہے، جس پر آگے بات ہے۔

اگر آپ کے پاس شیل تک رسائی ہے تو ایک کمانڈ فیصلہ کر دیتی ہے:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI اُس سائٹ پر سب سے تیز جانچ ہے جو آپ نے خود نہیں بنائی، خاص طور پر جب کسی page builder نے معمول کے ایڈمن مینیو چھپا رکھے ہوں۔

سائٹ میں ترمیم کرنے والے کے لیے کیا بدلتا ہے

classic theme میں ہیڈر، فوٹر، سائیڈبار، رنگ اور لوگو سب Customizer کے پیچھے ہوتے ہیں، اور آپ کو صرف وہی کنٹرول ملتے ہیں جو تھیم کے مصنف نے بنانے کا فیصلہ کیا تھا۔ اگر تھیم نے فوٹر کے کاپی رائٹ متن کے لیے کوئی کنٹرول رجسٹر نہیں کیا تو کوئی کنٹرول ہے ہی نہیں۔ یا تو PHP فائل میں ترمیم کریں، یا اسی کے ساتھ گزارا کریں۔

block theme میں Site Editor پورا صفحہ کھول کر سامنے رکھ دیتا ہے۔ ہیڈر، فوٹر، لوپ، 404 صفحہ، تلاش کے نتائج کا لے آؤٹ — سب blocks ہیں، اور سب ایسے شخص کے لیے قابلِ ترمیم ہیں جس نے کبھی PHP نہیں دیکھی۔ یہی اصل نمایاں خوبی ہے، اور واقعی بڑی ہے۔

قیمت یہ ہے کہ سب کچھ ایسے شخص کے لیے قابلِ ترمیم ہے جس نے کبھی PHP نہیں دیکھی۔ کلائنٹ رات دو بجے ہیڈر سے سائٹ کا عنوان مٹا سکتا ہے اور ڈسک پر کوئی ورژن ہسٹری نہیں جس سے بحال کیا جا سکے — صرف Site Editor کے اپنے revisions ہیں۔ block locking کے ذریعے اور ایڈیٹر تک رسائی محدود کر کے چیزیں مقفل کی جا سکتی ہیں، مگر یہ اضافی کام ہے جو آپ کو یاد رکھ کر خود کرنا پڑتا ہے۔

عملی طور پر دو چھوٹے نقصان بھی چبھتے ہیں: block themes میں Widgets اسکرین نہیں ہوتی (widget areas کی جگہ template parts اور blocks لے لیتے ہیں)، اور classic مینیو کی جگہ Navigation block آ جاتا ہے، جو اپنے آئٹمز جانی پہچانی Menus اسکرین کے بجائے ایک الگ مواد کی قسم میں رکھتا ہے۔

ڈویلپر کے لیے کیا بدلتا ہے

classic themes PHP ٹیمپلیٹ ہائرارکی استعمال کرتی ہیں۔ WordPress ایک معلوم زنجیر پر درخواست حل کرتا ہے — single-{post-type}.php، پھر single.php، پھر singular.php، پھر index.php — اور آپ کی فائل چلتی ہے، get_header() کو پکارتی ہے، لوپ چلاتی ہے، اور ایسا مارک اپ چھاپتی ہے جس کا ہر حرف آپ کے قابو میں ہے۔

<?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 وہی ہائرارکی نام استعمال کرتی ہیں مگر .html ایکسٹینشن کے ساتھ، اور فائل کے اندر block markup ہوتا ہے — تبصروں میں 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"} /-->

تین نتائج ڈویلپر کو فوراً پیش آتے ہیں:

get_header() اور get_footer() کبھی نہیں چلتے۔ جو کچھ بھی ان actions سے جڑا ہو، چاہے کسی پلگ اِن میں ہو یا پرانی چائلڈ تھیم میں، خاموشی سے بےاثر ہو جاتا ہے۔ wp_head اور wp_footer اب بھی چلتے ہیں، اس لیے زیادہ تر enqueueing بچ جاتی ہے، مگر ہیڈر سے مخصوص hooks نہیں چلتے۔

ڈیٹابیس آپ کی فائلوں کو ہرا دیتا ہے۔ جس لمحے کوئی Site Editor میں ٹیمپلیٹ محفوظ کرتا ہے، WordPress اس نسخے کو wp_template پوسٹ کے طور پر رکھ لیتا ہے اور آپ کی فائل کے بجائے وہی پیش کرتا ہے۔ آپ سارا دن HTML فائل میں ترمیم کرتے رہیں، فرنٹ اینڈ پر ذرہ برابر فرق نہیں آئے گا۔ اُس ٹیمپلیٹ کی تخصیص صاف کرنے سے فائل والا نسخہ واپس آ جاتا ہے۔ “میری block theme خراب ہے” کی سب سے عام رپورٹ یہی ہے، اور یہ کوئی بگ نہیں۔

اسٹائلنگ theme.json میں منتقل ہو جاتی ہے۔ رنگ، اسپیسنگ اسکیل، ٹائپوگرافی اور فی block ڈیفالٹس CSS کے بجائے ڈیٹا کے طور پر بیان ہوتے ہیں، اور CSS خود WordPress بناتا ہے۔ یہ صاف ستھرا اور کہیں زیادہ یکساں ہے — جب تک آپ کو کوئی ایسی چیز نہ چاہیے ہو جو اسکیما بیان نہیں کر سکتا، اور تب آپ ویسے بھی CSS لکھ رہے ہوتے ہیں اور جنریٹ شدہ قواعد کے خلاف specificity کی لڑائی لڑ رہے ہوتے ہیں۔

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

version کی قدر کو اُس WordPress ریلیز کے مقابل جانچ لیں جس پر آپ ہیں — اسکیما ایک سے زیادہ بار بدلا ہے، اور کسی پرانے ٹیوٹوریل سے ورژن نمبر نقل کرنے کا نتیجہ ایسی settings ہوتی ہیں جو خاموشی سے نظرانداز ہو جاتی ہیں۔

یاد رہے کہ functions.php ختم نہیں ہوتی۔ block themes اسے اب بھی enqueueing، add_image_size کے اندراجات رجسٹر کرنے، custom post types اور باقی ہر PHP کام کے لیے استعمال کرتی ہیں۔ بس ٹیمپلیٹنگ کا کام وہاں بہت کم رہ جاتا ہے۔

آپ کو اصل میں کیا ملتا ہے، اور کیا کھونا پڑتا ہے

block کی طرف جانے سے آپ کو ملتا ہے: پورے صفحے پر ایڈیٹر کا اختیار، theme.json سے نافذ ہوتی ڈیزائن یکسانیت، دیکھ بھال کے لیے کم فائلیں، اور ایسے styles جو ایڈیٹر اور فرنٹ اینڈ کے درمیان اُس سے کہیں زیادہ بار میل کھاتے ہیں جتنا classic themes کبھی کر سکیں۔

block کی طرف جانے سے آپ کھوتے ہیں: آؤٹ پٹ مارک اپ پر براہِ راست کنٹرول، hooks کے ذریعے سیدھی سادی تخصیص، ہر اُس چیز سے مطابقت جو PHP ٹیمپلیٹس مان کر چلتی ہے، اور یہ اطمینان کہ سائٹ کی شکل ورژن کنٹرول میں محفوظ ہے۔

آخری نکتہ زور کا مستحق ہے۔ classic theme میں git log آپ کو بتا دیتا ہے کہ کیا بدلا۔ block theme میں سائٹ کی شکل کا ایک بامعنی حصہ ڈیٹابیس میں رہتا ہے، جہاں آپ کی ڈیپلائے منٹ پائپ لائن جھانکتی تک نہیں۔

classic theme کب اب بھی درست جواب ہے

• سائٹ کوئی page builder چلا رہا ہے۔ Elementor، Divi، Beaver Builder اور اسی طرح کے ٹولز ٹیمپلیٹنگ خود سنبھال لیتے ہیں۔ ان کے نیچے block theme رکھنا ایک دوسرا ٹیمپلیٹنگ نظام بڑھا دیتا ہے جو کچھ کرتا ہی نہیں۔
• مارک اپ بالکل مخصوص ہونا چاہیے۔ خاص طور پر بنی کمپوننٹ لائبریریاں، سخت رسائی پذیری کا مارک اپ، غیر معمولی اسکیما تقاضے — block کا آؤٹ پٹ اسی حد تک محدود ہے جو blocks نکالتے ہیں، اور اس سے لڑنے کی قیمت PHP لکھنے سے زیادہ پڑتی ہے۔
• پلگ اِن کی بھاری ٹیمپلیٹنگ۔ ممبرشپ، LMS، ڈائریکٹری اور پرانی کامرس ایکسٹینشنز اکثر PHP ٹیمپلیٹ اوور رائیڈز کے ساتھ آتی ہیں۔ کئی کے پاس اب block متبادل موجود ہیں؛ کئی کے پاس نہیں۔
• سائٹ مکمل ہے اور چل رہی ہے۔ پانچ سال کی جمع شدہ تخصیص والی تھیم کے لیے block کی طرف کوئی اپ گریڈ راستہ نہیں، صرف دوبارہ تعمیر ہے۔ “یہ نیا طریقہ ہے” کوئی کاروباری وجہ نہیں۔
• آپ کے سوا کوئی اس میں ترمیم نہیں کرے گا۔ Site Editor کا بنیادی فائدہ غیر ڈویلپر افراد کو اختیار دینا ہے۔ اگر کوئی غیر ڈویلپر ہے ہی نہیں، تو آپ ایسے فائدے کی قیمت ادا کر رہے ہیں جو کوئی استعمال نہیں کرتا۔

ہائبرڈ درمیانی راستہ

ایک classic theme theme.json شامل کر کے گلوبل اسٹائلز کا نظام، رنگ اور اسپیسنگ کے presets، اور ایڈیٹر کی یکساں اسٹائلنگ حاصل کر سکتی ہے — اور ساتھ ہی اپنے PHP ٹیمپلیٹس اور Customizer بھی رکھ سکتی ہے۔ WordPress اسے block theme نہیں کہتا، اور Site Editor دستیاب نہیں ہوتا، مگر ڈیزائن سسٹم کا زیادہ تر فائدہ آپ کو بہت کم محنت میں مل جاتا ہے۔

ایسی موجودہ سائٹ کے لیے جو زیادہ تر ٹھیک چل رہی ہے، عموماً یہی پہلا درست قدم ہے۔ theme.json شامل کریں، اپنا palette اور اسپیسنگ طے کریں، جو CSS اس کی جگہ لے وہ حذف کریں، اور پھر دیکھیں کہ کیا آپ کو باقی چیزیں واقعی چاہییں۔