থিম কাস্টমাইজেশন: বিগিনার থেকে অ্যাডভান্সড — পুরো পথটা একসাথে

একটা দৃশ্য প্রায় প্রতি মাসেই দেখি। ক্লায়েন্ট ফোন দিয়ে বলেন, সাইট ঠিকই আছে, কিন্তু তিন বছর ধরে চলা থিমটা এখন আর আপডেট পায় না, PHP 8.3-এ ওয়ার্নিং দেয়, আর তিনি নতুন কোনো থিমে যেতে চান। আমরা স্টেজিংয়ে থিম বদলে দেখি — আর সাথে সাথে হাওয়া হয়ে যায় বিকাশ পেমেন্টের নির্দেশনা, কুরিয়ার সিলেক্ট করার ফিল্ড, প্রোডাক্ট পেজের কাস্টম ব্যাজ, এমনকি ফেসবুক পিক্সেলটাও। কিছুই “হারায়নি” আসলে — সবকিছু পুরনো থিমের functions.php-তে লেখা ছিল, আর থিমটা সরিয়ে দিতেই কোডগুলোও চলে গেছে।

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

যে একটামাত্র নিয়ম ৯০ শতাংশ সিদ্ধান্ত সহজ করে দেয়

নিজেকে একটাই প্রশ্ন করুন: থিমটা কাল মুছে ফেললে এই জিনিসটার কি টিকে থাকা দরকার?

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

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

শুনতে সাদামাটা লাগছে, কিন্তু WordPress-এর যত সাইট আমি ভাঙতে দেখেছি, তার বেশিরভাগই এই এক লাইনের নিয়মটা না মানার ফল। সবাই সব কোড functions.php-তে ঢালে, কারণ ওটাই সবচেয়ে সহজ — আর তারপর আর কোনোদিন থিম বদলাতে পারে না।

কোড রাখার পাঁচটা জায়গা

• ১. Customizer → Additional CSS। ডেটাবেসে জমা হয়, থিমের সাথে বাঁধা। দ্রুত, ঝুঁকিহীন, ভার্সন কন্ট্রোলে থাকে না। ছোট CSS টুইকের জন্য একদম ঠিক আছে।
• ২. স্নিপেট প্লাগইন (WPCode বা Code Snippets)। কোড ডেটাবেসে জমা হয়, ফলে থিম বদলালেও টিকে যায় — এটাই এর বড় সুবিধা। FTP লাগে না, সাদা স্ক্রিন হলে সেফ মোডে বন্ধ করা যায়। অসুবিধা: Git-এ যায় না, আর ক্লায়েন্ট চাইলে ডিঅ্যাক্টিভেট করে দিতে পারে।
• ৩. চাইল্ড থিম (`style.css` + `functions.php`)। প্যারেন্ট থিমের আপডেটে আপনার কোড টেকে — কিন্তু থিম বদলালে টেকে না। মনে রাখবেন, চাইল্ডের functions.php প্যারেন্টেরটাকে রিপ্লেস করে না, দুটোই লোড হয় (চাইল্ডেরটা আগে)। এই ভুল ধারণা থেকেই অনেক অদ্ভুত বাগ জন্মায়।
• ৪. সাইট-স্পেসিফিক প্লাগইন বা mu-plugin। /wp-content/mu-plugins/ ফোল্ডারে PHP ফাইল রাখলে সেটা আপনাআপনি চালু থাকে — ক্লায়েন্ট প্লাগইন লিস্ট থেকে বন্ধই করতে পারবে না। থিম-নিরপেক্ষ, Git-এ যায়, ভাঙার ঝুঁকি কম। পেশাদার কাজে ফাংশনালিটির জন্য এটাই সবচেয়ে নিরাপদ ঘর।
• ৫. প্যারেন্ট থিম নিজে এডিট করা। কখনো করবেন না। পরের আপডেটেই আপনার সব পরিশ্রম মুছে যাবে — আর যদি আপডেট বন্ধ করে রাখেন, তাহলে সিকিউরিটি প্যাচও পাবেন না। একমাত্র ব্যতিক্রম: থিমটা যদি আপনারই বানানো হয়।

পাঁচটা ঘর, পাঁচরকম পরিণতি

