آموزش نگهداری دوره‌ای وردپرس؛ چک‌لیست روزانه، هفتگی و ماهانه سایت و ووکامرس
🗓 آخرین به‌روزرسانی:
نگهداری دوره‌ای وردپرس مجموعه‌ای از کارهای تکرارشونده و قابل اندازه‌گیری است که مانع تبدیل مشکلات کوچک به قطعی، نفوذ، از دست‌رفتن سفارش یا هزینه سنگین بازیابی می‌شود. سایتی که امروز بدون خطا باز می‌شود ممکن است Backup نامعتبر، افزونه آسیب‌پذیر، Cron متوقف، درگاه نیمه‌فعال، فایل دانلودی گمشده یا دیتابیس رو‌به‌رشد داشته باشد. نگهداری حرفه‌ای فقط «آپدیت‌کردن افزونه‌ها» نیست؛ باید سلامت فنی، امنیت، داده، فروش، سئو و تجربه مشتری را هم‌زمان پوشش دهد.
یک برنامه مؤثر باید برای هر کار پنج جزء داشته باشد: تناوب، مسئول، روش اجرا، شاهد انجام و معیار عبور. برای مثال «بکاپ بگیر» دستور کاملی نیست. برنامه دقیق می‌گوید بکاپ دیتابیس هر چند ساعت اجرا می‌شود، کجا ذخیره می‌شود، چه کسی شکست آن را می‌بیند، آخرین Restore موفق چه تاریخی بوده و حداکثر چه میزان داده قابل ازدست‌رفتن است.
در این راهنما، وظایف فوری، روزانه، هفتگی، ماهانه، فصلی و سالانه وردپرس و WooCommerce را به یک تقویم عملیاتی تبدیل می‌کنیم. همچنین Maintenance Window، Change Log، Backup، Update، Site Health، امنیت، Uptime، لاگ، دیتابیس، Action Scheduler، ایمیل، درگاه، محصول، سفارش، فایل دانلودی، سئو و افزونه‌های سفارشی را بررسی می‌کنیم.
وضعیت سایت فعلی: dev-source.ir روی WordPress 7.0.2، WooCommerce 10.9.4، WoodMart 8.3.7 و LiteSpeed Cache اجرا می‌شود و چند افزونه سفارشی برای محصول، PDF، Import و Checkout دارد. افزونه اختصاصی مدیریت Maintenance در فهرست افزونه‌های فعال مشاهده نشد. این مقاله یک برنامه پیشنهادی است و هیچ Update، پاک‌سازی، Backup، Cron یا تغییر تنظیماتی روی سایت زنده انجام نمی‌دهد.
نگهداری واکنشی و پیشگیرانه چه تفاوتی دارند؟
نگهداری واکنشی
پس از رخداد اقدام می‌کنید: سایت قطع شده، درگاه کار نمی‌کند، ایمیل نرسیده یا دیتابیس پر شده است. این مدل معمولاً فشار، Downtime و تصمیم‌های عجولانه ایجاد می‌کند.
نگهداری پیشگیرانه
نشانه‌های مشکل پیش از اثر بر مشتری پیدا می‌شوند: فضای دیسک هشدار می‌دهد، Backup شکست می‌خورد، Actionهای Pending افزایش می‌یابند یا افزونه قبل از منقضی‌شدن سازگاری بررسی می‌شود.
نگهداری اصلاحی
مشکلی که در پایش کشف شده به‌صورت برنامه‌ریزی‌شده رفع می‌شود؛ برای مثال اصلاح Query کند، جایگزینی افزونه رهاشده یا کاهش حجم Optionهای Autoload.
برنامه حرفه‌ای هر سه نوع را در نظر می‌گیرد، اما هدف آن کاهش سهم کارهای واکنشی است.
از چک‌لیست ثابت کورکورانه استفاده نکنید
تناوب کارها به سرعت تغییر داده و حساسیت کسب‌وکار بستگی دارد. فروشگاه روزانه با صدها سفارش به Backup و بررسی پرداخت پرتکرارتر از یک وبلاگ کم‌فعالیت نیاز دارد. معیارهای تصمیم:
- تعداد سفارش و کاربر جدید
- ارزش مالی هر ساعت قطعی
- حجم تغییر محتوا و محصول
- تعداد افزونه‌های سفارشی
- محدودیت منابع هاست
- تعهد قانونی نگهداری داده
- توان تیم برای واکنش
تقویم این مقاله نقطه شروع است؛ پس از یک ماه با داده واقعی سایت تنظیمش کنید.
سه سند پایه برای نگهداری سایت
فهرست دارایی‌ها
- دامنه و Registrar
- هاست و DNS
- WordPress، PHP و دیتابیس
- قالب، Child Theme و افزونه‌ها
- Licenseها و تاریخ انقضا
- درگاه، SMTP، CDN و سرویس‌های خارجی
- Repository و افزونه‌های سفارشی
Change Log
هر تغییر باید زمان، مسئول، هدف، Backup، نسخه قبل و بعد، نتیجه تست و Rollback داشته باشد. هنگام خطا، این سند سریع‌ترین مسیر به علت احتمالی است.
Runbook رخداد
برای قطعی، هک، شکست پرداخت، پرشدن دیسک، خطای 500 و عدم ارسال ایمیل، مراحل اقدام و مسئول مشخص باشد. Runbook نباید فقط در همان سایت ذخیره شود.
Maintenance Window چیست؟
بازه‌ای از پیش تعیین‌شده برای تغییرهای پرریسک است. در این زمان:
- Backup تازه تأیید می‌شود.
- تیم و ذی‌نفعان مطلع‌اند.
- مانیتورهای قطعی در حالت Maintenance قرار می‌گیرند، نه اینکه Log متوقف شود.
- Checkout در صورت نیاز کوتاه‌مدت محدود می‌شود.
- Rollback و Smoke Test آماده‌اند.
برای تغییر محتوای ساده Maintenance Mode لازم نیست. Update WooCommerce، PHP، قالب و دیتابیس باید در بازه کنترل‌شده انجام شوند.
وظایف دائمی و خودکار
بعضی کنترل‌ها نباید منتظر بازبینی دستی بمانند:
- Uptime و SSL Monitoring
- Backup خودکار خارج از هاست
- هشدار مصرف دیسک و منابع
- ثبت Fatal Error و Error Rate
- هشدار Failed Payment و Queue
- اسکن امنیتی و File Integrity
- گزارش شکست Jobهای زمان‌بندی‌شده
خودکارسازی بدون اعلان شکست کافی نیست. Job سبز باید شاهد قابل بررسی داشته باشد.
چک‌لیست فوری پس از هر هشدار بحرانی
- اثر روی مشتری، سفارش و داده را مشخص کنید.
- زمان شروع و Scope را ثبت نمایید.
- از وضعیت فعلی Snapshot بگیرید.
- در صورت خطر مالی، Checkout یا درگاه را کنترل کنید.
- Logهای مرتبط را حفظ نمایید.
- تغییر اخیر را بررسی کنید.
- Fix موقت و راه‌حل نهایی را جدا نگه دارید.
- پس از رفع، Smoke Test و Postmortem انجام دهید.
برای Critical Error از مقاله راهنمای رفع خطای 500 و Critical Error و برای نفوذ از پاک‌سازی وردپرس هک‌شده استفاده کنید.
وظایف روزانه وردپرس
بررسی Uptime و خطاهای بحرانی
- قطعی و Response Time غیرعادی
- خطاهای 500، 502، 503 و 504
- SSL و DNS Alert
- Fatal Error جدید
گزارش روزانه باید استثناها را نشان دهد، نه اینکه ده‌ها اعلان عادی تولید کند.
بررسی سفارش‌های WooCommerce
- سفارش‌های Failed
- Pending Payment قدیمی
- On Hold بدون پیگیری
- Refund غیرمعمول
- سفارش Completed بدون Transaction معتبر
افزایش وضعیت ناموفق نسبت به الگوی عادی می‌تواند نشانه خرابی درگاه، Callback، واحد پول یا Checkout باشد.
بررسی پرداخت و درگاه
- آخرین تراکنش موفق
- پیام‌های خطای درگاه
- Callbackهای 403 یا 500
- عدم تطبیق Transaction ID
- تغییر ناخواسته Merchant Setting
در صورت اختلاف، Order Note، WooCommerce Log و پنل پذیرنده را تطبیق دهید.
بررسی ایمیل‌های حیاتی
- New Order برای مدیر
- Processing یا Completed برای مشتری
- Reset Password
- Bounce یا SMTP Error
وضعیت Sent داخل WordPress به معنی رسیدن به Inbox نیست. لاگ SMTP و Bounce اهمیت دارد.
کنترل آخرین Backup
فقط تاریخ فایل را نبینید. نتیجه Job، حجم، مقصد و وجود دیتابیس و فایل‌ها را بررسی کنید. نسخه صفر بایت یا Backup ذخیره‌شده روی همان دیسک، پوشش واقعی ایجاد نمی‌کند.
بررسی هشدار امنیتی
- ورود مدیر از IP یا دستگاه جدید
- تلاش ورود پرتکرار
- ساخت Administrator
- تغییر Application Password
- تغییر فایل حساس
وظایف روزانه مخصوص فروش فایل
- یک لینک دانلود اخیر را کنترل کنید.
- خطاهای 403 و 404 فایل را بررسی نمایید.
- فایل اصلی PDF یا محصول گمشده نباشد.
- مجوز دانلود سفارش Completed برقرار باشد.
- دانلود بسیار غیرعادی از یک سفارش بررسی شود.
فایل دانلودی در دیتابیس و فایل‌سیستم وابستگی مشترک دارد؛ سالم‌بودن محصول به‌تنهایی کافی نیست.
وظایف هفتگی وردپرس
بررسی Dashboard Updates
هسته، قالب، افزونه و ترجمه‌های معوق را فهرست کنید. هر Update را فوراً و بدون تست نصب نکنید؛ تغییر امنیتی فوری با Update قابلیت بزرگ یکسان نیست.
اولویت‌بندی Update
- وصله امنیتی بحرانی: سریع و کنترل‌شده
- Bug Fix مربوط به سایت: در نزدیک‌ترین Window
- نسخه Feature بزرگ: پس از Staging
- افزونه بلااستفاده: حذف به‌جای Update بی‌هدف
فرایند کامل در مقاله به‌روزرسانی امن وردپرس توضیح داده شده است.
Site Health
Tools → Site Health را بررسی کنید:
- Critical Issueها
- Background Update
- REST API و Loopback
- PHP Version و Moduleها
- Autoloaded Options
- File Permission و HTTPS
Site Health ابزار تشخیص است و سبزبودن آن سلامت کامل فروشگاه را تضمین نمی‌کند.
WooCommerce System Status
- نسخه WordPress و WooCommerce
- PHP Memory
- Database Version
- HPOS و Compatibility
- Template Overrideهای قدیمی
- Log Directory و Cron
Scheduled Actions
WooCommerce → Status → Scheduled Actions:
- Failedهای جدید
- Pendingهای گذشته از موعد
- In-progress قدیمی
- Hook یا Group پرتکرار
حذف گروهی Queue بدون شناخت ممکن است ایمیل، Import یا عملیات مالی را ناقص کند.
بررسی Logها
- PHP Fatal Error
- درگاه پرداخت
- ایمیل تراکنشی
- Webhook
- افزونه‌های سفارشی
هدف خواندن خطاهای جدید و پرتکرار است، نه مرور دستی هزاران خط.
تست فرم‌ها و مسیرهای مهم
- فرم تماس
- Login و Lost Password
- جست‌وجو
- سبد خرید
- Checkout تا مرحله درگاه
- My Account
کنترل منابع هاست
- فضای دیسک و Inode
- CPU، RAM و I/O
- PHP Worker
- Database Connection
- رشد Log و Backup
وظایف ماهانه وردپرس
Restore آزمایشی Backup
مهم‌ترین آزمون ماهانه، بازیابی یک نسخه روی Staging یا محیط جداست. موارد تست:
- ورود مدیر
- صفحات و تصاویر
- محصول و سفارش
- درگاه Sandbox
- ایمیل Sandbox
- فایل دانلودی
آخرین تاریخ Restore موفق را ثبت کنید. راهنما در مقاله بکاپ وردپرس موجود است.
بازبینی کاربران و دسترسی‌ها
- Administrator و Shop Manager
- کاربر بلااستفاده
- همکار خارج‌شده
- Sessionهای فعال
- 2FA و Recovery Method
- Application Password و API Key
هر فرد باید حساب مستقل و حداقل دسترسی لازم داشته باشد.
بازبینی افزونه و قالب
- افزونه غیرفعال یا بدون استفاده
- افزونه بدون Update طولانی
- قابلیت تکراری میان چند افزونه
- License در آستانه انقضا
- قالب یا Child Theme بدون Source Control
افزونه غیرفعال همچنان روی فایل‌سیستم وجود دارد و در صورت آسیب‌پذیری ممکن است ریسک ایجاد کند.
تحلیل دیتابیس
- بزرگ‌ترین جدول‌ها
- Autoloaded Options
- Transient منقضی
- Sessionهای منقضی
- Action Scheduler و Log
- رشد غیرعادی Meta
پاک‌سازی باید مرحله‌ای و همراه Backup باشد. مقاله بهینه‌سازی دیتابیس وردپرس جزئیات را دارد.
کنترل Cache و Performance
- TTFB صفحات بدون Cache
- Cache Hit/Miss
- Object Cache
- صفحات Excludeشده
- Core Web Vitals آزمایشگاهی
- Checkout و My Account بدون Cache عمومی
پاک‌کردن دائمی Cache راهکار Performance نیست؛ علت Miss یا Purge غیرعادی باید پیدا شود.
بازبینی SEO فنی
- Sitemap
- Robots و Noindex ناخواسته
- Canonical
- 404 و Redirect Chain
- صفحه‌های اسپم یا هک‌شده
- Structured Data خطادار
پس از Update Rank Math، قالب یا ساختار URL این کنترل اهمیت بیشتری دارد.
تست امنیتی پایه
- ورود 2FA یا Passkey
- Rate Limit
- WAF Event
- Permission فایل
- Core Checksum
- PHP در Uploads
- Backup خارج از هاست
راهنمای مادر در چک‌لیست امنیت وردپرس قرار دارد.
وظایف فصلی
آزمون کامل Disaster Recovery
هر سه ماه یک بار سناریوی از دست‌رفتن هاست را تمرین کنید:
- ساخت سرور یا محیط خالی
- Restore فایل و دیتابیس
- تنظیم DNS آزمایشی
- تست WooCommerce
- ثبت زمان بازیابی واقعی
این آزمون نشان می‌دهد RTO نوشته‌شده واقع‌بینانه است یا خیر.
بازبینی افزونه‌های سفارشی
- Repository و آخرین Commit
- نسخه Release نصب‌شده
- Compatibility با PHP و WooCommerce
- Query، Cron و Queue
- Log و Retention
- Credential و Secret
بررسی Dependencyها و سرویس خارجی
- درگاه
- SMTP
- CDN
- Mailchimp
- Torob و Feed
- Royal MCP و API
- License Server
برای هر سرویس راه جایگزین یا برنامه قطع ارتباط مشخص باشد.
آزمون Staging و Deploy
محیط Staging باید تازه و قابل اعتماد باشد. ایمیل، درگاه و Webhook واقعی در آن غیرفعال بمانند. راهنما در آموزش ساخت Staging وردپرس است.
بازبینی محتوا و تجربه کاربر
- صفحه‌های پربازدید قدیمی
- لینک‌های شکسته
- اطلاعات محصول منقضی
- FAQ و اسکرین‌شات قدیمی
- مسیر خرید موبایل
- دسترسی‌پذیری فرم‌ها
نگهداری محتوا باید ارزش و دقت صفحه را بهتر کند؛ تغییر تاریخ بدون به‌روزرسانی واقعی کاربر را فریب می‌دهد.
وظایف شش‌ماهه
- ارزیابی پلن هاست و منابع
- بررسی نسخه PHP و دیتابیس
- بازبینی معماری Cache و CDN
- ممیزی افزونه‌ها و حذف قابلیت تکراری
- تست کامل درگاه و Refund
- بررسی سیاست Privacy و Retention
- بازبینی SLA و Runbook تیم
تغییر PHP یا سرور را هم‌زمان با Update بزرگ دیگر انجام ندهید مگر تست کامل وجود داشته باشد.
وظایف سالانه
ممیزی امنیت
- کاربران و دسترسی‌های سازمانی
- 2FA، Passkey و Recovery
- WAF و Origin
- Credential Rotation
- افزونه و کد سفارشی
- Backup، Restore و Incident Response
ممیزی عملکرد
- ظرفیت سرور
- رشد دیتابیس و Uploads
- Queryهای کند
- Checkout و صفحات درآمدزا
- هزینه CDN و Object Storage
ممیزی کسب‌وکار
- محصولات بدون فروش
- فایل‌های قدیمی
- Refund و علت بازگشت
- درگاه و هزینه تراکنش
- سیاست مجوز دانلود
- ایمیل و اتوماسیون
تمدیدها
- دامنه
- SSL غیرخودکار
- هاست
- قالب و افزونه تجاری
- SMTP، CDN و Backup Storage
هشدار تمدید را ۳۰، ۱۴ و ۷ روز پیش از انقضا تنظیم کنید.
چک‌لیست Update ماهانه
- Changelog و Compatibility را بخوانید.
- Backup تازه بگیرید.
- Staging را Refresh کنید.
- Updateها را یکی‌یکی اجرا کنید.
- PHP و WooCommerce Log را بررسی نمایید.
- Product، Cart و Checkout را تست کنید.
- ایمیل و Download را آزمایش نمایید.
- تغییر را در Change Log ثبت کنید.
- Production را در Maintenance Window به‌روز کنید.
- Smoke Test و مانیتورینگ انجام دهید.
چک‌لیست WooCommerce پس از هر تغییر
- محصول ساده، مجازی و دانلودی
- Variation و Attribute
- قیمت و کوپن
- Cart و Mini Cart
- خرید مهمان و حساب‌دار
- درگاه و Callback
- کاهش موجودی
- ایمیل Processing و Completed
- لینک Download
- Refund
- HPOS و Scheduled Actions
نگهداری WoodMart و Child Theme
برای قالب فعلی:
- WoodMart و WoodMart Core هماهنگ باشند.
- Template Overrideهای WooCommerce قدیمی نباشند.
- تغییرها داخل Child Theme یا Custom Code مستند قرار گیرند.
- CSS و JS پس از Update و Minify تست شوند.
- Header Builder، Login Popup و Mini Cart روی موبایل کنترل شوند.
نگهداری LiteSpeed Cache
- Cart، Checkout و My Account کش عمومی نشوند.
- Purge غیرعادی و مکرر بررسی شود.
- Object Cache Connection کنترل گردد.
- Image Optimization Queue متوقف نباشد.
- Critical CSS و Delay JS پس از Update تست شوند.
- Cache Preload در ساعت شلوغ منابع را اشباع نکند.
نگهداری Rank Math
- Sitemap XML باز شود.
- Meta Robots صفحه‌های مهم Index باشد.
- 404 Monitor دارای Retention مشخص باشد.
- Redirectهای قدیمی و Chain بررسی شوند.
- Schema پس از تغییر قالب تست شود.
- Instant Indexing Log بدون دلیل رشد نکند.
نگهداری افزونه‌های سفارشی سایت
برای هر افزونه سفارشی یک پرونده نگهداری داشته باشید:
- مالک فنی
- Repository
- نسخه نصب‌شده
- Dependencyهای PHP
- جدول و Optionها
- Cron و Action Hook
- Log Source
- روش Backup و Rollback
- داده موقت و سیاست Cleanup
افزونه بدون مستندات در هنگام خطا به یک نقطه مبهم و پرهزینه تبدیل می‌شود.
چگونه انجام کار را اثبات کنیم؟
کنار تیک «انجام شد» یکی از این شواهد را نگه دارید:
- شناسه Backup و مقصد
- Screenshot یا Export Site Health
- نسخه قبل و بعد افزونه
- لینک Staging و نتیجه تست
- Order ID سفارش آزمایشی
- Log موفق Cron یا Action
- تاریخ Restore آزمایشی
- نتیجه Checksum
این شواهد در Incident و تحویل کار به همکار دیگر ارزش زیادی دارند.
ماتریس مسئولیت
مدیر محتوا
- محتوا، لینک و تصویر
- محصول و قیمت
- بررسی تجربه کاربر
مدیر فروشگاه
- سفارش، موجودی، Refund و کوپن
- ایمیل و فایل دانلودی
- گزارش فروش
مدیر فنی
- Backup، Update و Staging
- Log، Cron، دیتابیس و امنیت
- درگاه، DNS و سرور
حتی در تیم یک‌نفره این نقش‌ها را جدا در چک‌لیست بنویسید تا بخش تجاری زیر سایه کار فنی فراموش نشود.
شاخص‌های نگهداری
- درصد Uptime
- میانگین زمان تشخیص رخداد
- میانگین زمان بازیابی
- تعداد Update معوق
- آخرین Restore موفق
- تعداد Fatal Error جدید
- Failed Payment Rate
- Actionهای Overdue
- رشد ماهانه دیتابیس و Uploads
- درصد کارهای تقویم انجام‌شده
شاخص باید به تصمیم منتهی شود. عددی که هیچ Threshold و مسئول ندارد فقط تزئین Dashboard است.
اشتباهات رایج نگهداری وردپرس
- آپدیت مستقیم Production بدون Backup و Staging
- اعتماد به Backup بدون Restore
- پاک‌سازی دیتابیس با Select All
- خاموش‌کردن هشدارها به‌جای رفع علت
- نگهداری افزونه غیرفعال و قدیمی
- تست‌نکردن Checkout و Callback
- فراموش‌کردن فایل دانلودی
- بازبینی‌نکردن Action Scheduler
- روشن‌گذاشتن Debug
- نداشتن Change Log
- لغو سریع هاست قدیمی پس از مهاجرت
- وابستگی کل برنامه به یک فرد
خطا: کارهای نگهداری زیاد و زمان‌بر شده‌اند
کارهای قابل اتکا را خودکار کنید، گزارش‌ها را به استثنا محدود نمایید و چک‌لیست را براساس ریسک اولویت‌بندی کنید. Automation باید با Alert شکست و بازبینی انسانی همراه باشد.
خطا: بعد از هر Update سایت خراب می‌شود
فاصله نسخه‌ها، Staging، افزونه‌های سفارشی، Template Override و تغییر PHP را بررسی کنید. Updateهای کوچک و منظم از جهش‌های بزرگ کم‌ریسک‌ترند.
خطا: Backup فضا را پر می‌کند
نسخه‌ها داخل همان هاست مانده‌اند یا Retention ندارند. Destination خارجی، Incremental Backup و حذف نسخه قدیمی پس از تأیید Restore را تنظیم کنید.
خطا: Scheduled Actions هر هفته زیاد می‌شوند
حذف Queue کافی نیست. Hook، افزونه مالک، Fatal Error، Cron و منابع سرور را تحلیل کنید.
خطا: Site Health سبز است اما فروشگاه مشکل دارد
Site Health تست عمومی پیکربندی است و نمی‌تواند منطق درگاه، Checkout، ایمیل یا افزونه سفارشی را کامل ارزیابی کند. Synthetic Test و آزمون تجاری لازم است.
تقویم پیشنهادی dev-source.ir
روزانه
- Uptime، Fatal Error و منابع بحرانی
- سفارش Failed/Pending و آخرین پرداخت موفق
- ایمیل و Download
- آخرین Backup
هفتگی
- Updateهای معوق و Changelog
- Site Health و WooCommerce Status
- Scheduled Actions و Woo Logs
- Cart، Checkout، Login و فرم تماس
ماهانه
- Restore کامل روی Staging
- بازبینی Administrator و APIها
- تحلیل دیتابیس و Autoload
- تست درگاه Sandbox، ایمیل و Download
- SEO فنی و 404
فصلی
- Disaster Recovery Drill
- Audit افزونه‌های سفارشی
- مقایسه منابع هاست و رشد داده
- تست کامل Staging و Deploy
سالانه
- ممیزی امنیت و عملکرد
- بازبینی معماری و هزینه سرویس‌ها
- تمدید دامنه، هاست و Licenseها
- به‌روزرسانی Runbook و مسئولیت‌ها
چک‌لیست نهایی نگهداری وردپرس
- دارایی‌ها و دسترسی‌ها مستندند.
- Backup خودکار خارج از هاست وجود دارد.
- Restore دوره‌ای آزمایش می‌شود.
- Uptime، SSL و منابع هشدار دارند.
- Update فقط با Backup و تست انجام می‌شود.
- Site Health و Woo Status بازبینی می‌شوند.
- Checkout، درگاه، ایمیل و Download تست می‌شوند.
- Action Scheduler و Cron مانیتور می‌شوند.
- Logها Retention و Rotation دارند.
- کاربران و API Keyها دوره‌ای بررسی می‌شوند.
- دیتابیس براساس اندازه‌گیری نگهداری می‌شود.
- Staging خصوصی و قابل اعتماد است.
- افزونه‌های سفارشی Repository و Rollback دارند.
- Change Log و Runbook خارج از سایت ذخیره شده‌اند.
- هر کار شاهد و معیار عبور دارد.
📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، انتقال وردپرس به هاست جدید و فایروال وردپرس و WAF
پرسش‌های متداول
هر چند وقت وردپرس را نگهداری کنیم؟
بررسی فروش و خطا برای فروشگاه باید روزانه باشد؛ Update، Site Health و Queue معمولاً هفتگی؛ Restore، دسترسی‌ها و دیتابیس ماهانه. تناوب را با حجم سفارش تنظیم کنید.
آیا افزونه Maintenance همه کارها را انجام می‌دهد؟
خیر. افزونه می‌تواند بخشی از Backup، Update یا Monitoring را خودکار کند، اما تست درگاه، تحلیل سفارش و تصمیم Rollback به فرایند انسانی نیاز دارد.
آیا Auto Update را برای همه افزونه‌ها فعال کنیم؟
برای افزونه کم‌ریسک و همراه Backup و مانیتورینگ قابل بررسی است. WooCommerce، قالب و افزونه سفارشی بهتر است ابتدا روی Staging تست شوند.
مهم‌ترین کار نگهداری چیست؟
Backup قابل Restore، مانیتورینگ و Update کنترل‌شده سه پایه اصلی‌اند. بدون هرکدام، خرابی کوچک می‌تواند به حادثه بزرگ تبدیل شود.
آیا دیتابیس را هر هفته Optimize کنیم؟
خیر. Optimize باید براساس Overhead و نیاز واقعی انجام شود. پاک‌سازی داده منقضی و رفع علت رشد مهم‌تر از اجرای زمان‌بندی‌شده کورکورانه است.
چگونه بفهمیم نگهداری موفق بوده است؟
با شواهد: Restore موفق، سفارش آزمایشی سالم، نبود خطای جدید، Queue بدون تأخیر و شاخص‌های عملکرد در محدوده Baseline.
جمع‌بندی
نگهداری دوره‌ای وردپرس باید از مجموعه کارهای پراکنده به یک سیستم قابل اجرا تبدیل شود. وظیفه، تناوب، مسئول، شاهد و معیار عبور را مشخص کنید؛ در غیر این صورت چک‌لیست به مجموعه‌ای از تیک‌های بدون اطمینان تبدیل می‌شود.
برای فروشگاه WooCommerce، بررسی روزانه سفارش، پرداخت، ایمیل و فایل دانلودی در اولویت است. Update، Site Health، Action Scheduler و Logها باید هفتگی کنترل شوند و Restore، دسترسی‌ها، دیتابیس و تست کامل خرید حداقل ماهانه انجام شوند.
در dev-source.ir وجود HPOS، WoodMart، LiteSpeed و افزونه‌های سفارشی باعث می‌شود برنامه نگهداری باید علاوه بر هسته وردپرس، Queueها، Template Override، پردازش PDF، Import، API و Checkout را نیز پوشش دهد. بهترین برنامه برنامه‌ای است که پیش از خطا هشدار بدهد و هنگام خطا راه بازگشت واقعی داشته باشد.