چک لیست نگهداری سایت وردپرس: گزارش ماهانه پشتیبانی را با خود سایت چطور بسنجیم؟

نمونه گزارش ماهانه صفحه پشتیبانی فنی وردپرس یک چک لیست نگهداری سایت وردپرس است با هشت کار روتین و تیک سبز «انجام شد». روز ۱۸ آبان ۱۴۰۵ سه خط از آن را روی یک فروشگاه آزمایشی فارسی اجرا کردیم (وردپرس 7.1.3 و ووکامرس 11.1.2): به‌روزرسانی هسته و دو افزونه مستقیم روی همان سایت و بدون کپی، یک بکاپ دستی همراه با بازگردانی آن روی سایتی تازه، و یک سفارش آزمایشی با پرداخت در محل. بعد در خود سایت دنبال ردشان گشتیم. از سه به‌روزرسانی دستی فقط ووکامرس ردی گذاشت. بکاپ با تنظیم پیش‌فرض بدون زمان‌بندی و روی همان سرور ساخته شد. سفارش آزمایشی از انبار کم کرد و برای مشتری ایمیل فرستاد.

اگر هر ماه گزارشی با تیک‌های سبز می‌گیرید، جدول زیر می‌گوید هر خط را کجا می‌توانید روی سایت ببینید و کجا باید از پشتیبان مدرک بخواهید. فقط یک فروشگاه، یک افزونه بکاپ و یک روز کار را آزموده‌ایم؛ بخش‌های زیر جدول می‌گویند بیشتر ردیف‌ها را چطور دیدیم. جدول هشت خط گزارش را در هفت ردیف آورده: دو خط آخر یک ردیف‌اند.

خط گزارش	روی خود سایت چه می‌ماند (در آزمایش ما)	از پشتیبان چه بخواهید
به‌روزرسانی هسته، قالب و افزونه‌ها	نگارش فعلی هر کدام؛ از سه به‌روزرسانی دستی ما فقط ووکامرس ردی گذاشت (چون نگارش تازه‌اش مرحله به‌روزرسانی دیتابیس داشت): یک لاگ و چند «عملیات برنامه ریزی شده»	فهرست نگارش قبل و بعد با تاریخ
بررسی امنیت	صفحه کاربران ستون تاریخ ورود ندارد و «سلامت سایت» اسکن بدافزار ندارد	نام ابزار اسکن، تاریخ و خروجی
بکاپ هفتگی	فهرست نسخه‌ها و فایل لاگ افزونه، اگر افزونه‌ای نصب باشد؛ بازگردانی هم لاگ خودش را دارد	محل نگه‌داری، تعداد نسخه‌ها و لاگ بازگردانی
بررسی سرعت	«سلامت سایت» فقط زمان پاسخ سرور را می‌گوید (آزمون کش برگه، با نوع محیط production)، نه Core Web Vitals را	ابزار، صفحه، دستگاه و تاریخ اندازه‌گیری
سلامت درگاه و سفارش آزمایشی	خود سفارش با یادداشت‌هایش، ایمیل‌ها و کم شدن موجودی؛ ما با پرداخت در محل آزمودیم، نه با درگاه	شماره سفارش آزمایشی و وضعیت نهایی‌اش
همگام‌سازی موجودی و سفارش‌ها	یادداشت کم و زیاد شدن موجودی روی سفارش	چند محصول نمونه با موجودی دو طرف
آمادگی فصل فروش و گزارش ماهانه	سندی که پشتیبان می‌نویسد	هر مورد با نتیجه‌اش، نه فقط «انجام شد»

از سه به‌روزرسانی دستی فقط ووکامرس ردی گذاشت

از صفحه «به‌روزرسانی‌ها» ووکامرس را از 11.1.2 به 11.2.2، ووکامرس فارسی را از 10.0.2 به 10.0.7 و بعد وردپرس را از 7.1.3 به 7.1.4 رساندیم. دیتابیس را قبل و بعد مقایسه کردیم: هشت جدول تغییر کرده بود. در ردیف‌های تازه دنبال نام یا نگارش تازه ووکامرس فارسی گشتیم و چیزی نبود. برای هسته هم جز نتیجه آخرین بررسی به‌روزرسانی ردیفی نبود که چیزی درباره خود به‌روزرسانی بگوید. گزینه woocommerce_version مثلاً فقط مقدار تازه را داشت. ایمیلی هم نیامد (۱۳ ایمیل قبل و ۱۳ بعد).