• থিম আপডেটে টিকবে? Additional CSS — হ্যাঁ। স্নিপেট প্লাগইন — হ্যাঁ। চাইল্ড থিম — হ্যাঁ। প্যারেন্ট এডিট — না, নিশ্চিতভাবেই না।
• *থিম বদলালে টিকবে?* স্নিপেট প্লাগইন আর mu-plugin — হ্যাঁ। চাইল্ড থিম, Additional CSS — না। এই কলামটাই আসল, আর এখানেই বেশিরভাগ মানুষ ধরা খায়।
• ক্লায়েন্ট ভুল করে ভাঙতে পারবে? স্নিপেট প্লাগইন — পারবে (ডিঅ্যাক্টিভেট করে দিলেই)। mu-plugin — পারবে না। চাইল্ড থিম — সাধারণত না, যদি না তিনি থিম এডিটরে ঢুকে বসেন (তাই DISALLOW_FILE_EDIT অন করে রাখুন)।
• Git ও স্টেজিংয়ে যাবে? চাইল্ড থিম আর mu-plugin — যাবে, ফাইল বলে। Additional CSS আর স্নিপেট প্লাগইন — যাবে না, ডেটাবেসে বসে থাকে। টিমে কাজ করলে এটা বড় পার্থক্য।

বিগিনার থেকে অ্যাডভান্সড — লেভেল আপের ট্রিগার

প্রতিটা ধাপে ওঠার একটা নির্দিষ্ট সংকেত আছে। সংকেত না এলে জোর করে উপরে ওঠার দরকার নেই — অপ্রয়োজনীয় জটিলতা নিজেও একধরনের বাগ।

লেভেল ১ — Additional CSS। বাটনের রঙ, ফন্ট সাইজ, মোবাইলে একটা এলিমেন্ট লুকানো। DevTools দিয়ে সিলেক্টর বের করুন, লিখে ফেলুন। উপরে ওঠার সংকেত: যখন CSS ১০০ লাইন ছাড়ায়, বা যখন প্রায় প্রতি লাইনে !important লিখতে হচ্ছে — বুঝবেন আপনি ডিজাইনের সাথে যুদ্ধ করছেন, ফাইল করছেন না।

লেভেল ২ — চাইল্ড থিম। এখন CSS একটা আসল ফাইলে থাকে, আর functions.php খুলে যায়। প্যারেন্টের স্টাইল ঠিকভাবে enqueue করুন, নাহলে অর্ধেক ডিজাইন উধাও হবে। সংকেত: যখন CSS-এর বাইরে গিয়ে PHP লিখতে হচ্ছে।

লেভেল ৩ — হুক আর ফিল্টার। WordPress-এর আসল শক্তি এখানেই। add_action দিয়ে জিনিস বসান, add_filter দিয়ে জিনিস বদলান, remove_action দিয়ে থিমের নিজের জিনিস সরান। উদাহরণ: WooCommerce চেকআউটে বিকাশ/নগদ নম্বরের একটা নোট বসানো, বা ক্যাশ-অন-ডেলিভারির শর্ত দেখানো — দশ লাইনের একটা ফিল্টার, কোনো টেমপ্লেট না ছুঁয়েই। সংকেত: যখন কোনো হুক খুঁজে পাচ্ছেন না, অথচ HTML-এর গঠনটাই বদলাতে হবে।

লেভেল ৪ — টেমপ্লেট ওভাররাইড। WooCommerce-এর টেমপ্লেট ফাইল কপি করে চাইল্ড থিমের /woocommerce/ ফোল্ডারে রাখলে WooCommerce আপনার কপিটাই ব্যবহার করে। শক্তিশালী, কিন্তু এখানে একটা ফাঁদ আছে যেটা অনেকেই দেরিতে টের পায়: WooCommerce যখন মূল টেমপ্লেটটা আপডেট করে, আপনার কপিটা পুরনো হয়ে বসে থাকে। WooCommerce → Status পেজে গিয়ে “outdated templates” সতর্কতাটা নিয়মিত দেখুন — নাহলে ছয় মাস পর চেকআউটে অদ্ভুত বাগ পাবেন আর কারণ খুঁজে পাবেন না। নিয়ম: টেমপ্লেট ওভাররাইড হলো শেষ অস্ত্র, প্রথম না।

লেভেল ৫ — `theme.json` আর ব্লক স্টাইল। ব্লক থিমের যুগে রঙ, ফন্ট, স্পেসিং — সব এক ফাইলে ডিক্লেয়ার করা যায়, আর এডিটরের ভেতরেও ঠিক সেটাই দেখা যায় যা সামনে দেখাবে। বাংলা সাইটে এটা বিশেষভাবে কাজে দেয়: Hind Siliguri বা Noto Sans Bengali theme.json-এ ঠিকভাবে রেজিস্টার করে দিলে পুরো সাইটে ফন্ট এক থাকে, আর register_block_style() দিয়ে ক্লায়েন্টকে দুটো-তিনটে বৈধ ডিজাইন অপশন দিয়ে দেওয়া যায় — যাতে তিনি নিজের মতো রঙ বেছে সাইটের চেহারা নষ্ট করতে না পারেন।

