১১ অক্টো, ২০২৫·8 মিনিট
রাসমুস লারদর্ফ ও PHP: ব্যক্তিগত টুল থেকে ওয়েবের অপরিহার্য উপাদান
রাসমুস লারদর্ফ এবং PHP-র গল্প—কিভাবে কয়েকটি ওয়েব স্ক্রিপ্ট বিস্তৃত প্ল্যাটফর্মে পরিণত হলো, এবং কেন আজও অনেক সাইটে PHP ব্যবহৃত হয়।
রাসমুস লারদর্ফ এবং PHP-র গল্প—কিভাবে কয়েকটি ওয়েব স্ক্রিপ্ট বিস্তৃত প্ল্যাটফর্মে পরিণত হলো, এবং কেন আজও অনেক সাইটে PHP ব্যবহৃত হয়।
PHP কোনও বড় প্ল্যাটফর্ম বা সুচিন্তিত ভাষা হিসেবে শুরু হয়নি। এটি শুরু হয়েছিল কারণ রাসমুস লারদর্ফ একটি বাস্তব সমস্যার সমাধান করতে চেয়েছিল: বারবারের ম্যানুয়াল কাজ ছাড়াই একটি ব্যক্তিগত ওয়েবসাইট বজায় রাখা।
এই ছোট কিন্তু নির্দিষ্ট লক্ষ্যটি গুরুত্বপূর্ণ, কারণ এটা অনেক কিছু ব্যাখ্যা করে—কেন PHP আজও অনেকাংশে তেমন অনুভূত হয়।
লারদর্ফ তখনকার ওয়েবের জন্য ডেভেলপার ছিলেন, যখন পেজগুলো প্রধানত স্ট্যাটিক ছিল এবং HTML ছাড়া কিছু এডিট করলে দ্রুতই ক্লান্তিকর হয়ে যেত। তিনি চাইতেন সহজ স্ক্রিপ্ট যা ভিজিটরদের ট্র্যাক করবে, সাধারণ পেজ অংশগুলি পুনরায় ব্যবহার করবে, এবং ডাইনামিক কনটেন্ট জেনারেট করবে।
অর্থাৎ: তিনি চাইতেন এমন টুল যা তাকে দ্রুত পরিবর্তন পাঠাতে সাহায্য করবে।
“ব্যক্তিগত টুল” কোনো ব্র্যান্ড নয়—এটি একটি মানসিকতা ছিল। প্রাথমিক ওয়েব বিল্ডাররা প্রায়ই ছোট ইউটিলিটি লিখতেন অদক্ষ কাজগুলো অটোমেট করতে:
PHP-র প্রথম সংস্করণগুলো সেই ব্যবহারিক, ‘কাজ সেরে ফেলো’ দৃষ্টিভঙ্গি দ্বারা গঠিত ছিল।
একবার আপনি PHP-র শিকড় জানলে, এর অনেক বৈশিষ্ট্য বুঝতে সুবিধা হয়: HTML-এ সরাসরি কোড এমবেড করার উপর জোর, সাধারণ ওয়েব টাস্কের জন্য বড় স্ট্যান্ডার্ড লাইব্রেরি, এবং অ্যাকাডেমিক পরিশীলনের চেয়ে সুবিধাকে অগ্রাধিকার দেয়া।
এই সিদ্ধান্তগুলো PHP-কে দ্রুত ছড়িয়ে দিতে সাহায্য করেছে, তবে সেগুলো কিছু ট্রেড-অফও তৈরি করেছে—যা পরে আলোচনা করা হবে।
নিবন্ধটি ব্যাখ্যা করে কিভাবে PHP লারদর্ফের স্ক্রিপ্ট থেকে কমিউনিটি-চালিত ভাষায় পরিণত হয়েছিল, কেন এটি হোস্টিং ও LAMP স্ট্যকের সাথে ভাল মিশে গিয়েছিল, কিভাবে WordPress-জাত ইকোসিস্টেম এটিকে আরও বিস্তার করেছে, এবং PHP-এর আধুনিক সংস্করণ (7 ও 8+) কীভাবে পরিবর্তন এনেছে—যাতে আপনি PHP-কে বাস্তবতার ওপর ভিত্তি করে বিচার করতে পারেন, নস্টালজিয়া বা হাইপ নয়।
১৯৯০-এর দশকের মাঝামাঝি সময়ে ওয়েব বেশিরভাগই স্ট্যাটিক HTML ছিল। যদি আপনি কিছু ডাইনামিক করতে চান—ফর্ম প্রসেস করা, হিট কাউন্টার দেখানো, বা প্রতিটি ভিজিটারের জন্য পেজ কাস্টমাইজ করা—তবে সাধারণত CGI স্ক্রিপ্ট ব্যবহার করা হতো, প্রায়ই Perl-এ।
এটি কাজ করত, কিন্তু ভাসাল ছিল না।
CGI প্রোগ্রাম প্রতিটি অনুরোধে আলাদা প্রসেস হিসেবে চলত। সহজ টাস্কের জন্য এর মানে অনেকগুলো চলমান অংশ—একটি স্ক্রিপ্ট ফাইল, সাবধানে সেট করা পারমিশন, সার্ভার কনফিগারেশন—এবং এমন একটি মেন্টাল মডেল যেটা “ওয়েব পেজ লেখা” মনে হতো না। আপনি HTML-এ সামান্য লজিক মিশাচ্ছেন না; আপনি একটি ছোট প্রোগ্রাম তৈরি করছেন যা টেক্সট হিসেবে HTML আউটপুট দিচ্ছে।
শখিয়া সাইট এবং ছোট ব্যবসায়ের জন্য সাধারণ চাহিদাগুলো বাস্তব ও পুনরাবৃত্তি ছিল:
অধিকাংশ মানুষ শেয়ার্ড হোস্টিং-এ ছিল, যেখানে CPU, মেমরি সীমিত এবং সার্ভার সেটিংস নিয়ন্ত্রণ কম। কাস্টম মডিউল ইনস্টল করা বা দীর্ঘ-চলমান সার্ভিস রাখা বাস্তবসম্মত ছিল না। আপনি যে কাজটি করতে পারতেন তা হলো ফাইল আপলোড করা এবং সহজ স্ক্রিপ্ট চালানো।
এই সীমাবদ্ধতা এমন একটি টুলের দিকে চাপ দিল যা:
এই খাঁজ—স্ট্যাটিক পেজ এবং ভারী-ওয়েট স্ক্রিপ্টিংর মধ্যে—ই ছিল সেই দৈনন্দিন ওয়েব সমস্যা যা PHP সমাধান করতে চেয়েছিল।
লারদর্ফ কোন প্রোগ্রামিং ভাষা তৈরি করতে চেয়েছিলেন না; তিনি চাইতেন তার নিজের সাইট চালানোর একটি ভালো উপায়।
PHP-এর প্রথম কাজগুলো ছিল ছোট C প্রোগ্রামের সংগ্রহ যা তিনি তার অনলাইন রিজিউমে ভিজিট ট্র্যাক করার জন্য ব্যবহার করতেন, পাশাপাশি কয়েকটি ইউটিলিটি যাতে বারবার পেজ হাত দিয়ে এডিট না করতে হয়।
সেই সময়ে জানতে কীভাবে আপনার সাইটে কে আসছে (এবং কতবার) সহজ ছিল না—লারদর্ফের স্ক্রিপ্টগুলি অনুরোধ লগ ও সারাংশ তৈরি করত, যাতে ট্র্যাফিক প্যাটার্ন বোঝা সহজ হয়।
এছাড়া তিনি সাধারণ ওয়েব কাজের জন্য হেল্পার তৈরি করেছিলেন—সহজ টেমপ্লেটিং, ছোট ডাইনামিক আউটপুট, এবং ফর্ম হ্যান্ডলিং—যাতে সাইট “লাইভ” মনে হত বিশেষ কোনো বড় কাস্টম অ্যাপ ছাড়াই।
একবার আপনার কাছে অনুরোধ ট্র্যাকিং, ফর্ম প্রসেসিং, এবং পেজ কম্পোনেন্টগুলি পুনঃব্যবহারের টুল থাকল, তখন আপনি এমন কিছু তৈরি করেছেন যা অন্যরাও ব্যবহার করতে পারত।
এইটা জরুরি মুহূর্ত: ফাংশনালিটি কোনো এক লেআউট বা একটি পেজের সঙ্গেই বাঁধা ছিল না। এটা সাধারণ ছিল—অন্য সাইট মালিকরাও একই পদ্ধতি তাদের প্রকল্পে কল্পনা করতে পারত।
কারণ এটি একটি টুলবক্স হিসেবে শুরু হয়েছিল, উদ্বিগ্নতা ছিল ব্যবহারিক: সাধারণ কাজ দ্রুত করো, অতিরিক্ত ডিজাইনের দরকার নেই, এবং প্রবেশের বাধা কম রাখো।
এই মনোভাব—প্রথমে উপযোগিতা, পরে পালিশ—PHP-কে প্রথম থেকেই প্রযোজ্য করে তুলেছিল।
উপসংহারটি সহজ: PHP-র শিকড় একাডেমিক বা তাত্ত্বিক ছিল না। এগুলো সমস্যা-চালিত ছিল—বাস্তব সাইট কম ঘাটতি আর কম বাঁধা দিয়ে কাজ করুক, সেটাই লক্ষ্য ছিল।
PHP একটি “ভাষা” হিসেবে শুরু হয়নি যেভাবে মানুষ আজ ধরে নেয়। প্রথম পাবলিক মাইলস্টোন ছিল PHP/FI, যার পুরো নাম ছিল “Personal Home Page / Forms Interpreter.”
এই নামটাই বলছে: এটি সবকিছু হতে চায়নি। এটি ডিজাইন করা হয়েছিল ডাইনামিক পেজ বানানো এবং ওয়েব ফর্ম প্রসেস করার জন্য, প্রতিটি টাস্কে সম্পূর্ণ কাস্টম প্রোগ্রাম লিখিয়ে ফেলা না।
PHP/FI কয়েকটি ব্যবহারিক ধারণা একত্র করে দিল যা মিলে প্রাথমিক ওয়েব ডেভেলপমেন্টকে অনেক সহজ করে তুলল:
এটি পরিপাটি ছিল না, কিন্তু এটি মানুষকে শুধু একটি পেজ কাজ করার জন্য প্রয়োজনীয় গ্লু-কোড কম লিখতে দেয়।
প্রাথমিক ওয়েবসাইটগুলো দ্রুতই এক বাধায় পড়ত: আপনি যখনই ফিডব্যাক ফর্ম, গেস্টবুক, সাইন-আপ, বা সহজ সার্চ করতে চান, তখন ইউজার ইনপুট গ্রহণ করে কিছু করা লাগবে।
PHP/FI ফর্ম হ্যান্ডলিংকে মূল ব্যবহারিক ক্ষেত্রে পরিণত করল। ফর্মগুলোকে একটি উন্নত ফিচার হিসেবে না দেখে এটি তাদেরকে সহজ করে তুলল—জমা হওয়া মান পড়া এবং রেসপন্স পেজ জেনারেট করা সরল হলো।
এই ফোকাসটি প্রতিদিনের সাইট মালিকদের চাহিদার সঙ্গে মিলছিল।
PHP/FI-র সবচেয়ে প্রভাবশালী ধারণাগুলোর একটি ছিল এর টেমপ্লেটিং স্টাইল: HTML-কে প্রধান ডকুমেন্ট রাখো, এবং ছোট ছোট সার্ভার-লজিক ঢুকিয়ে দাও।
<!-- HTML-first, with small dynamic pieces -->
<p>Hello, <?php echo $name; ?>!</p>
ডিজাইনার ও টিঙ্কারদের কাছে এটি স্বাভাবিক মনে হচ্ছিল: আপনি একটি পেজ এডিট করে “পর্যাপ্ত” ডাইনামিক আচরণ যোগ করতে পারতেন, কোনও সম্পূর্ণ আলাদা সিস্টেম গ্রহণ না করেই।
PHP/FI পরিপাটি ছিল না, এবং সেটাই লক্ষ্যমাত্রা ছিল না। মানুষ এটি গ্রহণ করেছিল কারণ এটি ছিল:
এই “কিলার” ফিচারগুলো চকমক নয়—তবে সেগুলোই প্রাথমিক ওয়েবের প্রয়োজন ছিল।
রাসমুস লারদর্ফের প্রাথমিক PHP স্ক্রিপ্টগুলো তার নিজের সমস্যা সমাধানের উদ্দেশ্যেই ছিল: ভিজিটর ট্র্যাক করা, সাধারণ পেজ কম্পোনেন্ট পুনরায় ব্যবহার, এবং কাজটি দ্রুত করা।
ছোট ইউটিলিটি এক ব্যক্তি থেকে অনেকের কাজে লাগার পরই PHP-কে পরিচিতি ও সম্প্রসারণ মিলেছিল।
PHP পাবলিশ হতেই ব্যবহারকারীরা ফিক্স, ছোট ফিচার এবং আইডিয়া পাঠাতে শুরু করল। সেই প্রতিক্রিয়া-লুপটি গুরুত্বপূর্ণ: প্রজেক্টটি এক ব্যক্তির চাহিদার বদলে অনেক ওয়েবমাস্টারের চাহিদাকে প্রতিফলিত করতে শুরু করল।
ডকুমেন্টেশন উন্নত হল, এজ-কেসগুলো প্যাচ হল, এবং ভাষাটা ধীরে ধীরে কনভেনশন পেল যা শেখা ও ব্যবহার করা সহজ করে তোলে।
এক বড় মোড় ছিল PHP 3—কোর ইঞ্জিন রিরাইট করা হয় এবং নাম বদল করে “PHP: Hypertext Preprocessor” করা হয়। এটি কেবল ব্র্যান্ডিং ছিল না।
রিরাইটটি ভাষাটিকে আরও কনসিস্টেন্ট ও এক্সটেন্ডেবল করে তোলে, যার ফলে PHP বড় হয়ে উঠতে সক্ষম হলো।
বড় ব্যবহারকারী সম্প্রদায় বিভিন্ন ডাটাবেস ও সার্ভিসের সাথে ইন্টিগ্রেশনের দাবি তুলল। এক্সটেনশনগুলো আসতে লাগল যা PHP-কে বিভিন্ন ডাটাবেস ও সার্ভিসের সাথে যুক্ত করে দিল—ফলে আপনি একটি নির্দিষ্ট সেটআপেই আটকা ছিলেন না।
“HTML আউটপুট দেয় এমন স্ক্রিপ্ট” থেকে PHP বদলে গেল—ডেটা-চালিত ওয়েবসাইট বানানোর একটি ব্যবহারিক উপায়ে: গেস্টবুক, ফোরাম, কেটালগ, এবং প্রাথমিক ই-কমার্স।
এইটাই মূল পরিবর্তন: কমিউনিটি কন্ট্রিবিউশনগুলো কেবল ফিচার যোগ করেনি; তারা PHP-র ভূমিকা বদলে দিয়ে এটিকে একটি ভাগ করা, এক্সটেন্ডেবল প্ল্যাটফর্মে পরিণত করল যাতে সত্যিকারের প্রকল্প গড়া যায়।
PHP এতগুলো ওয়েবসাইটের ডিফল্ট পছন্দ হয়ে উঠল কেবল সহজ হওয়ায় নয়—এক বড় অংশ ছিল কোরের সীমা শক্তিশালী করা যা PHP-কে দ্রুত, আরও কনসিস্টেন্ট, এবং এক্সটেনশনের জন্য উপযোগী করে তুলল।
Zend (Andi Gutmans ও Zeev Suraski দ্বারা প্রতিষ্ঠিত) Zend Engine নামে PHP-র নতুন কোর পরিচয় করিয়ে দিল। ভাবুন এটি গাড়ির ইঞ্জিন বদলে দেওয়ার মতো, গাড়ির মডেল একই রেখে।
ডেভেলপাররা পরিচিত PHP কোডই লিখতে পারছিলেন, কিন্তু রানটাইমটি ভিতর থেকে আরও ভালভাবে সংগঠিত হয়ে উঠল।
এই গঠন ফলে গুরুত্বপূর্ণ বিষয়গুলো সম্ভব হলো:
PHP 4 (Zend Engine 1) তখনকার শেয়ার্ড-হোস্টিং মডেলের জন্য একেবারে সঠিক সময়ে এলো।
শেয়ার্ড হোস্টিং প্রদানকারীরা সহজেই PHP অফার করতে পারত, এবং অনেকেই তাই করল। এই প্রাপ্যতা একটি গ্রোথ লুপ তৈরি করল: বেশি হোস্টিং সমর্থন করলো PHP, তাই আরও মানুষ ব্যবহার করল; বেশি ব্যবহার হোস্টিংকে বারবার PHP সমর্থন করতে বাধ্য করলো।
বাস্তবে, PHP 4 “প্রায় সর্বত্র ঠিকঠাক কাজ করে”—এটাই সবচেয়ে গুরুত্বপূর্ণ বিষয়।
PHP 5 (Zend Engine 2) বড়ো প্রকল্পের জন্য PHP-কে আরও ভালো করে তুলল। প্রধান পরিবর্তন ছিল শক্তিশালী অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিং: ক্লাস হ্যান্ডলিং উন্নত, ভিসিবিলিটি নিয়ম ভালো করা, এবং আরও আধুনিক প্যাটার্নের ভিত্তি রাখা।
এটি PHP-কে একাডেমিক করতে নয়—বরং বাস্তব প্রকল্প সংগঠিত করা, কোড পুনঃব্যবহার এবং রক্ষণাবেক্ষণ সহজ করা ছিল উদ্দেশ্য।
PHP ছড়িয়ে পড়ার সাথে একটি চাপও এল: লোকেরা আশা করতে শুরু করল পুরোনো কোড চলমান থাকবে। হোস্টরা, CMS প্ল্যাটফর্ম ও এজেন্সিগুলো স্থিতিশীলতার ওপর নির্ভর করছিল।
এই মুহূর্ত থেকে PHP-র বিবর্তন আর ছিল কেবল ফিচার যোগ করা—তবুও ছিল "ইন্টারনেট ভাঙবে না"—রকম দায়িত্বও পালন করা।
PHP যতটা জিতেছে তা ভাষার সৌন্দর্যের কারণে নয়—এটি জিতেছে কারণ এটি কার্যকরী ওয়েব পেজ বানানোকে তাত্ক্ষণিক করে তুলেছিল।
প্রাথমিক ওয়েব ডেভেলপারদের (প্রায়ই ডিজাইনার, হবি ডেভেলপার, বা ছোট ব্যবসা) জন্য PHP সময়-থেকে-প্রথম-চালু-করা ব্যাপারে অন্যান্য বিকল্পের থেকে বাধা কমিয়েছিল।
PHP-এ ফিডব্যাক লুপ প্রায় ঘর্ষণহীন ছিল: একটি ফাইল আপলোড করলেই, পেজ রিফ্রেশ করলেই ফল দেখা যেত। এটা সাধারণ বলে মনে হতে পারে, কিন্তু এক প্রজন্মের ওয়েব নির্মাণকে এইভাবেই গড়ে তুলেছিল।
মানুষ একটি ডাইনামিক পেজ দিয়ে (কন্ট্যাক্ট ফর্ম, গেস্টবুক, কাউন্টার) শুরু করে বড়ো করত।
শুরুতে ওয়েব প্রজেক্টে বড়ো ইঞ্জিনিয়ারিং দল ছিল না। সাধারণত একজন বা দুজন ডেভেলপার থাকত এবং অনেক জরুরী চাহিদা।
PHP সেই বাস্তবতার সঙ্গে মানানসই: ডেপ্লয়মেন্টের আনুষ্ঠানিকতা কমায় এবং ইনক্রিমেন্টাল পরিবর্তন দ্রুত পাঠানো সহজ করে।
PHP শেয়ার্ড হোস্টিংয়ের ঢেউয়ে সাঁতরে উঠল। অনেক প্রদানকারী PHP প্রি-ইনস্টল করে দিত—অর্থাৎ আলাদা ইনফ্রাস্ট্রাকচার বা দামী সার্ভারের দরকার পড়েনি।
ডেপ্লয়মেন্ট প্রায়ই ছিল “ফাইল কপি করে দিন,” যা মানুষের HTML প্রকাশের পূর্বের কাজের রীতির সঙ্গে মিলে যায়।
PHP গ্রহণ বাড়ার সাথে টিউটোরিয়াল, স্নিপেট, ফোরাম ও কপি-পেস্ট উদাহরণও Everywhere হয়ে গেল।
এই কমিউনিটি মেমোরি PHP-কে পছন্দসই করে তুললো—এমনকি যখন অন্তর্নিহিত ওয়েব সমস্যা জটিল ছিল।
PHP কেবল সহজ হওয়ায় সফল হয়নি—এটি সফল হয়েছিল কারণ এর একটি ডিফল্ট “বাড়ি” ছিল।
সেই বাড়ি ছিল LAMP স্ট্যাক: Linux + Apache + MySQL + PHP। বছরব্যাপী এই কম্বোটি ডাইনামিক ওয়েবসাইট চালানোর স্ট্যান্ডার্ড ছিল, বিশেষত ছোট ব্যবসা ও ব্যক্তিগত প্রকল্পে।
Linux ও Apache সহজে পাওয়া ও সস্তা চালানো যায়। PHP Apache-র রিকোয়েস্ট/রেসপনস মডেলে সুন্দরভাবে ফিট করত: ভিজিটর URL এ ঢুকলেই Apache রিকোয়েস্ট PHP-কে দেয়, এবং PHP অন-ফ্লাই HTML জেনারেট করে।
অলাদা অ্যাপ্লিকেশন সার্ভার ব্যবস্থাপনা করতে হয়নি, ফলে ডেপ্লয়মেন্ট সাদাসিধে ও সস্তা ছিল।
MySQL এই ছবিটাকে পূর্ণ করলো। PHP-র বিল্ট-ইন ডাটাবেস এক্সটেনশনগুলো MySQL-এ সংযোগ, কোরি চালানো ও রিজাল্ট রেন্ডার করা সহজ করে দিল।
এই শক্তিশালী একত্রীকরণ মানে ছিল—এক বড় অংশ ডাটাবেস-চালিত সাইট একই পরিচিত টুল দিয়ে তৈরি করা যায়।
একটি বড় ত্বরক ছিল শেয়ার্ড হোস্টিং। অনেক হোস্ট অ্যাকাউন্ট অফার করত যেখানে PHP ও MySQL আগেই কনফিগার করা থাকে—কোনো সিস্টেম অ্যাডমিন দরকার পড়ত না।
cPanel-এর মতো কন্ট্রোল প্যানেল দিয়ে ব্যবহারকারীরা MySQL ডাটাবেস তৈরি, phpMyAdmin-এ টেবিল ম্যানেজ, FTP-র মাধ্যমে PHP ফাইল আপলোড করে দ্রুত লাইভ হতে পারত।
তারপর এলো ওয়ান-ক্লিক ইনস্টলার (প্রায়ই WordPress, ফোরাম, শপিং কার্টের জন্য)। এই ইনস্টলারগুলো “একটি ওয়েবসাইট হলো একটি PHP অ্যাপ + একটি MySQL ডাটাবেস” ধারণাকে স্বাভাবিক করে দিলো, যার ফলে লক্ষ লক্ষ সাইট মালিকের জন্য PHP ছিল সবচেয়ে অল্প-প্রতারণার পথ।
স্ট্যাকটি একটি ব্যবহারিক ওয়ার্কফ্লো উৎসাহিত করলো: .php ফাইল এডিট করো, ব্রাউজার রিফ্রেশ করো, SQL টুইক করো, পুনরাবৃত্তি।
এটি টেমপ্লেট ও ইনক্লুডস, ফর্ম হ্যান্ডলিং, সেশন, CRUD পেজ—এই পরিচিত প্যাটার্নগুলোকে ঘড়ে তুললো, যা LAMP-র শিখরের পরে বহুৎ বছর ধরে থমথমে কাজ করেছে।
PHP কেবল সিনট্যাক্সের কারণেই “প্রত্যেকে” নয়—এটি ডিফল্ট পছন্দ হয়ে উঠল কারণ সম্পূর্ণ ইনস্টলেবল পণ্যগুলো এর চারপাশে তৈরি হলো—যা বাস্তব ব্যবসায়িক সমস্যাগুলো খুব কম সেটআপে সমাধান করত।
কন্টেন্ট ম্যানেজমেন্ট সিস্টেমগুলো PHP-কে এক-ক্লিক সিদ্ধান্ত করে দিল। WordPress, Drupal, Joomla-র মতো প্ল্যাটফর্মগুলো অ্যাডমিন প্যানেল, লগইন, পারমিশন্স, থিম, প্লাগইন—সব জটিলতা বয়েছে, ফলে সাইট মালিক কোড না লিখেই কন্টেন্ট পাবলিশ করতে পারছিল।
প্রতিটি CMS তার নিজের গ্র্যাভিটি তৈরি করলো: ডিজাইনাররা থিম তৈরি শিখল, এজেন্সি রেপিটেবল অফার বানালো, এবং প্লাগইন মার্কেটপ্লেস বেড়েছিল।
একবার ক্লায়েন্টের সাইট সেই ইকোসিস্টেমের ওপর নির্ভরশীল হয়ে গেলে, PHP প্রায়ই বারবার “নির্বাচিত” হত—কখনও কখনও ক্লায়েন্ট নিজেই জানত না।
অনলাইন স্টোর ও কমিউনিটি সাইট প্রাথমিক থেকেই জরুরি ছিল, এবং PHP শেয়ার্ড-হোস্টিং বাস্তবতার সঙ্গে ভাল মিশে গিয়েছিল।
Magento (এবং পরে WordPress-এ WooCommerce) সহ সফটওয়্যার এবং phpBB-এর মতো ফোরাম অ্যাপ ইন্টারপ্রেটেড কেটালগ, কার্ট, অ্যাকাউন্ট, ও মডারেশন—এগুলো মানুষকে প্রায়ই রিপিটেবল সমাধান হিসেবে পৌঁছে দিল।
এই প্রকল্পগুলোও একটি ওয়ার্কফ্লো স্বাভাবিক করে দিল: অ্যাপ ইন্সটল করো, ব্রাউজারে কনফিগার করো, মডিউল দিয়ে বাড়াও—এই রকম ডেভেলপমেন্ট PHP-কে টিকে থাকতে সাহায্য করেছে।
সব PHP পাবলিক-মুখী নয়। অনেক দল এটি ইন্টারনাল ড্যাশবোর্ড, অ্যাডমিন টুল, এবং সরল API-র জন্য ব্যবহার করে যা পেমেন্ট, ইনভেন্টরি, CRM অথবা অ্যানালিটিক্সের সাথে সংযুক্ত।
এই সিস্টেমগুলো “কোন CMS” স্ক্যান-এ ধরায় না, কিন্তু তারা PHP-কে দৈনন্দিন কাজে রেখেই দেয়।
যখন ওয়েবের বড় অংশ কয়েকটি বিশাল প্রোডাক্টে চলে (বিশেষত WordPress), তখন তার উপরে থাকা ভাষাটাই সেই পরিধি উত্তরাধিকার পায়।
PHP-র পৌঁছানোটার একটি বড় অংশ হলো তার ওপর নির্মিত ইকোসিস্টেমের পৌঁছানো—কেবল ভাষার নিজ গুণমান নয়।
PHP-র সাফল্য সবসময়ই বাস্তব-চলন্ততার উপর নির্ভরশীল ছিল—আর বাস্তবতা প্রায়ই কিছু খসখসে অংশ রেখে দেয়।
অনেক সমালোচনা বাস্তব ইতিহাসের উপর ভিত্তি করে, কিন্তু সবগুলোই আধুনিক PHP-এ প্রযোজ্য নয়।
একটি সাধারণ অভিযোগ হলো ইনকনসিস্টেন্সি: ফাংশন নামের প্যাটার্ন ভিন্নভিন্ন হওয়া, প্যারামিটার সাজানো আলাদা হওয়া, এবং পুরোনো API নতুন API-র পাশে থাকায় বিভ্রান্তি।
এটা কাল্পনিক নয়—PHP দ্রুত বেড়ে উঠেছে, ওয়েব বদলেছে, এবং পুরোনো ইন্টারফেসগুলো লক্ষ কোটিতে চলমান সাইটের জন্য কাজ চালিয়ে রাখতে রাখা হয়েছে।
PHP একাধিক প্রোগ্রামিং স্টাইল সমর্থন করে। আপনি সহজ “জাস্ট-গেট-ইট-ডান” স্ক্রিপ্ট লিখতে পারেন, অথবা আরও সংগঠিত, অবজেক্ট-ওরিয়েন্টেড কোডও লিখতে পারেন।
সমালোচকরা এটাকে “মিশ্র প্যারাডাইম” বলেন; সমর্থকরা এটাকে নমনীয়তা বলে মনে করেন। বাধা হলো দলগুলো স্ট্যান্ডার্ড না রাখলে কোড কোয়ালিটি অসম হতে পারে।
“PHP অনসিকিউর” বলা অতিরিক্ত সহজীকরণ। বেশিরভাগ PHP নিরাপত্তার ঘটনা অ্যাপ্লিকেশনগত ভুল থেকে আসে: ইউজার ইনপুটে অবিশ্বাস করা, স্ট্রিং কনক্যাটেনেশনের মাধ্যমে SQL কুয়েরি তৈরি করা, ফাইল আপলোড ভুল কনফিগার করা, বা এক্সেস চেক ভুলে যাওয়া।
PHP-র ঐতিহাসিক ডিফল্টগুলো সবসময় শিক্ষানবিসদের নিরাপদ রুট দেখায়নি, এবং সহজ হওয়ার কারণে অনেক শিক্ষানবিস পাবলিক-ফেসিং কোড ডেপ্লয় করেছেন।
সঠিক দৃষ্টিকোণ হলো: PHP ওয়েব অ্যাপ বানাতে সহজ করে দেয়, আর ওয়েব অ্যাপ ভুল করা সহজ যদি নিরাপদ অভ্যাস না মেনে চালানো হয়।
PHP-র উপর একটি বড় দায়িত্ব পড়েছে: ইন্টারনেট ভাঙ্গবে না।
এই ব্যাকওয়ার্ড কম্প্যাটিবিলিটি দীর্ঘমেয়াদী অ্যাপকে চলমান রাখে, কিন্তু লেগ্যাসি কোডও অদ্ভুতভাবে টিকে যায়—কখনও কখনও তার সেরা সময় পার হয়ে গেলেও। কোম্পানিগুলো পুরোনো প্যাটার্ন রক্ষণাবেক্ষণে বেশি সময় ব্যয় করে নতুন কিছু গ্রহণের বদলে।
ন্যায্য সমালোচনা: অসঙ্গতি, লেগ্যাসি API, ও অনিয়মিত কোডবেস বাস্তবে আছে।
প্রাচীনকালীন সমালোচনা: আধুনিক PHP প্রজেক্টগুলোকে মনে করা যে সেগুলো অবশ্যই ২০০০-এর দশকের শৈলীর হুবহু অনুকরণ করবে, বা ভাষাটাই প্রধান নিরাপত্তা দুর্বলতা—এগুলো ভুল।
বাস্তবে পার্থক্য সাধারণত টিমের অনুশীলনের উপর নির্ভর করে, টুলের নয়।
PHP-র প্রতিচ্ছবি প্রায়ই সেই কোডের সঙ্গে জড়িয়ে থাকে যা বছরগুলো আগে লেখা—HTML ও লজিক একটি ফাইলে মিশে থাকা, অগোছালো স্টাইল, এবং “আমার সার্ভারে চলে” ডেপ্লয় আচার-ব্যবহার।
PHP 7 ও 8+ কেবল ফিচার যোগ করেনি—এগুলি ইকোসিস্টেমকে পরিষ্কার, দ্রুত ও রক্ষণযোগ্য কাজের সাইডে ঠেলে দিয়েছে।
PHP 7 কোর ইন্টারনালগুলো পুনরায় ডিজাইন করে বড় পারফরম্যান্স উন্নতি এনেছিল (Zend Engine আপডেট)।
সহজভাবে: একই অ্যাপ একই হার্ডওয়্যারে বেশি রিকোয়েস্ট হ্যান্ডেল করতে পারত, বা একই ট্রাফিকে কম খরচে চালানো যেত।
এটি শেয়ার্ড হোস্টিং, ব্যস্ত WordPress সাইট, এবং এমন ব্যবসার জন্য গুরুত্বপূর্ণ ছিল যারা লোড-টাইমকে বিক্রি-ক্ষতির সাথে মাপেন। এটি PHP-কে নতুন সার্ভার-সাইড অপশনের বিরুদ্ধে প্রতিযোগী করে তুলল।
PHP 8 এমন ফিচার এনেছে যা বড় কোডবেসকে বোঝা সহজ করে:
int|string)—এতে অনুমান কমে এবং টুলিং উন্নত হয়।আধুনিক PHP প্রজেক্টগুলো সাধারণত Composer-এর উপর নির্ভর করে—স্ট্যান্ডার্ড ডিপেনডেন্সি ম্যানেজার।
লিব্রেরি হ্যান্ড-কপি করার বদলে, দলগুলো একটি ফাইলে ডিপেনডেন্সি ঘোষণা করে, নির্দিষ্ট ভার্সন ইনস্টল করে, এবং অটোলোডিং ব্যবহার করে। এটিই কারণ যে আধুনিক PHP অনেকটাই “পেশাদার” মনে হয় পুরনো কপি-পেস্ট যুগের তুলনায়।
পুরনো PHP প্রায়শই ছিল অ্যাড-হক স্ক্রিপ্ট; আধুনিক PHP সাধারণত মানে ভার্সনড ডিপেনডেন্সি, ফ্রেমওয়ার্ক, টাইপেড কোড, অটোমেটেড টেস্টিং, এবং বাস্তব ট্রাফিকে সহনীয় পারফরম্যান্স।
PHP নস্টালজিয়ার ভিত্তিতে বেছে নেবার বিষয় নয়—এটি একটি ব্যবহারিক টুল যা এখনও অনেক ওয়েব কাজের জন্য অত্যন্ত উপযোগী।
মুখ্য বিষয় হলো আপনার বাধ্যবাধকতার সাথে মিলানো, আদর্শের সাথে নয়।
PHP উজ্জ্বল যখন আপনি বানাচ্ছেন বা চালাচ্ছেন:
আপনার প্রজেক্ট যদি “অনেক ডেভেলপার ইতিমধ্যেই জানে” এবং “হোস্টিং সর্বত্র” থেকে লাভ করে, তাহলে PHP ঘর্ষণ কমাতে পারে।
বিকল্প বিবেচনা করুন যদি আপনার দরকার:
এছাড়া, যখন আপনি নতুন পণ্য তৈরি করছেন এবং আধুনিক আর্কিটেকচারের জন্য শক্ত ডিফল্ট চান (টাইপড API, স্ট্রাকচার্ড সার্ভিস, পরিষ্কার কনসার্ন সেপারেশন), তখন অন্য স্ট্যাক বিবেচ্য হতে পারে।
PHP-র উৎপত্তি কাহিনীর এক পাঠ সবসময় শক্তিশালী: জিতেছে এমন টুলগুলো ধারণা থেকে কাজ করা সফটওয়্যার পর্যন্ত ঝামেলা কমায়।
আপনি যদি মূল্যায়ন করছেন PHP-এ বিনিয়োগ চালিয়ে যাবেন কিনা বা একটি নতুন সার্ভিস তৈরি করবেন (উদাহরণ: React ফ্রন্টএন্ড + Go API), তাহলে একটি দ্রুত প্রোটোটাইপ অনেক সন্দেহ দূর করতে পারে। Koder.ai-এর মতো প্ল্যাটফর্মগুলো সেই “শিপ-ফার্স্ট” ওয়ার্কফ্লো-এর জন্য তৈরি: চ্যাটে অ্যাপটা বর্ণনা করে একটি কাজ করা ওয়েব বা ব্যাকএন্ড প্রজেক্ট (React + Go with PostgreSQL) জেনারেট করা যায়, তারপর দ্রুত পুনরাবৃত্তি করে যখন প্রস্তুত তখন সোর্স কোড এক্সপোর্ট করা যায়।
আরও ব্যবহারিক গাইডের জন্য /blog ব্রাউজ করুন। ডেপ্লয়মেন্ট বা সার্ভিস অপশন তুলনা করতে /pricing দেখতে পারেন।
রাসমুস লারদর্ফ তার ব্যক্তিগত সাইট পরিচালনার জন্য ছোট সি-ভিত্তিক ইউটিলিটি তৈরি করেছিলেন—ভিজিটর ট্র্যাক করা, পাতার অংশগুলো পুনঃব্যবহার করা, এবং সহজ ডাইনামিক আউটপুট হ্যান্ডল করা।
লক্ষ্য ছিল বারবারের জটিল কাজগুলো অপসারণ করা; তাই PHP–এর ধারা ছিল ব্যবহারিক: দ্রুত ডিপ্লয় করা যায়, HTML-এ সহজে এমবেড করা যায়, এবং ওয়েব-ফোকাসড হেল্পার দিয়ে পূর্ণ।
১৯৯০-এর দশকের মাঝামাঝি সময়ে বেশিরভাগ পেজই স্ট্যাটিক HTML ছিল। ফর্ম, কাউন্টার, বা ভিজিটর-ভিত্তিক কনটেন্টের মতো ডাইনামিক কাজ করার জন্য সাধারণত CGI স্ক্রিপ্ট—প্রায়ই Perl—ই ব্যবহার করা হতো।
কিন্তু সেটি দৈনন্দিন সাইট আপডেটের জন্য ঝামেলা ছিল, কারণ সাধারণত আলাদা একটি প্রোগ্রাম লিখে HTML প্রিন্ট করতে হতো, HTML ফাইলে সামান্য সার্ভার-লজিক যোগ করা হয়নি।
CGI প্রোগ্রামগুলো প্রতিটি রিকোয়েস্টে আলাদা প্রসেস হিসেবে চলত, এবং সেটআপ (পারমিশন, সার্ভার কনফিগ) বেশি দরকার হতো—আর মেন্টাল মডেলও আলাদা ছিল।
PHP ডাইনামিক আউটপুটকে “ওয়েব পেজ এডিট করা”র কাছাকাছি এনে দিল: HTML লেখুন, সামান্য সার্ভার-সাইড স্নিপেট যোগ করুন, আপলোড করুন, রিফ্রেশ করুন।
PHP/FI-এর পূর্ণ নাম ছিল “Personal Home Page / Forms Interpreter.” এটি প্রাথমিক পাবলিক রিলিজ যা ডাইনামিক পেজ তৈরি এবং ফর্ম প্রসেসিংকে কেন্দ্রেই রাখে।
এর শক্তিশালী ধারণা ছিল: সার্ভার-সাইড কোড পেজে এমবেড করা যায় এবং সাধারণ ওয়েব টাস্কের জন্য বিল্ট-ইন সুবিধা দেয়া আছে (বিশেষত ফর্ম ও মৌলিক ডেটাবেস অ্যাকসেস)।
এটি অ-স্পেশালিস্টদের জন্য বাধা কমিয়েছিল: HTML-কে মূল ডকুমেন্ট হিসেবে রেখে ছোট ছোট ডাইনামিক অংশ জুড়তে পারলে (নাম আউটপুট করা বা রেজাল্ট লুপ করা) কাজটি সহজ হলো।
এই পন্থা শেয়ার্ড হোস্টিংয়ের বাস্তবতার সঙ্গে খাপ খেতে পারত—ধাপে ধাপে সাইট তৈরি করার জন্য—কোনো আলাদা টেমপ্লেটিং সিস্টেম নিতে হয়নি।
PHP পাবলিক হওয়ার সাথে সাথেই অন্যান্য ডেভেলপাররা ফিক্স, ছোট ফিচার, ও ইন্টিগ্রেশনের প্রস্তাব পাঠাতে শুরু করলেন।
এই প্রতিক্রিয়া লুপের ফলে PHP এক ব্যক্তির টুলবক্স থেকে একটি ইকোসিস্টেম-চালিত প্রজেক্টে রূপ নিল—যেখানে ডাটাবেস, এক্সটেনশন ও পোর্টাবিলিটির মতো বাস্তবসম্মত ওয়েব-মাস্টারের চাহিদা ভাষার দিশা নির্ধারণ করল।
PHP 3 ছিল একটি বড় রিরাইট যা কোর ইঞ্জিনকে বদলে দিল—এই সংস্করণেই নাম বদলে “PHP: Hypertext Preprocessor” করা হয়েছিল।
করপাসটি আরও কনসিস্টেন্ট ও এক্সটেন্ডেবল হয়ে উঠার ফলে PHP আর কেবল একরকম স্ক্রিপ্টের সমষ্টি নয়—এটি একটি স্থিতিশীল, বাড়ানো যায় এমন প্ল্যাটফর্মে রূপ নিল।
Zend Engine (Andi Gutmans ও Zeev Suraski দ্বারা প্রতিষ্ঠিত) PHP-র রানটাইম ইন্টারনালকে উন্নত করেছিল—ভিত্তি করে বেশি সংগঠিত কোর, দ্রুত এক্সিকিউশন, এবং এক্সটেনশনের জন্য পরিষ্কার পথ।
এই পরিবর্তনগুলো হোস্টিং প্রদানকারীদের PHP-কে ব্যাপকভাবে ও সস্তায় অফার করতে সাহায্য করে, এবং বড় কোডবেস পরিচালনা করা সহজ করে তুলল।
LAMP (Linux, Apache, MySQL, PHP) ছোট ব্যবসা এবং ব্যক্তিগত প্রজেক্টে ডায়নামিক সাইট চালানোর একটি ডিফল্ট রেসিপি হয়ে উঠলো।
Linux ও Apache সহজে পাওয়া যায়, এবং PHP Apache-র রিকোয়েস্ট/রেসপন্স মডেলের সঙ্গে সুন্দরভাবে মেলে—রেকোয়েস্ট এলে Apache PHP-কে ডিলে করে, PHP অন-ফ্লাই HTML জেনারেট করে। MySQL-এ সংযোগ করতে PHP-র বিল্ট-ইন ফাংশনগুলো কাজকে সরল করে তুললো।
আধুনিক PHP (7 ও 8+) বড় পারফরম্যান্স উন্নতি এনেছে এবং বড় কোডবেসগুলোর জন্য রক্ষণযোগ্যতা বাড়িয়েছে, আর Composer ডিপেনডেন্সি ম্যানেজমেন্টে স্ট্যান্ডার্ড এনেছে।
কিন্তু সিদ্ধান্ত নেওয়ার সময় আপনার বাধ্যবাধকতাগুলো বিবেচনা করতে বলছি: আপনি কি WordPress/Drupal/Magento ইকোসিস্টেমে কাজ করবেন? হোস্টিং কি সহজ ও সস্তা হতে হবে? আপনি কি নিরাপত্তা বজায় রাখতে সক্ষম? বিদ্যমান PHP সিস্টেম বাড়ানোর চেয়ে রিরাইট সাধারণত ব্যয়বহুল।