থিম কাস্টমাইজেশন: ৬টি ভুল ধারণা আর পরিবর্তন আসলে কোথায় জমা হয়

প্রায় প্রতি মাসেই একটা ফোন আসে, আর কথাগুলো প্রায় হুবহু এক: “ভাই, থিম আপডেট দিলাম, হেডার আগের চেহারায় ফিরে গেছে — যা যা কাজ করেছিলাম সব উধাও।” যিনি ফোন করেন তিনি মনে করেন তিনি কোনো ভুল করেননি, আর একদিক থেকে তিনি ঠিকই বলেন — তিনি ঠিক সেটাই করেছেন যা ইউটিউব টিউটোরিয়ালে দেখানো হয়েছিল। সমস্যাটা টিউটোরিয়ালেও না। সমস্যা হলো ওটা ২০১৭ সালের, আর তিনি ২০২৬ সালের একটা ব্লক থিমে সেটা প্রয়োগ করছেন।

theme customization নিয়ে এত ভুল ধারণা এখনো বেঁচে আছে একটাই কারণে: WordPress-এ থিম বদলানোর চার যুগের পদ্ধতি একসাথে, পাশাপাশি চলছে। ক্লাসিক থিম আর PHP টেমপ্লেট, Customizer, পেজ বিল্ডার, আর ব্লক থিম-Site Editor — চারটাই আজও কাজ করে, আর গুগলে সার্চ করলে চারটার টিউটোরিয়ালই সমান আত্মবিশ্বাসের সাথে সামনে আসে। কোন পরামর্শটা আপনার সাইটের জন্য প্রযোজ্য সেটা না বুঝেই বেশিরভাগ মানুষ কাজে হাত দেয়। নিচের ছয়টা বিশ্বাস আমরা ক্লায়েন্ট আর জুনিয়র ডেভেলপারদের কাছ থেকে বারবার শুনি — ছয়টাই ভুল, আর ছয়টার ভুল হওয়ার দাম কেউ না কেউ শেষমেশ দেয়।

“কাস্টমাইজেশন মানে থিমের ফাইলে ঢুকে কোড বদলানো”

Appearance → Theme File Editor — ড্যাশবোর্ডের সবচেয়ে বিপজ্জনক মেনুটার নাম এত নিরীহ যে কেউ ভয় পায় না। ওখান থেকে সরাসরি header.php বা style.css খুলে হেডারটা ঠিক করে ফেলা যায়, আর সেভ চাপলেই সাইটে বদলটা দেখা যায়। কিন্তু ওই ফাইলগুলো আপনার নয় — ওগুলো থিম ডেভেলপারের। পরের বার Astra বা OceanWP আপডেট হলে ওদের নতুন ফাইল আপনার লেখা লাইনগুলোর ওপর দিয়ে কপি হয়ে যাবে, আর আপনার তিন দিনের কাজ কোনো ওয়ার্নিং, কোনো কনফার্মেশন ছাড়াই মুছে যাবে।

এই ভুলটা কেন এত ছড়িয়েছে বোঝা কঠিন নয় — কারণ এটা কাজ করে। ঠিক ততক্ষণ, যতক্ষণ কেউ আপডেট বাটনটা চাপে না। আর যেহেতু ক্ষতিটা সাথে সাথে হয় না, হয় তিন-চার মাস পরে, তাই কেউ কারণ আর ফলাফলকে আর মেলাতে পারে না। একটা রেস্তোরাঁর সাইটে আমরা দেখেছিলাম মেনু পেজের পুরো লেআউট parent থিমের page.php-তে হার্ডকোড করা; একটা রুটিন সিকিউরিটি আপডেটে পুরো পেজ ডিফল্ট চেহারায় ফিরে যায়, আর যিনি কাজটা করেছিলেন তিনি ততদিনে ফোন ধরা বন্ধ করে দিয়েছেন।

সবচেয়ে সহজ প্রতিরোধ এক লাইনের: wp-config.php-তে define('DISALLOW_FILE_EDIT', true); বসিয়ে ড্যাশবোর্ডের ফাইল এডিটরটাই বন্ধ করে দিন। আর নিয়মটা মুখস্থ রাখুন — যে ফাইল আপনি লেখেননি, সেটা এডিট করবেন না; সেটাকে ওভাররাইড করুন।

“চাইল্ড থিম বানিয়ে ফেললেই সব নিরাপদ”

