Optistream دوازده پلاگین سفارشی وردپرس را بدون از دست دادن سئو برای هیچ‌یک از هزار صفحه عمومی خود، در یک کد‌بیس واحد ادغام کرد.

چرا این ادغام اهمیت داشت

یک سایت وردپرسی معمولی در نهایت با تعدادی پلاگین روبرو می‌شود؛ اما یک سایت بزرگ‌تر شبیه به کارگاهی پر از سیم است که هر کدام در حال کار هستند اما جدا کردن هیچ‌کدام از آن‌ها آسان نیست. سایت Optistream از دوازده پلاگین اختصاصی برای مدیریت پروفایل استریمرها، تیم‌های ورزش‌های الکترونیک (esports) و داده‌های بازی استفاده می‌کرد. این پلاگین‌ها هزار صفحه قابل ایندکس ایجاد می‌کردند. حفظ سلامت این URLها غیرقابل مذاکره بود؛ هرگونه تغییر می‌توانست فرآیند مهاجرت را با شکست مواجه کند.

ساختار قدیمی چگونه بود

هر یک از دوازده پلاگین در پوشه مخصوص به خود قرار داشت، نوع پست سفارشی (custom post type) خود را ثبت می‌کرد و در نقاط مختلفی به وردپرس متصل (hook) می‌شد. مشکلات یکی پس از دیگری از راه می‌رسیدند:

  • هوک‌ها (Hooks) و دارایی‌ها (assets) پراکنده بودند و پیش‌بینی اینکه چه کدی در چه زمانی اجرا می‌شود را دشوار می‌کردند.
  • منطق مسیریابی (Routing) در فایل‌های مجزای زیادی قرار داشت، بنابراین یک URL واحد می‌توانست تحت تأثیر چندین پلاگین قرار بگیرد.
  • فایل‌های CSS با ترتیبی غیرقابل پیش‌بینی بارگذاری می‌شدند که منجر به تداخل در استایل‌ها می‌شد.
  • عیب‌یابی (Debugging) مستلزم باز کردن دوازده دایرکتوری مختلف بود که زمان زیادی از هر توسعه‌دهنده‌ای می‌گرفت.

هدف کاهش تعداد فایل‌ها نبود؛ بلکه هدف این بود که به کل سیستم یک چرخه حیات (lifecycle) واحد و یک مکان واحد برای مدیریت وابستگی‌ها (dependencies) داده شود.

برنامه‌ریزی برای مهاجرت

تیم پروژه با رابط کاربری عمومی (شامل URLها، قالب‌ها و متادیتاها) مانند قراردادی برخورد کرد که نباید نقض می‌شد. هر تغییری در سمت کاربر (front end) به معنای شکست پروژه بود. با در نظر گرفتن این قاعده، آن‌ها چک‌لیستی را برای اجرا پس از هر مرحله تهیه کردند.

۱. فهرست کردن قراردادهای عمومی

هر مسیر URL به همراه نوع پست، اسلاگ بازنویسی (rewrite slug)، فایل قالب و کلیدهای متایی (meta keys) که به آن‌ها وابسته بود، ثبت شد. این فایل اکسل به کتابچه قوانین تبدیل شد: اگر پس از جابه‌جایی یک ماژول، URL تغییر می‌کرد، فرآیند مهاجرت به حالت قبل بازمی‌گشت (rollback).

۲. ساخت یک لودر ساده

یک فایل bootstrap بسیار کوچک ساخته شد. هر پلاگین سابق اکنون یک "content domain" واحد را از طریق یک نام تابع قابل پیش‌بینی ثبت می‌کند. این لودر کار پیچیده‌ای انجام نمی‌دهد؛ فقط به اندازه‌ای عمل می‌کند که ماژول صحیح را در صورت نیاز به وردپرس فراخوانی کند. سادگی باعث می‌شود شکست‌ها به وضوح قابل تشخیص باشند.

۳. محافظت از داده‌ها

