مشکل واقعی WordPress خودمدیریتشده
یک سایت تولیدی WordPress هرگز فقط WordPress نیست. به یک دیتابیس، یک object cache، یک page cache، یک خط پردازش تصویر، گواهیهای TLS، DNS و یک فایروال نیاز دارد — و روی میزبانی اشتراکی هرکدام یک پلاگین، یک افزونه پولی یا سرویسی است که خودتان به هم میچسبانید. ناسازگاری نسخه میان runtime از نوع PHP، سرور MySQL و یک پلاگین caching منبع همیشگی صفحههای سفید است. cdn.com.tr آن وصلهپینه را با یک استک مدیریتشده جایگزین میکند که در آن runtime، دیتابیس، Redis و edge از پیش سازگار و با هم تأمین شدهاند.
object cache از نوع Redis که واقعاً بار دیتابیس را کم میکند
بیشتر کندی WordPress زیر بار، ناشی از کوئریهای تکراری و یکسان دیتابیس برای option ها، منوها و متادیتای نوشتههاست. افزونه مدیریتشده Redis بهعنوان یک drop-in برای object cache وردپرس وصل میشود، بنابراین آن کوئریها از حافظه پاسخ داده میشوند نه از MySQL. برای سایتهای WooCommerce و عضویتی که صفحات شخصیسازیشدهاند و نمیتوان آنها را کاملاً page-cache کرد، همین است که سبد خرید و صفحات حساب کاربری را سریع نگه میدارد. چون Redis مدیریتشده است، اعتبارنامهها بهجای نشستن در یک صفحه تنظیمات پلاگین، به runtime تزریق و برای شما چرخانده میشوند.
edge CDN cache و بهینهسازی تصویر بهصورت توکار
داراییهای ثابت و HTML قابلcache از edge شبکه cdn.com.tr نزدیک به بازدیدکننده ارائه میشوند، که رفتوبرگشتها به origin را کم و جهشهای ترافیک در کمپینها را جذب میکند. بهینهسازی تصویر آپلودها را به قالبهای مدرن دوباره encode و نسخههایی با اندازه مناسب ارائه میکند، که نیاز به یک پلاگین سنگین بهینهسازی که بر سر worker های PHP با سایت شما رقابت میکند را حذف میکند. قواعد cache کوکیهای ورود WordPress و سبد WooCommerce را میشناسند، بنابراین کاربران واردشده و خریداران بهدرستی از cache مشترک عبور میکنند در حالی که بازدیدکنندگان ناشناس صفحات cacheشده را میگیرند.
Auto SSL، DNS و WAF در جلوی wp-admin
پُرحملهترین URLها روی هر نصب WordPress، همان wp-login.php و xmlrpc.php هستند. چون ترافیک پیش از origin به edge شبکه cdn.com.tr میرسد، WAF الگوهای brute-force و بهرهبرداریهای رایج را پیش از رسیدن به PHP فیلتر میکند. Auto SSL بدون cron job یا certbot، HTTPS را روی هر دو apex و www معتبر نگه میدارد، و DNS در همان پنل مدیریت میشود بنابراین یک جابهجایی دامنه نیازمند دستوپنجه نرم کردن با سه داشبورد نیست.
مهاجرت یک سایت موجود بدون بازسازی
برای جابهجایی سایت لازم نیست آن را بازسازی کنید. فایلهای موجود و یک export از دیتابیس را بیاورید، آنها را روی پلتفرم مدیریتشده بازیابی کنید و پیش از تغییر DNS، روی یک URL از نوع name.cdn.com.tr راستیآزمایی کنید. دیتابیس مدیریتشده import و نگرانیهای مجموعهکاراکتر را رسیدگی میکند، Redis و edge cache پس از سالم بودن محتوا روشن میشوند، و جابهجایی دامنه در آخر انجام میشود بنابراین هیچ بازهای وجود ندارد که سایت در دسترس نباشد.
یک پنل برای آژانسهایی که سایتهای بسیار اجرا میکنند
آژانسها بیش از همه از ناهماهنگی رنج میبرند: هر سایت مشتری روی یک میزبان کمی متفاوت با پلاگینهای متفاوت برای caching و امنیت قرار میگیرد. استانداردسازی روی پلتفرم مدیریتشده WordPress یعنی همان runtime، همان مدل Redis و edge، و همان پروفایل WAF در سراسر هر پروژه. purge، لاگها و وضعیت deploy بهازای هر سایت در همان حساب قابلمشاهدهاند، بنابراین سپردن یک سایت به عضو دیگر تیم به معنای یادگیری مجدد یک راهاندازی سفارشی نیست.
راهنمای گامبهگام deploy
اپلیکیشن WordPress را بسازید
در پنل بخش Platform را باز کنید، WordPress را انتخاب کنید و runtime از نوع PHP 8 و اندازه پلن را برگزینید. پلتفرم runtime، یک volume پایدار برای wp-content و یک دیتابیس مدیریتشده MySQL را تأمین میکند، بنابراین هرگز ثابتهای دیتابیس wp-config.php را دستی ویرایش نمیکنید — آنها برای شما تزریق میشوند.
دامنه را متصل و SSL صادر کنید
دامنه را به cdn.com.tr اشاره دهید، یا برای آزمایش اولیه آن را بهعنوان یک زیردامنه name.cdn.com.tr اضافه کنید. Auto SSL گواهی را صادر و تمدید میکند، و هر دو apex و www جداگانه تأیید میشوند تا یک حلقه هدایت نتواند یکی از انواع را بدون پوشش رها کند.
object cache از نوع Redis را روشن کنید
افزونه مدیریتشده Redis را فعال کنید و drop-in مربوط به object-cache را از پنل قرار دهید. آنگاه WordPress نتایج پرهزینه کوئریها، option ها و transient ها را بهجای کوبیدن MySQL در هر درخواست، در Redis ذخیره میکند، که بزرگترین دستاورد برای ترافیک کاربران واردشده و WooCommerce است.
edge CDN cache و بهینهسازی تصویر را فعال کنید
سایت را از مسیر edge منتشر کنید تا فایلهای ثابت — تصاویر، CSS، JS، فونتها — از cache نزدیک به بازدیدکننده ارائه شوند. بهینهسازی تصویر، رسانه را در لحظه دوباره encode و متناسبسازی میکند، بنابراین به یک پلاگین بهینهسازی جداگانه که wp-admin را کند میکند نیاز ندارید.
قواعد WAF و purge را تنظیم کنید
پروفایل WAF را در جلوی wp-login.php، xmlrpc.php و wp-admin اعمال کنید و قواعد bypass کردن cache را برای کوکیهای کاربران واردشده و سبد خرید تنظیم کنید. purge خودکار را طوری پیکربندی کنید که انتشار یک نوشته یا بهروزرسانی یک محصول، edge cache مربوط را بدون یک flush دستی پاک کند.
نمونه سناریوها
یک سایت خبری یا وبلاگ، جهشهای کمپین را با edge page cache جذب میکند در حالی که Redis داشبورد تحریریه را پاسخگو نگه میدارد.
صفحات محصول و دستهبندی در edge cache میشوند، سبد خرید و checkout بهدرستی از cache عبور میکنند، و Redis صفحات شخصیسازیشده را زیر بار سریع نگه میدارد.
دهها سایت مشتری روی یک استک استانداردشده با همان مدل SSL، WAF و caching اجرا میشوند، که از یک حساب واحد مدیریت میگردد.
پرسشهای پرتکرار
آیا object cache از نوع Redis پلاگینهای page caching که پیشتر استفاده میکنم را خراب میکند؟
object cache از نوع Redis و edge page cache مسائل متفاوتی را حل میکنند و با هم کار میکنند. object cache نتایج دیتابیس را از حافظه برای صفحات غیرقابلcache و واردشده ارائه میدهد؛ edge cache کل پاسخهای ثابت را برای بازدیدکنندگان ناشناس ارائه میکند. معمولاً میتوانید یک لایه page-cache مبتنی بر پلاگین را پس از رسیدگی edge کنار بگذارید و object cache مدیریتشده Redis را برای بخشهای پویا نگه دارید.
چگونه checkout در WooCommerce از cache مشترک بیرون نگه داشته میشود؟
قواعد cache کوکیهای WordPress و WooCommerce — کوکی ورود و کوکیهای سبد/نشست — را تشخیص میدهند و برای آن درخواستها از edge cache عبور میکنند، بنابراین هیچ مشتریای هرگز سبد خرید مشتری دیگر را نمیبیند. صفحات محصول و دستهبندی ناشناس cacheشده میمانند، که همانجایی است که ترافیک و دستاورد سرعت واقعاً هست.
آیا هنوز به Wordfence، یک پلاگین caching و یک پلاگین تصویر نیاز دارم؟
این استک کاری را که آن پلاگینها معمولاً انجام میدهند پوشش میدهد: WAF جای فایروال یک پلاگین امنیتی را در جلوی wp-admin میگیرد، edge و Redis جای پلاگینهای caching را میگیرند، و بهینهسازی تصویر توکار جای یک پلاگین تصویر را. حذف آنها worker های PHP را آزاد میکند، چون آن پلاگینها در غیر این صورت داخل هر درخواست اجرا میشوند.
آیا انتشار یک نوشته، CDN cache را بهصورت خودکار پاک میکند؟
بله. purge خودکار به رویدادهای محتوا گره خورده است، بنابراین انتشار یا بهروزرسانی یک نوشته، صفحه یا محصول، ورودیهای edge cache مربوط را پاک میکند. همچنین میتوانید برای تغییرات موردی مانند یک ویرایش قالب یا یک تصویر اصلاحشده، بهصورت دستی از پنل purge کنید.
آیا میتوانم نسخه PHP و پلاگینهای فعلی خود را در طول مهاجرت نگه دارم؟
شما به runtime مدیریتشده PHP 8 مهاجرت میکنید؛ بیشتر قالبها و پلاگینهای نگهداریشده بدون تغییر روی PHP 8 اجرا میشوند. سایت را روی یک URL موقت name.cdn.com.tr پیش از تغییر DNS راستیآزمایی میکنید، بنابراین هر پلاگینی که به بهروزرسانی نیاز دارد پیش از دیده شدن توسط بازدیدکنندگان واقعی شناسایی میشود.
چه بر سر اعتبارنامههای دیتابیس در wp-config.php میآید؟
اتصال دیتابیس مدیریتشده به runtime تزریق میشود، بنابراین host، name، user یا password دیتابیس را دستی در wp-config.php نمیچسبانید. اعتبارنامهها را میتوان بدون ویرایش فایل از پنل چرخاند، که امنتر از ذخیره آنها بهصورت متن ساده در مخزن یا روی دیسک است.