চাইল্ড থিম নিয়ে সমস্যা এই নয় যে জিনিসটা খারাপ — সমস্যা হলো এটাকে একটা জাদুর ঢাল ভাবা হয়। চাইল্ড থিম আপনার ফাইলগুলোকে আপডেট থেকে বাঁচায়, আপনার অনুমানগুলোকে নয়। ধরুন parent থিমের single.php কপি করে চাইল্ডে বসালেন, তারপর সেখানে কাটাছেঁড়া করলেন। এখন ওই ফাইলটার মালিক আপনি, চিরকালের জন্য। parent থিম পরের ভার্সনে যদি নতুন hook যোগ করে, স্কিমা মার্কআপ ঠিক করে, কিংবা অ্যাক্সেসিবিলিটির জন্য মার্কআপ বদলায় — সেই উন্নতিগুলোর একটাও আপনার সাইটে ঢুকবে না। আপনি নিরাপদ নন; আপনি শুধু হিমায়িত।

দ্বিতীয় সমস্যাটা আরও নতুন, আর এটা নিয়ে ফেসবুক গ্রুপে কেউ কথা বলে না। ২০২৬-এ যেসব ব্লক থিম দিয়ে কাজ হচ্ছে — Twenty Twenty-Five, Ollie, Frost — সেগুলোতে Site Editor-এ করা টেমপ্লেট পরিবর্তন ফাইলে যায় না, ডাটাবেসে wp_template আর wp_template_part পোস্ট টাইপে জমা হয়। মানে হেডার বদলানো, নতুন টেমপ্লেট বানানো, রঙ ঠিক করা — এসবের জন্য চাইল্ড থিম লাগেই না। তবুও অনেকে অভ্যাসবশত একটা খালি চাইল্ড থিম বানিয়ে বসে থাকেন, যেটা কার্যত কিছুই করে না। চাইল্ড থিম তখনই দরকার যখন আপনার PHP লিখতে হবে, বা theme.json-এর টোকেন গোড়া থেকে বদলাতে হবে।

• ক্লাসিক থিম, সাথে PHP পরিবর্তন বা টেমপ্লেট ওভাররাইড → চাইল্ড থিম, এখানে কোনো বিতর্ক নেই।
• ব্লক থিম, সাথে রঙ-ফন্ট-স্পেসিং-হেডার-ফুটার → Site Editor আর theme.json-ই যথেষ্ট; চাইল্ড থিম না বানালেও চলবে।
• শুধু কয়েকটা snippet (যেমন WooCommerce-এর একটা লেবেল বদলানো) → চাইল্ড থিমের functions.php-তে না রেখে ছোট একটা site-specific প্লাগিনে রাখুন। তাহলে দুই বছর পর থিম বদলালেও কোডটা বেঁচে থাকবে।
• parent-এর পুরো টেমপ্লেট ফাইল কপি করার আগে দুইবার ভাবুন। একটা hook বা filter দিয়ে কাজ হয়ে গেলে সেটাই করুন — কম কোড, কম রক্ষণাবেক্ষণ, আর আপস্ট্রিমের ফিক্সগুলো আসতেই থাকবে।

“Customizer-ই তো কাস্টমাইজেশনের জায়গা”

Appearance → Customize একসময় সত্যিই কেন্দ্র ছিল, মোটামুটি ২০১৫ থেকে ২০২১ পর্যন্ত। এখন ব্লক থিম চালালে অনেক সাইটে ওই মেনুটাই আর দেখা যায় না, আর প্রথমবার Site Editor খুলে অনেকে ভাবেন থিমটা বুঝি “ভাঙা”। ভাঙেনি; কেন্দ্রটা সরে গেছে। ২০২৬-এ গ্লোবাল স্টাইলের একমাত্র উৎস হলো theme.json — রঙের প্যালেট, ফন্ট সাইজের স্কেল, স্পেসিং, কনটেন্ট ও ওয়াইড লেআউটের প্রস্থ, সবকিছুর সংজ্ঞা ওই এক ফাইলে।

