
به اشتراک بگذارید

به اشتراک بگذارید
دامنه را ثبت کردهاید و ووکامرس روی سرور مجازی بالا آمده است. برای راهاندازی فروشگاه اینترنتی روی سرور هنوز هشت کار پشت صحنه مانده. هر کدام تاریخ خودش را دارد: روز افتتاح، اولین تمدید گواهی یا اولین خرابی.
💡 این فهرست را با تقویم بخوانید
قلمهای «روز افتتاح» را همین هفته آزمایش کنید. بقیه را با تاریخشان در تقویم بنویسید.
روز افتتاح مغازه کسی سراغ کپسول آتشنشانی نمیرود و قفل کرکره تا شبی که گیر کند دیده نمیشود. گواهی HTTPS، بازگشت درگاه و بکاپ هم روز خودشان را دارند. کاغذبازی نماد اعتماد و پرسش محل سرور را به مطلب اینماد و هاست ایران سپردهایم تا این صفحه به کارهای پشت پیشخوان برسد.
📌 روز افتتاح، اولین تمدید، اولین خرابی
◀️ سیستمعامل و وبسرور؛ انتخابی که بعداً سخت عوض میشود
◀️ دامنه، SSL و ایمیل فروشگاه را پیش از افتتاح آزمایش کنید
◀️ درگاه پرداخت، بکاپ و امنیت؛ سه جایی که خطا سفارش را از بین میبرد
◀️ کش و سرعت؛ کدام صفحهها نباید کش شوند؟

سیستمعامل و وبسرور اولین تصمیم راهاندازی فروشگاه اینترنتی روی سرور است. بعد از اولین سفارش، عوض کردنشان یعنی مهاجرت یک فروشگاه زنده. پس نسخه LTS توزیعی را بگیرید که پشتیبانیاش از عمر فروشگاه بلندتر است و PHP مخزنش با جدول زیر جور است.
صفحه نیازمندیهای ووکامرس برای وبسرور Apache یا Nginx را پیشنهاد میکند. نصب از صفر با Nginx را آموزش نصب وردپرس روی سرور مجازی با Nginx و PHP-FPM پوشش میدهد.
ارقام از همان صفحه است (بازدید ۱۳ آبان ۱۴۰۵)؛ سرور را با گزارش System Status ووکامرس با آنها بسنجید:
| مؤلفه | حداقل توصیهشده ووکامرس |
|---|---|
| وردپرس | نسخه 6.9 یا بالاتر |
| زبان PHP | نسخه 8.3 یا بالاتر (آزموده تا 8.4) |
| دیتابیس | نسخه 8.0 از MySQL یا 10.6 از MariaDB |
| حافظه وردپرس | ۲۵۶ مگابایت یا بیشتر |
| پشتیبانی HTTPS | لازم |
نسخه PHP را هم از همین گزارش بخوانید؛ خروجی php -v مال خط فرمان است و ممکن است با PHP-FPM سایت فرق کند. شاخههای 7.4 تا 8.1 در جدول نسخههای پشتیبانیشده php.net (۳ نوامبر ۲۰۲۶) دیگر نیستند و پشتیبانی امنیتی 8.2 هم ۳۱ دسامبر ۲۰۲۶ تمام میشود.
به گفته مستندات توسعه وردپرس، WP-Cron پیوسته اجرا نمیشود و با بارگذاری صفحهها راه میافتد. ساعت سه بامداد کارها تا اولین بازدید صبح میمانند. صف پسزمینه ووکامرس (Action Scheduler) به گفته مستند کاراییاش با WP-Cron حداکثر دقیقهای یک بار راه میافتد. پس کرون سیستم را هم دقیقهای بگذارید؛ بازه ۱۵ دقیقهای نمونه وردپرس برای فروشگاه کند است. اول در crontab -e:
* * * * * wget -q --delete-after https://YOUR_SITE_URL/wp-cron.php
بعد، در wp-config.php و بالای خط «That’s all, stop editing!»:
define( 'DISABLE_WP_CRON', true );
ترتیب مهم است. نوشتن خود خط کرون، از ترمینال یا از پنل، موضوع آموزش تنظیم کرون جاب در لینوکس، سیپنل و دایرکتادمین است.