تغییر نام کلیدهای متا، تغییر کد را به یک مهاجرت داده تبدیل می‌کرد که ریسک غیرضروری به همراه داشت. کلیدهای قدیمی دست‌نخورده باقی ماندند؛ توابع کمکی جدید آن‌ها را در بر می‌گیرند و ساختار پایگاه داده (database schema) را پایدار نگه می‌دارند.

۴. اصلاح مالکیت CSS

تداخل‌های استایل با سه اقدام حل شدند:

  • فایل‌های CSS ماژول با اولویت بالا در صف قرار می‌گیرند (enqueued) تا در آخرین مرحله بارگذاری شوند.
  • تمام انتخاب‌گرها (selectors) به یک کلاس پوشش‌دهنده (wrapper class) منحصربه‌فرد برای هر ماژول محدود (scoped) شده‌اند.
  • هنگام قرار دادن در صف، از filemtime() استفاده می‌شود تا در صورت تغییر استایل‌شیت، کش مرورگر شکسته شود (bust cache).

۵. استفاده از یک حلقه ایمن

مهاجرت ماژول به ماژول پیش رفت. پس از جابه‌جایی هر ماژول، تیم پیش از پرداختن به ماژول بعدی، ثبت نوع پست، مسیریابی و چیدمان موبایل را بررسی کرد. پلاگین‌های اصلی نصب‌شده اما غیرفعال باقی ماندند تا مسیر بازگشت فوری (instant rollback) فراهم باشد.

چک‌لیست عملیاتی

پس از تعویض هر ماژول، تیم موارد زیر را تأیید کرد:

  • هر URL مربوط به نوع محتوا، وضعیت HTTP 200 را برمی‌گرداند.
  • هدر URL اصلی (canonical) با URL اولیه مطابقت دارد.
  • عنوان صفحات و متادیسکریپشن‌ها بدون تغییر هستند.
  • تمام تصاویر بدون لینک‌های شکسته بارگذاری می‌شوند.
  • هیچ سرریز افقی (horizontal overflow) در صفحات موبایل مشاهده نمی‌شود.
  • کنسول مرورگر هیچ خطای JavaScript یا CSS نشان نمی‌دهد.

تنها زمانی که چک‌لیست با موفقیت طی شد، تیم پلاگین قدیمی را برای همیشه غیرفعال کرد.

آنچه پلاگین جدید ارائه می‌دهد

پلاگین واحد حاصل، کد‌بیس را کوچک‌تر نکرده است؛ بلکه صرفاً مرزها را شفاف کرده است. اکنون هر دوازده حوزه عملکردی، یک چرخه حیات، یک مجموعه هوک و یک مکان واحد برای مدیریت وابستگی‌ها دارند. پلاگین جدید سیستم را کوچک‌تر نکرد، بلکه مرزها را مشخص کرد. این موضوع بسیار مفیدتر از داشتن تعداد کمتری پلاگین بود.

ریسک‌ها و استدلال‌های متقابل

مورد Optistream نشان می‌دهد که یک رویکرد منضبطِ «اول-قرارداد» (contract-first) و اجرای مرحله‌به‌مرحله می‌تواند ریسک‌ها را تحت کنترل نگه دارد.

نکات بعدی برای توجه

اگر قصد انجام یک تجمیع مشابه را دارید، با این دو رکن شروع کنید:

  1. پایداری URL – پیش از نوشتن حتی یک خط کد، تمام مسیرهای عمومی را نقشه‌برداری کنید.
  2. پایداری داده‌ها – از تغییر نام فیلدهای پایگاه داده خودداری کنید، مگر اینکه برای یک مهاجرت کامل آماده باشید.

از آنجا به بعد، یک لودر بسیار کوچک بسازید، CSS را محدود (scoped) نگه دارید و ماژول‌ها را یکی یکی جابه‌جا کنید، در حالی که یک چک‌لیست عملیاتی دقیق را اجرا می‌کنید.