ووکامرس استثنا بود و در دو جا ردی گذاشت. یکی لاگی است که در «ووکامرس > وضعیت > گزارش‌ها» دیده می‌شود: خط‌هایش همه ساعت ۱۲:۱۹:۳۷ دارند و اولی می‌گوید «Automatic database update triggered» (به‌روزرسانی خودکار دیتابیس شروع شد). دیگری فهرست «ابزارها > عملیات برنامه ریزی شده» است که مرحله‌های به‌روزرسانی دیتابیس ووکامرس را با «تکمیل شده» و تاریخ اجرا نشان می‌دهد. ووکامرس این رد را فقط وقتی می‌گذارد که نگارش تازه مرحله به‌روزرسانی دیتابیس داشته باشد؛ رفتن از 11.1.2 به 11.2.2 مرحله‌هایی از این دست داشت. از ووکامرس فارسی و هسته چنین ردی پیدا نکردیم: نه در دیتابیس، نه در ایمیل‌ها، و نه در فایل‌هایی که بین ۱۲:۱۹ و ۱۲:۲۱ تغییر کرده بودند (جز پوشه‌های افزونه‌ها، قالب‌ها، زبان‌ها، wp-admin و wp-includes).

به‌روزرسانی خودکار رفتار دیگری دارد. Contact Form 7 را با روشن بودن به‌روزرسانی خودکار همان افزونه از 6.1.4 به 6.2.4.1 رساندیم؛ به‌روزرسان خودکار وردپرس را مثل یک درخواست کرون (کار زمان‌بندی‌شده خود وردپرس) اجرا کردیم. یک ایمیل به نشانی مدیر سایت رفت و نگارش قبل و بعد را نوشته بود. پس اگر پشتیبان‌تان دستی به‌روز می‌کند، مدرکش را باید خودش بدهد. در آزمایش ما وقتی به‌روزرسانی خودکار افزونه روشن بود، ایمیلی که به نشانی مدیر می‌رسید مدرک بود، به شرطی که کسی آن صندوق را بخواند.

سابقه را خودتان هم می‌توانید بسازید: «ابزارها > سلامت سایت > اطلاعات» دکمه «کپی اطلاعات سایت به کلیپ برد» دارد. متنی که می‌دهد نگارش وردپرس، PHP، دیتابیس، قالب و همه افزونه‌ها را دارد و تاریخ به‌روزرسانی ندارد. هر ماه یکی را با تاریخ در یک فایل نگه دارید و با ماه قبل مقایسه کنید. ترتیب اجرای خود به‌روزرسانی، اول روی کپی، در نوشته به‌روزرسانی روی کپی آمده است. اگر افزونه را با زیپ به‌روزرسانی می‌کنید، نوشته به‌روزرسانی افزونه با زیپ نشان می‌دهد آپلود زیپ نسخه قبلی را بدون کپی پاک می‌کند.

بکاپ پیش‌فرض UpdraftPlus Premium زمان‌بندی ندارد و روی همان سرور می‌ماند

UpdraftPlus Premium 2.26.15.26 را، همان زیپ فروشگاه، روی همین فروشگاه نصب کردیم و هیچ تنظیمی را عوض نکردیم. صفحه‌اش هم برای دیتابیس و هم برای فایل‌ها نوشت «در حال حاضر هیچ چیزی زمان‌بندی نشده است». برنامه هر دو «دستی» بود، دو نسخه برای هر کدام نگه می‌داشت و فضای ذخیره‌ای انتخاب نشده بود. خود صفحه هشدار می‌دهد که بدون فضای ذخیره، بکاپ‌ها روی وب‌سرور می‌مانند و «اگر سرور از کار بیفتد، همه اطلاعات خود را از دست خواهید داد».

دکمه «پشتیبان‌گیری هم‌اکنون» شش فایل ساخت: دیتابیس، افزونه‌ها، قالب، آپلودها، افزونه‌های الزامی و «سایر فایل‌ها»، که فایل‌های زبان فارسی هم در آن است. جمعشان ۴۴٫۵ مگابایت بود و طبق لاگ افزونه ۸٫۶ ثانیه طول کشید. همه در wp-content/updraft ماندند، یعنی داخل پوشه خود سایت. راهنمای وردپرس می‌نویسد نسخه‌ها را در «different locations» (جاهای مختلف) نگه دارید: یکی روی سرور میزبان، یکی در فضای ابری و یکی روی رایانه خودتان. برای گرفتن بکاپ با همین افزونه نوشته بکاپ با UpdraftPlus را ببینید.