theme.json-এর আসল সুবিধাটা কেউ বলে না, তাই বলে রাখি — এটা কাস্টমাইজ করার চেয়ে বেশি কাজে লাগে বেড়া দিতে। প্যালেটে ব্র্যান্ডের পাঁচটা রঙ ঢুকিয়ে দিলে এডিটরের প্রতিটা কালার পিকারে ঠিক ওই পাঁচটাই দেখাবে, তার বাইরে কিছু নয়। ফলে ছয় মাস পরে ক্লায়েন্টের মার্কেটিং টিম কোনো একটা ল্যান্ডিং পেজে হঠাৎ ফ্লুরোসেন্ট গোলাপি বসিয়ে দিতে পারবে না — কারণ অপশনটাই নেই। ডিজাইন সিস্টেম যদি সত্যিই টিকিয়ে রাখতে চান, বেড়াটা কোডে থাকতে হবে; ব্র্যান্ড গাইডলাইনের PDF কেউ খোলে না।

• গ্লোবাল রঙ, টাইপোগ্রাফি স্কেল, স্পেসিং → theme.json
• হেডার, ফুটার, আর্কাইভ ও সিঙ্গেল টেমপ্লেট → Site Editor-এর টেমপ্লেট ও টেমপ্লেট পার্ট
• বারবার ব্যবহার হওয়া সেকশন (CTA, প্রাইসিং টেবিল, টেস্টিমোনিয়াল) → block pattern, দরকার হলে synced pattern
• হুক, ফিল্টার, কাস্টম পোস্ট টাইপ, ব্যবসায়িক লজিক → চাইল্ড থিমের functions.php বা আলাদা প্লাগিন

“CSS দিয়ে সব ঠিক করে ফেলা যায় — না হলে !important আছে”

Additional CSS বাক্সটা শুরু হয় নিরীহভাবে, তিন লাইন দিয়ে। এক বছর পরে সেটা ১,৮০০ লাইনের একটা জঞ্জাল, যার অর্ধেক লাইনের শেষে !important, আর কেউ জানে না কোন নিয়মটা এখনো কাজে লাগে আর কোনটা মরা। একটা ক্লায়েন্ট সাইটে আমরা ৪০০ লাইন CSS পেয়েছিলাম যার পুরোটা লেখা হয়েছিল একটা প্লাগিনের জন্য — সেই প্লাগিন আট মাস আগেই ডিলিট হয়ে গেছে, CSS-টা রয়ে গেছে, আর প্রতিটা পেজলোডে সেটা ব্রাউজারে পৌঁছাচ্ছে।

আরও একটা ব্যাপার কম মানুষ জানে: Additional CSS-এ লেখা কোড ডাটাবেসে থিমের সাথে বাঁধা থাকে। থিম বদলালে ওটা আপনার সাথে যায় না, চুপচাপ পড়ে থাকে। তাই আসল CSS চাইল্ড থিমের স্টাইলশিটে রাখুন এবং ঠিকভাবে enqueue করুন — ভার্সন হিসেবে filemtime() দিলে ফাইল বদলানোমাত্র ক্যাশ নিজে থেকেই ভাঙবে, আর “ক্লায়েন্ট বলছে চেঞ্জ দেখতে পাচ্ছে না” সমস্যাটা চিরতরে বিদায় নেবে। আর !important টাইপ করার আগে একবার ব্রাউজারের ইন্সপেক্টর খুলে দেখুন সেলেক্টরটা আসলে কোথায় হারছে; দশবারের নয়বারই সমস্যাটা স্পেসিফিসিটির, জেদের নয়।

কাজের নিয়ম: একই ফল যদি theme.json-এর একটা টোকেন দিয়ে পাওয়া যায়, তাহলে CSS লিখবেন না। CSS তখনই লিখুন যখন টোকেনটা নেই — এবং তখন সেটা চাইল্ড থিমের ফাইলে লিখুন, Customizer-এর বাক্সে নয়।

“Elementor বা Divi ব্যবহার করলে থিমটা কী, সেটা আর ম্যাটার করে না”

পেজ বিল্ডার পেজের ক্যানভাসটা দখল করে, পুরো সাইটটা নয়। হেডার, ফুটার, ব্লগ আর্কাইভ, সিঙ্গেল পোস্ট, 404, সার্চ রেজাল্ট — এগুলো এখনো থিমের হাতে, যদি না আপনি বিল্ডারের থিম-বিল্ডার অ্যাডঅনটাও কেনেন। কোন ফন্ট লোড হচ্ছে, কোন স্ক্রিপ্ট enqueue হচ্ছে, wp_head-এ কী বসছে — সেটাও থিমই ঠিক করে। এজন্যই Hello Elementor-এর মতো ইচ্ছাকৃতভাবে খালি একটা থিম বেছে নেওয়া একটা সচেতন সিদ্ধান্ত; আর একটা ভারী মাল্টিপারপাস থিমের ওপরে Elementor চাপিয়ে দেওয়া মানে দুইটা লেআউট ইঞ্জিনকে একে অপরের সাথে কুস্তি করতে বসানো।