دو قلم را پیش از افتتاح تا آخر آزمایش کنید: تمدید گواهی HTTPS و رسیدن ایمیل سفارش به صندوق مشتری. خرابی هیچکدام روز اول راهاندازی فروشگاه اینترنتی روی سرور دیده نمیشود.
«نشانی وردپرس» و «نشانی سایت» هر دو با https ثبت شوند تا تسویه به http برنگردد، و دامنه با www و بدون آن زیر یک گواهی به یک نشانی برسد.
راهنمای کاربری Certbot میگوید بیشتر نصبها تمدید خودکار را از پیش دارند و یک کار زمانبندیشده certbot renew را اجرا میکند. آن را در crontab سیستم (معمولاً /etc/crontab یا /etc/cron.*/*) یا در تایمرهای systemd پیدا میکنید:
systemctl list-timers | grep certbot
sudo certbot renew --dry-run
دستور دوم تمدید آزمایشی است. از Certbot 4.0.0 به بعد، تمدید وقتی شروع میشود که کمتر از یکسوم عمر گواهی مانده باشد. پرسشهای متداول Let’s Encrypt گواهی پیشفرض را ۹۰ روزه میداند. پس اگر تمدید بیصدا شکست بخورد، سایت حدود ۳۰ روز دیگر کار میکند و بعد مرورگر هشدار امنیتی میدهد.
اگر روی سرور سرویس ارسال ایمیل نصب نکردهاید، ایمیلهای ووکامرس جایی نمیروند؛ سادهترین راه یک سرویس SMTP بیرونی از روز اول است. برای ارسال از خود سرور، راهنمای فرستندگان جیمیل SPF یا DKIM و رکورد PTR معتبر برای آیپی را از همه فرستندهها میخواهد. بعد یک سفارش آزمایشی با نشانی جیمیل ثبت کنید.
این سه قلم با پول سروکار دارند: خطای درگاه پرداخت بیسفارش میسازد و نبود بکاپ، سفارشها را با دیسک میبرد. جای هر سه در فهرست پیش از راهاندازی فروشگاه اینترنتی روی سرور است:
| مورد | اگر جا بماند | زمان کشف |
|---|---|---|
| نشانی بازگشت درگاه (CallbackURL) | پرداخت تمام میشود و تأییدی ثبت نمیشود | روز افتتاح |
| آیپی سرور در پنل درگاه | درخواست پرداخت با خطای آیپی رد میشود | اولین مهاجرت |
| بکاپ بیرون از سرور | خرابی دیسک، اصل و بکاپ را با هم میبرد | اولین خرابی |
| آزمون بازگردانی | بکاپ ناقص است و کسی خبر ندارد | اولین خرابی |
| بهروزرسانی امنیتی | آسیبپذیری شناختهشده باز میماند | اولین حمله خودکار |
سند فنی اتصال زرینپال (نسخه 1.2، آوریل ۲۰۱۴) CallbackURL را در درخواست پرداخت اجباری میداند. مشتری به همان نشانی برمیگردد و پذیرنده فقط اگر Status برابر OK بود، PaymentVerification را با Authority فراخوانی میکند. کد خطای -2 در همان سند یعنی شناسه یا آیپی پذیرنده درست نیست، پس آیپی تازه سرور را بعد از هر مهاجرت در پنل درگاه ثبت کنید.
سند قدیمی است. API امروز ممکن است کد دیگری بدهد؛ جزئیات را از مستندات جاری درگاه بخوانید. روالش اما دو شرط را روشن میکند: نشانی بازگشت از اینترنت مشتری باز شود و سرور به سرویس تأیید درگاه برسد.
بکاپ فروشگاه دو بخش دارد: دیتابیس با سفارشها و مشتریها (مثلاً با mysqldump) و پوشه wp-content با تصاویر و افزونهها (مثلاً با rsync). نسخه را بیرون از همان سرور نگه دارید و یک بار روی نصب آزمایشی بازگردانیاش کنید تا زمانش را بدانید.
🔶 نسخه PHP عوض شد و فروشگاه بالا نیامد
پنل اختصاصی سرور وبداده برای همین لحظه اسنپشات و بازگردانی دارد: یکی پیش از عوض کردن نسخه بگیرید و اگر کار خراب شد، سرور را به همان حالت برگردانید. این نقطه برگشت فقط همین سرور است؛ بکاپ بیرونی را جدا نگه دارید.
بهروزرسانی خودکار امنیتی روشن بماند؛ در اوبونتو بسته unattended-upgrades طبق مستندات Ubuntu Server پیشفرض نصب است. در دیواره آتش، مثلاً ufw، فقط پورتهای وب و SSH باز باشد. پیش از گذاشتن PasswordAuthentication no در /etc/ssh/sshd_config، ورود با کلید را در نشست دوم امتحان کنید تا پشت در نمانید.

سبد خرید، حساب کاربری و تسویه حساب سه صفحهایاند که هر چکلیست راهاندازی فروشگاه اینترنتی روی سرور باید از کش صفحه بیرون بگذارد. راهنمای پیکربندی افزونههای کش ووکامرس دلیلش را میگوید: این صفحهها اطلاعات همان مشتری و سبد او را نشان میدهند و باید پویا بمانند.
کوکیهای woocommerce_items_in_cart، woocommerce_cart_hash و wp_woocommerce_session_ را هم به گفته همان راهنما میتوانید از کش بیرون بگذارید. نمونه قاعده Varnish آن صفحه، /cart، /my-account، /checkout و نشانیهای ?add-to-cart= را بدون کش عبور میدهد.
⚠️ کش سطح سرور لزوماً از افزونه پیروی نمیکند
استثناهای افزونه کش لزوماً به Varnish یا کش FastCGI در Nginx نمیرسند. در Nginx، مسیرها و کوکیهای بالا را با دستورهای fastcgi_cache_bypass و fastcgi_no_cache ماژول fastcgi از کش بیرون بگذارید.
در یک مرورگر بدون ورود به حساب، محصولی به سبد اضافه کنید. در پنجره ناشناس مرورگر دیگری سبد را باز کنید؛ باید خالی باشد. اگر محصول آنجا هم بود، صفحه سبد کش شده است.
📱 آزمون پرداخت از بیرون شبکه خودتان
بعد از روشن کردن کش، یک پرداخت کوچک یا آزمایشی را با گوشی و اینترنت همراه انجام دهید. سفارش باید به «در حال انجام» برسد، مگر همه محصولاتش مجازی و دانلودی باشند (مستند وضعیت سفارش ووکامرس).
مسیر سرور تا سرویس تأیید درگاه را روی خود سرور با curl -I https://GATEWAY_HOST بسنجید. سرآیند یعنی مسیر باز است؛ timeout یعنی مشکل شبکه یا دیواره آتش.
برای صاحب فروشگاهی که افتتاحش همین هفته است: اگر فقط وقت یک پرسش را دارید، پرسش درگاه را بخوانید؛ خرابیاش همان روز افتتاح پیدا میشود.
روی سرور مجازی معمولاً یکی از اینهاست: سرور به سرویس درگاه وصل نمیشود، آیپی پنل درگاه با آیپی سرور فرق دارد یا گواهی HTTPS معتبر نیست. یادداشتهای سفارش را هم ببینید.
صفحه نیازمندیهای ووکامرس فقط پشتیبانی از HTTPS را میخواهد و نوع گواهی را تعیین نمیکند. گواهی Let’s Encrypt با تمدید آزموده کافی است.
اول یک خط crontab بگذارید که wp-cron.php را هر دقیقه با wget صدا بزند، بعد ثابت DISABLE_WP_CRON را در wp-config.php برابر true کنید.
بیرون از همان سرور، روی فضای ذخیرهسازی یا سرور دیگر. نسخه روی همان دیسک با خرابی دیسک از بین میرود.
از نظر فنی نوع جداگانهای نیست؛ سرور مجازیای است که نسخههای جدول ووکامرس را دارد. فرقش در نگهداری است.
به گفته راهنمای ووکامرس بسیاری از افزونهها پیشفرض این کار را میکنند، نه همه؛ آزمون دو مرورگر جواب قطعی را میدهد.
رکوردهای SPF و DKIM دامنه و رکورد PTR آیپی ارسال را بررسی کنید و نشانی فرستنده را با دامنه فروشگاه یکی کنید.
جمعبندی؛ سه تاریخ برای راهاندازی فروشگاه اینترنتی روی سرور هر قلم را به یکی از آنها بسپارید. این هفته، پیش از افتتاح: نسخهها، کرون دقیقهای، ایمیل سفارش تا صندوق بیرونی، استثنای کش سبد و تسویه و یک پرداخت از اینترنت همراه. پیش از اولین تمدید گواهی: تمدید آزمایشی Certbot و دیدن تایمرش، که همین امروز هم شدنی است. هر ماه: بازگردانی آزمایشی بکاپ روی یک نصب جدا. هر بار هم که آیپی سرور عوض شد، پنل درگاه را بهروز کنید. با این تقسیم، احتمال اینکه یکی از این خرابیها اولین بار وسط سفارش یک مشتری واقعی پیدا شود خیلی کمتر است.
🚀 سرور فروشگاه در پرونده نماد اعتماد
پیش از درخواست نماد، پرسش محل سرور و آمادهسازی دامنه را هم مرور کنید.
فروشگاه شما روی کدام وبسرور و کدام افزونه کش اجرا میشود؟ و کدام قلم این فهرست را دیرتر از موعدش کشف کردید، و چند روز دیرتر؟
منابع