صفحه پشتیبانی ما در بند «بکاپ و بازیابی» قرارداد می‌نویسد چه بپرسید: چه چیزی، با چه دوره‌ای و کجا بکاپ می‌شود و آیا بازگردانی هم آزموده می‌شود. نمونه قرارداد همان صفحه محل و مدت نگه‌داری نسخه‌ها را خالی گذاشته تا در پروپوزال پر شود، و نحوه حساب کردن بازگردانی را (داخل سهمیه یا جدا) هم. بخوانید این دو جای خالی در پروپوزال چطور پر شده است.

بازگردانی نوشته‌ها، محصول‌ها و سفارش‌ها را برگرداند، اما حساب مدیر سایت تازه رفت

برای دیدن اینکه بکاپ بازگردانی می‌شود یا نه، یک وردپرس 7.1.4 تازه ساختیم با همان UpdraftPlus و آدرسی دیگر. شش فایل را در پوشه updraft آن گذاشتیم و «Rescan local folder» (اسکن دوباره پوشه محلی) را زدیم. پنجره بازگردانی با شش بخش بدون تیک باز شد؛ همه را تیک زدیم. دو هشدار آمد: یکی که «This looks like a migration» (این شبیه جابه‌جایی سایت است، چون آدرس بکاپ با این سایت فرق دارد) و یکی درباره Collation دیتابیس. تیک «Search and replace site location in the database» (جایگزینی آدرس سایت در دیتابیس) از قبل تیک خورده بود و همان را نگه داشتیم. طبق لاگ بازگردانی ۶٫۱ ثانیه طول کشید.

بعد شمردیم. این‌ها در دو سایت یکی بودند: ۴ نوشته و ۷ برگه (با نوشته و برگه‌های پیش‌فرض وردپرس و ووکامرس؛ ما سه نوشته و دو برگه ساخته بودیم)، ۴ محصول، ۶ سفارش، ۳ کاربر، ۴۹ جدول، ۱۴ فایل در پوشه آپلودها، موجودی هر محصول و تنظیم پرداخت در محل. از چیزهایی که مقایسه کردیم فقط دو مورد فرق داشت: آدرس سایت، که مرحله جابه‌جایی عوضش کرد، و تعداد رویدادهای کرون (۱۵ و ۱۷). حساب مدیر سایت تازه هم رفت و سه حساب فروشگاه جایش آمد.

چیزی که در بکاپ نبود برنگشت. فایل wp-config.php در هیچ‌کدام از پنج فایل زیپ نبود (فایل ششم دیتابیس است) و گزینه WordPress core (هسته وردپرس) در پنجره بکاپ به‌طور پیش‌فرض بدون تیک است. اگر سرور تازه ثابت‌هایی مثل حافظه یا آدرس را درست نداشته باشد، بازگردانی آن‌ها را نمی‌آورد.

بعد از بازگردانی، «آخرین پیام گزارش» در صفحه اصلی افزونه فقط یک جزئیات دیتابیس («Max packet size: 16 MB») با ساعت ۱۲:۲۶:۰۴ بود که خود بازگردانی نوشته بود، و نامی از بازگردانی نبود. رد بازگردانی در صفحه پایانی خود آن (با پیوند دانلود لاگ) و در فایل log.*.txt پوشه updraft هست؛ آن فایل «Restore successful» را می‌نویسد. اگر پشتیبان‌تان می‌گوید بازگردانی را آزموده، این لاگ را بخواهید.

سفارش آزمایشی موجودی را کم کرد و در آمار پیش‌فرض تا تکمیل شدن نیامد

یک سفارش آزمایشی با پرداخت در محل ثبت کردیم: یک «قاب موبایل» به ۱۲۰ هزار تومان، از یک مرورگر بدون ورود، با ایمیلی ساختگی در تسویه حساب. سفارش در حالت «در حال انجام» ماند و پنج یادداشت گرفت: نگه‌داشتن موجودی برای ۶۰ دقیقه، کاهش موجودی «قاب موبایل» از ۱۸ به ۱۷، تغییر وضعیت از «در انتظار پرداخت» به «در حال انجام» و دو یادداشت برای ایمیل‌هایی که رفتند. دو ایمیل رفت، یکی به مدیر («سفارش جدید») و یکی به همان نشانی ساختگی. وقتی وضعیت را «تکمیل شده» کردیم ایمیل سوم به همان نشانی رفت.