বিল্ডারের আসল দামটা দেখা যায় দুই বছর পরে, বেরোনোর সময়। আপনার পোস্টের কনটেন্ট তখন ডাটাবেসে শর্টকোড আর JSON-এর স্তূপ হয়ে বসে আছে; বিল্ডার ডিঅ্যাকটিভেট করলে পেজজুড়ে [vc_row]-এর মতো জঞ্জাল ভেসে ওঠে। এটা এড়ানোর একটা সহজ অভ্যাস আছে, আর সেটা শুরু থেকেই ধরতে হয় — বিল্ডার দিয়ে লেআউট বানান, কিন্তু ব্লগ পোস্টের বডি টেক্সট বিল্ডারে না লিখে সাধারণ এডিটরেই লিখুন। লেআউট আবার বানানো যায়; পাঁচ বছরে জমা হওয়া ২০০টা পোস্টের লেখা উদ্ধার করা যায় না।

“কাস্টমাইজেশন মানে শুধু দেখতে কেমন হবে”

প্রতিটা ডিজাইন সিদ্ধান্তের সাথে আরও তিনটা সিদ্ধান্ত নিঃশব্দে ঢুকে পড়ে। প্রথমটা পারফরম্যান্স: চারটা আইকনের জন্য গোটা একটা আইকন লাইব্রেরি লোড করা, বা হোমপেজের একটামাত্র স্লাইডারের জন্য একটা ভারী স্ক্রিপ্ট টেনে আনা — এগুলো ডিজাইন রিভিউতে কেউ ধরে না, কিন্তু মোবাইল ডেটায় ঢাকার বাইরে বসে থাকা ইউজার প্রতিদিন এর দাম দেন। দ্বিতীয়টা অ্যাক্সেসিবিলিটি: ব্র্যান্ডের ওই হালকা ধূসর টেক্সট সাদা ব্যাকগ্রাউন্ডে দেখতে যত মার্জিত, ৪.৫:১ কনট্রাস্ট রেশিওতে তত ব্যর্থ — আর দুপুরের রোদে দাঁড়িয়ে কেউ ওটা পড়তে পারবে না।

তৃতীয়টা সবচেয়ে বেশি ভোগায়, কারণ এর দাম দেয় ক্লায়েন্ট: এডিটেবিলিটি। ফুটারে ক্লায়েন্টের bKash মার্চেন্ট নম্বরটা যদি টেমপ্লেট ফাইলে হার্ডকোড করে দেন, তিন মাস পরে নম্বর বদলালে ক্লায়েন্টকে আপনার কাছেই ফিরে আসতে হবে — আর তিনি তখন আপনাকে একজন ভালো ডেভেলপার হিসেবে নয়, একটা বাধা হিসেবে মনে রাখবেন। যা যা ভবিষ্যতে বদলাতে পারে — ফোন নম্বর, ঠিকানা, অফার ব্যানার, ঈদের ডিসকাউন্ট — সেগুলো ব্লক, প্যাটার্ন বা ACF ফিল্ডে রাখুন। ভালো কাস্টমাইজেশনের একটা নিষ্ঠুর কিন্তু নির্ভুল মাপকাঠি আছে: হ্যান্ডওভারের পরে ক্লায়েন্টকে কতবার আপনাকে ফোন করতে হয়।

কোন পরিবর্তন কোথায় থাকবে — একটা কাজের মানচিত্র

উপরের ছয়টা ভুলের গোড়ায় আসলে একটাই জিনিস: মানুষ জানে না তার পরিবর্তনটা ফিজিক্যালি কোথায় জমা হচ্ছে। তাই কোড লেখার আগে প্রতিবার নিজেকে একটাই প্রশ্ন করুন — “এই পরিবর্তনটা কোথায় সেভ হচ্ছে, আর থিম আপডেট বা থিম পরিবর্তনের পর সেটা বাঁচবে কি না?” উত্তরটা জানা থাকলে আপনি আর কখনো ভুল স্তরে কাজ করবেন না, আর ওপরের ফোনটা আপনাকে কখনো করতে হবে না।