সবচেয়ে দামি ভুলটা কোড লেখার ভুল নয় — জায়গা বাছার ভুল। ট্র্যাকিং কোড header.php-তে বসালে সেটা কাজ করবে, ঠিকই কাজ করবে। তারপর একদিন থিম বদলাবে, ট্র্যাকিং নীরবে বন্ধ হয়ে যাবে, আর তিন মাস পর ক্লায়েন্ট জিজ্ঞেস করবেন ডেটা কোথায় গেল।

কোন কোড কোথায় — এক নজরে

• সাধারণ CSS টুইক, একটামাত্র সাইট, তাড়াহুড়ো আছে → Additional CSS। জটিল করার দরকার নেই।
• কোডটা থিম বদলালেও লাগবে, কিন্তু আপনি FTP/Git ঘাঁটতে চান না → WPCode-এর মতো স্নিপেট প্লাগইন। ক্লায়েন্টের ছোট সাইটে বাস্তবসম্মত সমাধান।
• ডিজাইন-সংক্রান্ত পরিবর্তন, থিমের সাথেই যার সম্পর্ক → চাইল্ড থিম। CSS, টেমপ্লেট, লেআউট — সব এখানে।
• ব্যবসার জন্য জরুরি ফাংশনালিটি, যেটা কোনোভাবেই বন্ধ হওয়া চলবে না → mu-plugin। পিক্সেল, অ্যানালিটিক্স, কাস্টম পোস্ট টাইপ, পেমেন্ট লজিক — সব ওখানে রাখুন।
• প্যারেন্ট থিম এডিট করা → কখনো না। ব্যতিক্রম নেই, অজুহাত নেই।

যা জিজ্ঞেস করতেই হয়

চাইল্ড থিম কি এখনো দরকার? ক্লাসিক থিমে — অবশ্যই। ব্লক থিমে — অনেক কম, কারণ আপনার টেমপ্লেট আর স্টাইল পরিবর্তন ডেটাবেসে জমা হয়, থিম ফাইলে নয়। শুধু PHP বা theme.json বদলাতে হলেই চাইল্ড থিম লাগবে।

স্নিপেট প্লাগইন কি সাইট ধীর করে দেয়? না, উল্লেখযোগ্যভাবে নয়। WPCode-এর ২০টা স্নিপেট চালানোর খরচ একটা বাড়তি স্লাইডার প্লাগইনের চেয়েও কম। পারফরম্যান্স নিয়ে দুশ্চিন্তা করলে আগে ছবির সাইজ আর পেজ বিল্ডার দেখুন, স্নিপেট নয়।

থিম এডিটর (Appearance → Theme File Editor) ব্যবহার করা যাবে? লাইভ সাইটে না। একটা সেমিকোলন ভুলে গেলেই পুরো সাইট সাদা হয়ে যাবে, আর সেটা ঠিক করতে হবে FTP দিয়ে — সম্ভবত মাঝরাতে। wp-config.php-তে define('DISALLOW_FILE_EDIT', true); লিখে অপশনটা বন্ধই করে রাখুন।

পুরনো সাইটে সব কোড `functions.php`-তে, এখন কী করব? একদিনে সব সরাতে যাবেন না। স্টেজিং কপি বানান, তারপর কেবল সেই কোডগুলো mu-plugin-এ সরান যেগুলো থিম-নিরপেক্ষ (ট্র্যাকিং, পোস্ট টাইপ, শর্টকোড)। ডিজাইনের কোড যেখানে আছে সেখানেই থাক। এক সপ্তাহে ধাপে ধাপে করলে ঝুঁকি প্রায় শূন্য।

একটা লাইন মনে রাখলেই যথেষ্ট

যদি একটা কথাই মনে রাখতে চান, রাখুন এটা: ডিজাইন থিমের, ফাংশনালিটি প্লাগইনের। এই লাইনটা মেনে চললে আজ থেকে দুই বছর পর আপনি — কিংবা আপনার ক্লায়েন্টের পরের ডেভেলপার — নির্ভয়ে থিম বদলাতে পারবেন, আর ব্যবসার কিছুই ভাঙবে না। আর WordPress-এ দীর্ঘমেয়াদে টিকে থাকা মানে ঠিক এটুকুই — এমনভাবে কাজ করা যাতে ভবিষ্যতের কেউ আপনাকে গালি না দেয়।

পুরনো কোনো সাইট যদি থিমের সাথে এমনভাবে জড়িয়ে গেছে যে বদলানোই যাচ্ছে না, স্ট্যাক অ্যালিক্স টিম সেটা ধাপে ধাপে ছাড়িয়ে আনার কাজ করে — সাইট বন্ধ না রেখেই। দরকার হলে জানাবেন।