درآمد را از REST API ووکامرس (wc-analytics/reports/revenue/stats) خواندیم. تا وقتی سفارش در حال انجام بود همان ۶ سفارش و ۱٬۷۲۰٬۰۰۰ تومان دیده می‌شد. با تکمیل شدن سفارش، آمار ۷ سفارش و ۱٬۸۴۰٬۰۰۰ تومان شد. با لغو سفارش دوباره ۶ و ۱٬۷۲۰٬۰۰۰ شد و موجودی با یادداشتی روی سفارش به ۱۸ برگشت. سفارش لغو شده در فهرست ماند.

علتش در کد ووکامرس 11.2.2 است: ستون تاریخ گزارش درآمد و سفارش‌ها به‌طور پیش‌فرض تاریخ پرداخت است، و سفارش پرداخت در محل تا تکمیل شدن تاریخ پرداخت ندارد. مستندات ووکامرس هم تاریخ پرداخت را پیش‌فرض می‌نویسد و می‌گوید سفارش بدون تاریخ پرداخت در این گزارش‌ها نمی‌آید. سفارش دومی (۸۵ هزار تومان) را در حال انجام نگه داشتیم. گزارش با تاریخ پرداخت ۶ سفارش و ۱٬۷۲۰٬۰۰۰ تومان را نشان داد. وقتی همان API را با date_type=date_created خواندیم، ۷ سفارش و ۱٬۸۰۵٬۰۰۰ تومان شد. در فروشگاه ما واردسازی سفارش‌ها به این آمار هر ۱۲ ساعت یک بار اجرا می‌شود (گزینه woocommerce_analytics_scheduled_import روشن بود و ۱۲ ساعت پیش‌فرض کد است)؛ برای دیدن نتیجه، واردسازی را خودمان دستی اجرا کردیم.

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

در «سلامت سایت» زمان پاسخ سرور هست، اما Core Web Vitals و اسکن امنیتی نیست

«سلامت سایت» روی نصب آزمایشی ما، که نوع محیطش local است، ۳۸ آزمون داشت: ۳۳ مستقیم و ۵ ناهمگام. وقتی نوع محیط را production گرفتیم ۴۰ شد: آزمون کش برگه و آبجکت‌کش دائمی اضافه شدند. آزمون کش برگه زمان پاسخ سرور را می‌سنجد (در نصب ما نوشت «زمان پاسخ سرور خوب است»)، اما Core Web Vitals را نه. هیچ‌کدام از آزمون‌ها بدافزار را اسکن نمی‌کند.

وردپرس زمان ورود هر نشست را در session_tokens کاربر نگه می‌دارد، اما کد 7.1.4 فقط نشست‌های هنوز معتبر را برمی‌گرداند و صفحه کاربران تاریخی ندارد. ووکامرس تاریخ آخرین فعالیت هر کاربر را در wc_last_active نگه می‌دارد (برای حساب مدیر هم نوشته شده بود)، اما جدول wc_customer_lookup فقط ali و sara را داشت. برای یافته‌ای مثل «حساب مدیر قدیمی و بدون استفاده» (در جدول امنیتی نمونه گزارش) در نصب ما صفحه‌ای پیدا نکردیم که نشانش بدهد.

برای فایل‌ها یک ابزار خط فرمان هست: wp core verify-checksums فایل‌های هسته را با مخزن وردپرس می‌سنجد و روی فروشگاه ما موفق بود. wp plugin verify-checksums --all پنج افزونه از شش افزونه را سنجید و برای UpdraftPlus Premium چیزی نسنجید، چون wordpress.org برای آن نگارش فایل چک‌سام نداشت (کد 404). پس در گزارش امنیتی بپرسید اسکنر چه چیزی را با چه چیزی مقایسه کرده است.

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

صفحه پشتیبانی ما نمونه گزارش ماهانه و نمونه قرارداد را دارد؛ هر دو نمونه‌اند: گزارش داده‌ای نمایشی دارد و قرارداد الگویی است که جاهایی از آن خالی مانده. هر خط گزارش را با ستون سوم جدول بالا بسنجید و اگر خطی فقط «انجام شد» می‌گوید، مدرکش را بخواهید. اگر نمی‌خواهید هر ماه خودتان این بررسی‌ها را اجرا کنید، درخواست پشتیبانی ماهانه را ثبت کنید. بررسی‌هایی که پیش از سپردن سایت لازم است در چک لیست بررسی فنی آمده است.

پرسش‌های متداول