• থিম আপডেটেই মুছে যায় → parent থিমের যেকোনো ফাইল। এখানে কখনো কিছু লিখবেন না।
• থিম আপডেটে টেকে, কিন্তু থিম বদলালে চলে যায় → চাইল্ড থিম, theme.json, Site Editor-এর টেমপ্লেট, Additional CSS।
• থিম বদলালেও টিকে থাকে → প্লাগিন, ACF ফিল্ড, কাস্টম পোস্ট টাইপ, মিডিয়া লাইব্রেরি, আর পোস্টের কনটেন্ট।
• কী টিকে থাকা দরকার, সেটাই ঠিক করে দেবে আপনি কোথায় লিখবেন। ক্লায়েন্টের ব্যবসার লজিক কখনোই থিমে রাখবেন না — থিম হলো পোশাক, ব্যবসা নয়।

সচরাচর জিজ্ঞাসা

ব্লক থিমে কি চাইল্ড থিম বানানোর দরকার আছে? বেশিরভাগ ক্ষেত্রে নেই। রঙ, ফন্ট, স্পেসিং, হেডার-ফুটার — সবই Site Editor থেকে করা যায় এবং সেগুলো ডাটাবেসে সেভ হয়, তাই থিম আপডেটে মুছে যায় না। চাইল্ড থিম তখনই বানান যখন PHP লিখতে হবে, কাস্টম ব্লক ভ্যারিয়েশন যোগ করবেন, বা theme.json-এর টোকেনগুলো গোড়া থেকে বদলাবেন।

পুরনো ক্লাসিক থিম থেকে ব্লক থিমে যাওয়া কি জরুরি? জরুরি নয়। কিন্তু থিমটা যদি দুই বছরের বেশি সময় ধরে কোনো আপডেট না পেয়ে থাকে, তাহলে সমস্যাটা থিমের ধরনে নয়, রক্ষণাবেক্ষণে — এবং সেটা সত্যিই সমস্যা। ভালো চলতে থাকা একটা সাইট শুধু “নতুন পদ্ধতি এসেছে” বলে ভাঙার দরকার নেই; তবে ২০২৬-এ নতুন প্রজেক্ট শুরু করলে ব্লক থিম দিয়ে শুরু করাই যুক্তিসঙ্গত।

Additional CSS-এর কোডগুলো চাইল্ড থিমে সরাব কীভাবে? পুরোটা কপি করে চাইল্ড থিমের style.css-এ বসিয়ে দেওয়ার আগে একবার পড়ে দেখুন — সাধারণত ৩০ থেকে ৪০ শতাংশ নিয়ম এমন সব এলিমেন্টের জন্য লেখা যা সাইটে আর নেই-ই। বাকিটা সরিয়ে নিয়ে ব্রাউজারে প্রতিটা টেমপ্লেট একবার চোখ বুলিয়ে নিন, তারপর Customizer-এর বাক্সটা খালি করে দিন।

থিম কাস্টমাইজ করলে কি সাইট স্লো হয়ে যায়? কাস্টমাইজেশন নিজে থেকে স্লো করে না; স্লো করে অপ্রয়োজনীয় জিনিস যোগ করা — বাড়তি ফন্ট ওয়েট, স্লাইডার, তিন-তিনটা আইকন লাইব্রেরি, একই কাজের দুইটা প্লাগিন। বরং ভালোভাবে কাস্টমাইজ করা সাইট প্রায়ই ডেমোর চেয়ে দ্রুত হয়, কারণ তখন আপনি ডেমো কনটেন্টের ভারী মডিউলগুলো নির্দ্বিধায় ফেলে দিতে পারেন।

থিম কাস্টমাইজেশনে আটকে আছেন, নাকি একটা আপডেটে কয়েক সপ্তাহের কাজ হারিয়ে ফেলেছেন — স্ট্যাক অ্যালিক্সের টিম দুটোই সামলায়। সাইটের লিংকটা পাঠিয়ে দিন; আমরা দেখে সোজাসুজি বলে দেব কোন পরিবর্তনটা কোন স্তরে বসে আছে, আর কোনগুলো পরের আপডেটেই মুছে যাবে।