https://virgool.ir/feed/@arman_radوردپرس و زیرساخت وب می‌نویسم. تجربه‌های واقعی از هاست، دیتابیس و راه‌اندازی سایت برای کسی که می‌خواد کمتر خطا کند.fa2026-11-10 23:03:00https://files.virgool.ir/upload/users/4973958/avatar/yq246v.pnghttps://virgool.ir/@arman_radhttps://virgool.ir/@arman_rad/قبل-از-آپدیت-افزونه-استیجینگ-ساختم-ترتیبی-که-دیگه-روی-پروداکشن-تست-نمیکنم-tomof5dfonnpتجربه عملی ساخت محیط تست برای وردپرس؛ قبل از کپی چه چیزهایی را یادداشت میکنم چطور دیتابیس و درگاه را امن میکنم و روی استیجینگ واقعا چه چیزهایی را چک میکنمچند بار اول که افزونه سنگین یا قالب جدید را مستقیم روی سایت مشتری آپدیت کردم نتیجه اش یا صفحه سفید بود یا فرم پرداخت نیم ساعت از کار افتاد. از ان به بعد تقریبا هیچ آپدیت جدی را روی پروداکشن شروع نمیکنم. اول یک کپی استیجینگ میسازم و همانجا خرابکاری میکنم.استیجینگ یعنی چه و چه چیزی نیستاستیجینگ یک کپی نزدیک به سایت اصلی است با همان افزونهها و قالب و تا جای ممکن همان نسخه PHP. جای تست است نه جای نمایش به مشتری. اگر صفحه را ایندکس کند یا فرم واقعی پرداخت را به درگاه وصل کند دردسر درست میکند.من معمولا دامنه فرعی مثل staging.example.com یا یک زیردامنه موقت روی خود هاست میسازم و در robots یا تنظیمات افزونه سئو ایندکس را میبندم.قبل از کپی اینها را یادداشت کنیدقبل از اینکه دکمه کپی را بزنم این لیست را توی نوت گوشی مینویسم:نسخه PHP و مقدار memory_limitلیست افزونههای فعال مخصوصا کش امنیتی درگاه پرداخت و صفحهسازادرس پیشخوان و اگر ورود دو مرحلهای دارد چطور وارد شوماینکه کرون جاب یا ورکر جدا دارد یا نهبدون این لیست بعد از کپی نیم ساعت دنبال این میگردم که چرا کش روی استیجینگ هنوز فایلهای پروداکشن را سرو میکند.کپی فایل کافی نیست دیتابیس را هم باید درست بیاریدبیشتر وقتها مشکل از اینجاست که فایلها کپی شدهاند ولی در دیتابیس هنوز ادرس سایت قدیمی نوشته شده. بعد از ایمپورت دیتابیس ادرس سایت و home را در جدول options به ادرس استیجینگ عوض میکنم. اگر صفحهساز یا ووکامرس دارید بعضی ادرسها داخل پستها و تنظیمات افزونه هم ماندهاند و بهتر است با ابزار جستجو و جایگزینی امن یا افزونه مهاجرت درستشان کنید نه با replace کور روی کل دامپ.روی استیجینگ درگاه پرداخت را روی حالت تست میگذارم یا کلا کلیدها را خالی میکنم تا سفارش واقعی ثبت نشود. ایمیلهای اعلان را هم به ادرس خودم هدایت میکنم.روی استیجینگ چه چیزهایی را واقعا تست میکنمفقط باز شدن صفحه اصلی کافی نیست. چک لیست کوتاه من:ورود به پیشخوان و ذخیره یک برگهیک سفارش تستی یا حداقل افزودن به سبد اگر فروشگاه استفرم تماس و اگر خبرنامه دارید یک عضویت تستیآپدیت همان افزونه یا قالبی که قرار است روی اصلی برودپاک کردن کش و دیدن صفحه در حالت ناشناساگر همین پنج تا سبز بود معمولا آپدیت روی پروداکشن هم با خیال راحتتر پیش میرود.برگرداندن به پروداکشناگر تست خوب بود دو مسیر دارم. یا همان آپدیت را روی پروداکشن تکرار میکنم چون تغییرات فقط روی افزونه بوده. یا اگر تنظیمات و دیتابیس هم عوض شده با احتیاط از استیجینگ به اصلی مهاجرت میکنم و قبلش بکاپ کامل میگیرم.اگر تست بد بود همانجا میفهمم و پروداکشن دست نخورده مانده. این برای من ارزش اصلیش همین است.جمع بندیاستیجینگ لوکس نیست. بیمه است برای وقتی که یک آپدیت ساده سایت فروش را خواباند. کپی فایل به علاوه دیتابیس درست به علاوه بستن درگاه و ایندکس و یک چک لیست کوتاه واقعی. همین.برای سایتهای مشتری ترجیح میدهم جایی باشد که ساخت محیط تست و بکاپ و فایل منیجر دم دست باشد. خودم برای این کار پاستاکلود را پیشنهاد میکنم چون بدون درگیر شدن با سرور جدا میشود یک کپی برای تست ساخت. اگر خودتان مدیریت میکنید حداقل قبل از آپدیتهای سنگین یک بکاپ کامل بگیرید و اگر میتوانید یک زیردامنه تست راه بیندازید.اخرین باری که بدون استیجینگ آپدیت کردید چه چیزی خراب شد؟آرمان رادآرمان رادSat, 07 Nov 2026 02:34:30 +0330https://virgool.ir/@arman_rad/صفحه-سفید-وردپرس-بعد-از-آپدیت-افزونه-ترتیبی-که-من-خاموش-و-روشن-میکنم-tlp54e3ziz80صفحه سفید بعد از آپدیت افزونه بیشتر از هر خطای دیگری اعصابم را خرد کرده. نه پیامی هست نه کد خطایی. فقط یک صفحه خالی. چند بار اول گیج میشدم. الان یک ترتیب ثابت دارم که تقریبا همیشه جواب میدهد.اول لاگ را باز کنید نه پیشخوان راوقتی پیشخوان هم سفید است ورود به پنل فایده ندارد. مستقیم میروم سراغ لاگ PHP یا error_log داخل پوشه سایت. اگر هاست فایل لاگ را نشان نمیدهد موقتا این سه خط را به wp-config.php اضافه میکنم:define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);بعد یک بار صفحه را رفرش میکنم و فایل wp-content/debug.log را میخوانم. معمولا اسم فایل افزونه یا قالب همانجا نوشته شده.افزونهها را یکجا خاموش نکنیداولین وسوسه این است که پوشه plugins را عوض اسم بدهم تا همه خاموش شوند. این کار سایت را بالا میاورد ولی بعد نمیدانم کدام افزونه خراب بوده و تنظیمات بعضی افزونهها با غیرفعال شدن گروهی به هم میریزد.ترتیبی که خودم میروم:همان افزونهای که همین الان آپدیت شده را از FTP یا فایل منیجر به اسمی مثل plugin-name.off تغییر میدهمسایت را چک میکنم. اگر برگشت همان مقصر استاگر هنوز سفید است سراغ افزونههای کش و امنیتی و بهینهساز میروم چون بیشتر از بقیه با آپدیت تداخل میسازندتازه اگر لازم شد کل پوشه plugins را موقتا تغییر اسم میدهمکش را هم خالی کنیدگاهی خود سایت درست شده ولی شما هنوز صفحه سفید میبینید چون کش صفحه یا CDN نسخه خراب را نگه داشته. بعد از خاموش کردن افزونه خراب کش افزونه کش و اگر Cloudflare دارید کش ان را هم پاک میکنم. یک بار با گوشی روی اینترنت موبایل هم چک میکنم که کش مرورگر گولم نزند.نسخه PHP را بیخودی عوض نکنیدبعضی آموزشها اول میگویند نسخه PHP را پایین بیاورید. من این را اخرین گزینه میگذارم. اگر لاگ میگوید تابعی حذف شده یا افزونه با PHP هشت سازگار نیست ان وقت نسخه را عوض میکنم. وگرنه فقط یک متغیر تازه به مسئله اضافه کردهاید.برگرداندن افزونه بدون از دست دادن تنظیماتاگر نسخه جدید خراب است نسخه قبلی را از مخزن وردپرس یا بکاپ هاست میگیرم و دوباره آپلود میکنم. تنظیمات بیشتر افزونهها در دیتابیس است و با عوض کردن فایلها پاک نمیشود. فقط قبل از آپلود دوباره مطمئن میشوم پوشه با همان اسم درست سر جایش است.برای افزونههای پولی معمولا فایل نسخه قبلی را خودم آرشیو میکنم. یک بار نداشتم و مجبور شدم از بکاپ کامل فایل برگردم.جمع بندیصفحه سفید یعنی خطا هست ولی نمایش داده نمیشود. اول لاگ بعد همان افزونه تازه آپدیت شده بعد کش. این سه قدم بیشتر مواقع کافی است و لازم نیست کل سایت را زیر و رو کنید.سایتهای مشتری را ترجیحا روی اکو وردپرس پاستاکلود نگه میدارم چون لاگ و فایل منیجر و تغییر نسخه PHP و بکاپ روزانه یکجا دم دست است و وقتی صفحه سفید میشود سریعتر به فایلها میرسم. اگر خودتان مدیریت میکنید قبل از آپدیت افزونههای سنگین یک بکاپ بگیرید.اخرین باری که صفحه سفید دیدید اول سراغ لاگ رفتید یا افزونهها را یکجا خاموش کردید؟آرمان رادآرمان رادSat, 07 Nov 2026 00:28:49 +0330https://virgool.ir/@arman_rad/یادداشتهای-من-از-انتقال-دهها-سایت-وردپرسی-از-سیپنل-جاهایی-که-همیشه-گیر-میکنم-cswxqothm7yoانتقال سایت را دوست ندارم. نه چون سخت است بلکه چون همیشه یک چیز کوچک یادم میرود که بعد از تغییر DNS خودش را نشان میدهد. بعد از چند بار یک فهرست یادداشت برای خودم درست کردم. اینجا همان را با کمی توضیح میگذارم.قبل از دست زدن به هر چیزیاین پنج مورد را از هاست فعلی یادداشت میکنم:نسخه PHP که سایت الان رویش اجرا میشوداسم دیتابیس و پیشوند جدولها از فایل wp-config.phpحجم کل فایلها و دیتابیسکرون جابهایی که در سیپنل تعریف شدهایمیلهای دامنه اگر روی همان هاست استمورد اخر را یک بار فراموش کردم. DNS را عوض کردم و ایمیلهای شرکت مشتری دو روز به جایی نمیرسید. هاست جدید وردپرس فقط سایت را میزبانی میکرد و رکوردهای MX باید جداگانه تنظیم میشد.فول بکاپ یا انتقال دستیاگر هاست مقصد از بازیابی فول بکاپ سیپنل پشتیبانی کند سادهترین راه همین است. از بخش Backup در سیپنل یک فول بکاپ میگیرم فایل را دانلود میکنم و در مقصد بارگذاری میکنم.ولی بیشتر وقتها انتقال دستی را ترجیح میدهم چون کنترل بیشتری میدهد و فایلهای اضافه سالها مانده را جا میگذارم.انتقال دستی قدم به قدمفایلها. از مدیر فایل سیپنل محتوای public_html را فشرده میکنم. اگر حجم زیاد است پوشههای کش و بکاپهای قدیمی افزونهها را قبل از فشردهسازی حذف میکنم. معمولا بخش زیادی از حجم همینهاست.دیتابیس. از phpMyAdmin خروجی SQL میگیرم. برای دیتابیس بزرگ اگر دسترسی ترمینال دارم با mysqldump کار میکنم چون phpMyAdmin گاهی وسط کار قطع میشود.mysqldump -u USER -p --default-character-set=utf8mb4 DBNAME > site.sqlگزینه utf8mb4 را به خاطر متن فارسی فراموش نمیکنم. یک بار بدون ان همه نوشتهها بعد از انتقال علامت سوال شده بودند.مقصد. فایلها را بارگذاری و باز میکنم دیتابیس جدید میسازم SQL را وارد میکنم و اطلاعات تازه را در wp-config.php میگذارم.تست قبل از تغییر DNSاین مهمترین بخش است. با ویرایش فایل hosts روی کامپیوتر خودم دامنه را به ایپی سرور جدید اشاره میدهم. اینطوری فقط من سایت را از مقصد میبینم و بقیه هنوز سایت قدیمی را میبینند.چیزهایی که تست میکنم:ورود به پنل مدیریتچند نوشته و برگه با تصویرفرم تماس و ارسال ایمیلاگر فروشگاه است یک سفارش ازمایشی تا مرحله درگاهپیوندهای یکتااگر دامنه عوض میشوداگر ادرس سایت هم تغییر کرده Find و Replace ساده روی فایل SQL خطرناک است. وردپرس بعضی دادهها را سریالشده ذخیره میکند و طول رشته داخل داده نوشته شده. عوض کردن متن بدون اصلاح طول تنظیمات ویجتها و قالب را خراب میکند. برای این کار از wp search-replace در WP-CLI یا ابزارهایی که داده سریالشده را میفهمند استفاده میکنم.تغییر DNS و روزهای اولچند روز قبل از انتقال TTL رکوردهای دامنه را پایین میاورم تا تغییر سریعتر منتشر شود. بعد از تغییر هم هاست قدیمی را چند روز نگه میدارم. اگر در این فاصله کسی دیدگاه یا سفارشی روی سایت قدیمی ثبت کرده باشد دستی منتقلش میکنم.خطاهایی که بعد از انتقال دیدهامخطای اتصال به دیتابیس به خاطر اشتباه در wp-config.phpخطای ۵۰۰ به خاطر فایل htaccess که دستورهای مخصوص هاست قبلی داشتتصاویری که بارگذاری نمیشوند چون ادرسها هنوز به دامنه یا مسیر قدیمی اشاره دارندهشدار Mixed Content بعد از راهاندازی SSLجمع بندیقبل از عوض کردن DNS همهچیز را با فایل hosts تست کنید و ایمیل دامنه را جدا از هاست وردپرس ببینید. این دو مورد بیشتر از هر چیز دیگری بعد از انتقال دردسر درست کردهاند.سایتهای کوچک و متوسط مشتریهایم را این روزها روی اکو وردپرس پاستاکلود میبرم چون بکاپ روزانه و SSL و انتخاب نسخه PHP را یکجا دارد و هر سایت پنل جدای خودش را دارد. اگر قصد مهاجرت دارید اول یک سایت ازمایشی منتقل کنید و بعد بقیه را بیاورید.شما اخرین باری که سایت وردپرس منتقل کردید کجا گیر کردید؟آرمان رادآرمان رادThu, 05 Nov 2026 22:27:12 +0330https://virgool.ir/@arman_rad/گواهی-ssl-سایتم-وسط-قطعی-اینترنت-منقضی-شد-چرا-از-آن-روز-سراغ-dns-01-رفتم-rknxqqcdysffچند روز بود اینترنت بین الملل اختلال داشت و من فکر میکردم سایتهایم که سرورشان داخل است در امان اند. صبح یک روز مرورگر روی یکی از انها پیام اتصال شما خصوصی نیست را نشان داد. سرور روشن بود کد دست نخورده بود فقط گواهی SSL دیروز منقضی شده بود.اسکریپت تمدید خودکار هر شب اجرا شده بود و هر شب بیصدا شکست خورده بود. من هم هیچ هشداری نگرفته بودم.چرا تمدید شکست خوردگواهیهای رایگان Let's Encrypt معمولا با روشی به اسم HTTP-01 تایید میشوند. سرور تایید از خارج کشور یک درخواست به ادرس خاصی روی سایت شما میفرستد و انتظار دارد فایل مشخصی ببیند. اگر این درخواست به سرور نرسد مالکیت دامنه تایید نمیشود.در روزهای اختلال دقیقا همین درخواست ورودی از بیرون است که نمیرسد. یعنی مشکل از تنظیمات من نبود. مسیری که تایید از ان رد میشد بسته بود.DNS-01 چه فرقی دارددر روش DNS-01 به جای گذاشتن فایل روی سرور یک رکورد TXT به اسم _acme-challenge روی دامنه میسازید. سرور تایید فقط DNS دامنه را میپرسد و کاری به سرور شما ندارد.اگر DNS دامنه روی سرویسی باشد که از بیرون جواب بدهد تایید انجام میشود حتی اگر خود سرور فقط از داخل در دسترس باشد. این همان چیزی بود که من لازم داشتم.گواهی Wildcard هم با همین روشیک مزیت جانبی هم پیدا کردم. من برای هر مشتری یک زیردامنه تست میسازم و قبلا برای هر کدام گواهی جدا میگرفتم. Let's Encrypt گواهی Wildcard مثل *.example.com را فقط با DNS-01 صادر میکند. حالا با یک گواهی همه زیردامنه های یک سطح پوشش داده میشوند.کاری که کردممراحل کلی برای هر ابزار ACME تقریبا یکی است:ابزار تمدید را روی حالت DNS گذاشتم. با certbot یا acme.sh این کار با یک گزینه انجام میشود.ابزار یک مقدار تصادفی تولید کرد و از من خواست رکورد TXT با اسم _acme-challenge و همان مقدار بسازم.رکورد را در پنل DNS ساختم و چند دقیقه صبر کردم تا منتشر شود.با ابزار dig یا یک سرویس بررسی انلاین مطمئن شدم رکورد دیده میشود.تایید را ادامه دادم و گواهی صادر شد.dig TXT _acme-challenge.example.com +shortمرحله دستی را حذف کنیدساختن دستی رکورد برای بار اول خوب است ولی گواهیها هر چند وقت یک بار تمدید میشوند و من حافظه خوبی برای این کارها ندارم. اگر سرویس DNS شما API داشته باشد ابزارهایی مثل acme.sh میتوانند رکورد را خودشان بسازند و پاک کنند. اینطوری تمدید واقعا خودکار میشود با هر روش دسترسی که سرور داشته باشد.هشدار انقضادرس دوم ان روز این بود که شکست بیصدا بدترین نوع شکست است. حالا یک بررسی ساده دارم که تاریخ انقضای گواهیها را چک میکند و اگر کمتر از دو هفته مانده باشد به من خبر میدهد. این کار را میشود با یک اسکریپت کوتاه و openssl انجام داد:echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddateجمع بندیبهترین زمان برای عوض کردن روش تایید روزی است که اینترنت وصل است و میشود با خیال راحت تست کرد. صبر نکنید تا گواهی وسط یک اختلال منقضی شود.برای دامنه هایی که خودم مدیریت میکنم الان DNS و SSL را روی پاستاکلود نگه میدارم چون DNS Challenge و گواهی Wildcard را یکجا دارد. اگر سایت وردپرسی دارید اکو وردپرس پاستا هم SSL را خودش تمدید میکند و لازم نیست دستی نگران انقضا باشید.شما برای تمدید SSL از HTTP-01 استفاده میکنید یا DNS-01؟آرمان رادآرمان رادThu, 05 Nov 2026 20:28:41 +0330https://virgool.ir/@arman_rad/چرا-در-پروژه-های-جدیدم-گاهی-postgresql-را-انتخاب-می-کنم-و-گاهی-mysql-ey3eb5durmnrسال‌ها برای من دیتابیس یعنی MySQL بود. وردپرس با آن کار می‌کرد، هاست‌ها پیش‌فرض داشتندش و هر آموزشی که می‌دیدم با آن شروع می‌شد. اولین بار که یک پروژه Django را با PostgreSQL شروع کردم، بیشتر از سر کنجکاوی بود. حالا هر دو را استفاده می‌کنم و فهمیدم سوال «کدام بهتر است» سوال درستی نیست.سوال درست این است: این پروژه به چه چیزی نیاز دارد و تیم با چه چیزی راحت است.وقتی بدون فکر MySQL را انتخاب می‌کنماگر پروژه وردپرس یا ووکامرس است، بحثی نیست. وردپرس برای MySQL و MariaDB ساخته شده و کل اکوسیستم افزونه‌ها روی همین فرض نوشته شده. همین‌طور برای بیشتر CMSهای PHP و پروژه‌های Laravel قدیمی که روی MySQL نوشته شده‌اند.یک دلیل دیگر هم هست که کمتر درباره‌اش صحبت می‌شود: تیم. اگر تیمی سال‌ها با MySQL کار کرده و ابزارها و عادت‌هایش را می‌شناسد، عوض کردن دیتابیس فقط به خاطر مد، هزینه یادگیری دارد که معمولا ارزشش را ندارد.وقتی سراغ PostgreSQL می‌رومدر پروژه‌های جدیدم با Django یا FastAPI یا Node، اغلب PostgreSQL را انتخاب می‌کنم. چند دلیل مشخص دارم:داده نیمه‌ساختاریافته. در یک پروژه تنظیمات هر مشتری شکل متفاوتی داشت. با نوع JSONB در PostgreSQL توانستم این داده را ذخیره کنم و روی فیلدهای داخلش ایندکس بگذارم. در MySQL هم JSON هست، ولی برای این کار PostgreSQL را راحت‌تر یافتم.افزونه‌ها. وقتی خواستم جستجوی معنایی روی متن‌ها بسازم، pgvector را نصب کردم و بردارها را کنار بقیه داده نگه داشتم. برای داده مکانی هم PostGIS هست. این‌ها دلیل اصلی بودند که بعضی پروژه‌ها را به PostgreSQL بردم.گزارش‌گیری. در پروژه‌ای که گزارش‌های پیچیده با چند join و تابع پنجره‌ای داشت، کار با PostgreSQL برایم روان‌تر بود.درباره فارسییک نگرانی رایج این است که کدام فارسی را بهتر پشتیبانی می‌کند. تجربه من این است که هر دو مشکلی ندارند، به شرطی که درست تنظیم شوند. در MySQL حتما کدگذاری utf8mb4 را انتخاب می‌کنم، چون utf8 قدیمی همه کاراکترها را پوشش نمی‌دهد. مرتب‌سازی الفبایی فارسی در هر دو به collation وابسته است و همیشه با داده واقعی تستش می‌کنم، چون ی و ک عربی و فارسی می‌توانند نتیجه را عوض کنند.اشتباهی که کردمیک بار پروژه‌ای را با MySQL شروع کردم و یک سال بعد خواستم ببرمش روی PostgreSQL. ابزار انتقال داده وجود دارد و کار شدنی است، ولی کوئری‌های خامی که نوشته بودم، رفتار متفاوت مقایسه رشته‌ها و تفاوت نوع داده‌ها، چند هفته وقتم را گرفت. از آن به بعد، انتخاب دیتابیس را جدی‌تر و در همان روز اول انجام می‌دهم.قاعده سرانگشتی منوردپرس و PHP قدیمی: MySQLپروژه جدید با JSON زیاد، جستجوی معنایی یا داده مکانی: PostgreSQLتیمی که فقط یکی را می‌شناسد و پروژه نیاز خاصی ندارد: همان که می‌شناسدنگهداری را دست کم نگیریدانتخاب موتور فقط نصف ماجراست. بکاپ منظم، تست بازگردانی و آپدیت نسخه، کارهایی است که من در سرورهای شخصی‌ام بارها عقب انداختم. اگر شما هم حوصله نگهداری دیتابیس را ندارید، پیشنهادم این است که سراغ یک دیتابیس مدیریت‌شده بروید. خودم این روزها از دیتابیس مدیریت‌شده پاستاکلود استفاده می‌کنم که هم PostgreSQL دارد هم MySQL و بکاپ زمان‌بندی‌شده می‌گیرد؛ هر سرویس دیگری هم که این کارها را برایتان انجام دهد، به همان اندازه وقت آزاد می‌کند.آرمان رادآرمان رادThu, 05 Nov 2026 11:28:36 +0330https://virgool.ir/@arman_rad/وقتی-وردپرس-می-گوید-به-دیتابیس-وصل-نمی-شود-ترتیبی-که-من-بررسی-می-کنم-pcxefunh9zhjجمله Error establishing a database connection را احتمالا دیده‌اید. صفحه سفید، یک خط متن، و هیچ چیز دیگر. اولین بار که این را روی سایت خودم دیدم، فکر کردم همه چیز از دست رفته. حالا که بارها دیده‌امش، می‌دانم معمولا علتش ساده‌تر از چیزی است که به نظر می‌رسد.اینجا ترتیبی را می‌نویسم که خودم دنبال می‌کنم. از ساده‌ترین و رایج‌ترین علت شروع می‌کنم و به سمت موارد نادرتر می‌روم.اول: کل سایت یا فقط یک بخشاول بررسی می‌کنم آیا فقط صفحه اصلی این خطا را می‌دهد یا آدرس wp-admin هم. اگر پنل مدیریت پیام دیگری مثل «یک یا چند جدول دیتابیس در دسترس نیست» بدهد، مشکل احتمالا خراب شدن جدول‌هاست، نه قطع اتصال. این تفاوت کوچک مسیر را کاملا عوض می‌کند.دوم: فایل wp-config.phpبیشتر مواردی که من دیده‌ام همین‌جا حل شده. چهار خط را نگاه می‌کنم:define('DB_NAME', '...'); define('DB_USER', '...'); define('DB_PASSWORD', '...'); define('DB_HOST', '...');موقعیت‌هایی که این مقادیر بهم می‌ریزند:سایت را از هاست دیگری منتقل کرده‌اید و اسم دیتابیس یا کاربر عوض شدهکسی رمز کاربر دیتابیس را از پنل عوض کرده ولی فایل را به‌روز نکردهمقدار DB_HOST روی localhost مانده در حالی که هاست جدید آدرس دیگری می‌خواهدیک بار تمام یک ظهر را گشتم و آخرش معلوم شد یک فاصله اضافه آخر رمز عبور بوده که موقع کپی آمده بود.سوم: کاربر به دیتابیس دسترسی دارددر پنل هاست نگاه می‌کنم کاربر دیتابیس واقعا به آن دیتابیس متصل شده و دسترسی کامل دارد. بعد از انتقال سایت، فراموش کردن همین مرحله خیلی رایج است. کاربر ساخته شده، دیتابیس هم ساخته شده، ولی به هم وصل نشده‌اند.چهارم: سرویس دیتابیس بالاستاگر تنظیمات درست بود، احتمال دارد خود سرویس دیتابیس مشکل داشته باشد. روی هاست اشتراکی این را با پشتیبانی چک می‌کنم. روی سرور خودم وضعیت سرویس را نگاه می‌کنم و لاگ MySQL را می‌خوانم. گاهی کمبود فضای دیسک باعث می‌شود سرویس بالا نیاید، مخصوصا وقتی لاگ‌ها یا بکاپ‌های قدیمی جا را پر کرده‌اند.پنجم: جدول‌های خراباگر پنل مدیریت گفت جدول‌ها خراب‌اند، وردپرس ابزار تعمیر داخلی دارد. این خط را موقتا به wp-config.php اضافه می‌کنم:define('WP_ALLOW_REPAIR', true);بعد به آدرس wp-admin/maint/repair.php می‌روم و تعمیر را اجرا می‌کنم. این صفحه به ورود نیاز ندارد، پس حتما بعد از کار خط را پاک می‌کنم. قبل از تعمیر هم یک بکاپ از دیتابیس می‌گیرم، حتی اگر خراب باشد.ششم: فشار زیاد روی دیتابیسگاهی خطا فقط در ساعت‌های شلوغ می‌آید و بعد خودش رفع می‌شود. این یعنی سقف اتصال‌های همزمان پر شده. علتش می‌تواند یک افزونه پرمصرف، ربات‌هایی که سایت را می‌خزند یا نبود کش باشد. اینجا کش صفحه و بستن ربات‌های مزاحم معمولا کمک می‌کند. اگر کمک نکرد، وقت آن است که به منابع بیشتر فکر کنید.چیزی که همیشه آماده دارماز این ماجراها یک عادت برایم مانده: همیشه یک بکاپ تازه از دیتابیس دارم و می‌دانم چطور برگردانمش. وقتی جدول‌ها واقعا از بین بروند، هیچ ترفندی جای بکاپ را نمی‌گیرد.اگر هاستتان بکاپ خودکار روزانه از دیتابیس نمی‌گیرد، همین امروز یک بکاپ دستی بگیرید و یک جای دیگر نگهش دارید. روزی که این خطا را ببینید، از خودتان ممنون می‌شوید.اگه نمی‌خواید درگیر تنظیم دیتابیس و سرور بشید، یه پیشنهاد هم دارم: پاستاکلود یه سرویس ابری ایرانیه که دیتابیس و وردپرس رو آماده تحویل می‌ده.برای شفافیت: من با پاستاکلود همکاری دارم.آرمان رادآرمان رادTue, 03 Nov 2026 14:18:09 +0330https://virgool.ir/@arman_rad/هاست-ارزان-برای-وردپرس-اشتباه-است-تجربه-من-از-سایت-هایی-که-بیخودی-گران-خریده-بودند-rlrjlaxyxan9چند ماه پیش یک مشتری با یک سوال ساده سراغم آمد. سایت معرفی یک دفتر ترجمه داشت، هشت صفحه و یک فرم تماس. ماهانه پول یک پلن سنگین با منابع اختصاصی را می‌داد، چون کسی به او گفته بود «هاست ارزان سایت را خراب می‌کند».نگاهی به آمار سایتش انداختم. بازدید روزانه‌اش آن‌قدر کم بود که عملا بخش بزرگی از منابعی که پولش را می‌داد بیکار مانده بود. این ماجرا برای من تکراری است و برای همین تصمیم گرفتم این یادداشت را بنویسم.ارزان بودن ایراد نیست، اندازه نبودن ایراد استهاست اشتراکی یعنی چند سایت روی یک سرور، پردازنده و حافظه را با هم شریک‌اند. اگر هاست درست مدیریت شود، هر سایت فایل و دیتابیس جدای خودش را دارد و فقط منابع پردازشی مشترک است.برای این نوع سایت‌ها، هاست اشتراکی خوب کاملا کافی است:وبلاگ شخصی یا تخصصیسایت معرفی شرکت یا دفتر کارصفحه فرود یک محصول یا کمپینرزومه آنلاین و نمونه کارنشانه‌هایی که می‌گوید وقت ارتقاستمن سه نشانه را جدی می‌گیرم:یک. پنل مدیریت در ساعت‌های شلوغ کند می‌شود. وقتی چند نفر همزمان محصول اضافه می‌کنند یا سفارش‌ها را بررسی می‌کنند، این اولین جایی است که فشار دیده می‌شود.دو. فروشگاه دارید و کمپین می‌زنید. صفحه سبد خرید و تسویه حساب کش نمی‌شوند و هر درخواست مستقیم به PHP و دیتابیس می‌رسد. اینجاست که منابع مشترک اذیت می‌کند.سه. لاگ خطا پر از پیام‌های محدودیت منابع یا قطع شدن پردازش است. این را فقط وقتی می‌بینید که هاست به شما دسترسی لاگ بدهد.اگر هیچ‌کدام از این‌ها را ندارید، احتمالا پول اضافه می‌دهید.قبل از ارتقا، این‌ها را امتحان کنیدقبل از اینکه به مشتری بگویم پلن را عوض کند، این کارها را انجام می‌دهم:افزونه کش درست را نصب و تنظیم می‌کنمتصاویر را فشرده و به فرمت سبک‌تر تبدیل می‌کنمافزونه‌هایی که سال‌هاست کسی سراغشان نرفته را حذف می‌کنمنسخه PHP را به جدیدترین نسخه‌ای که قالب و افزونه‌ها پشتیبانی می‌کنند می‌برمبارها شده که فقط همین چهار کار، سایت را آن‌قدر سبک کرده که دیگر بحث ارتقا منتفی شده.تست بار را جدی ولی محتاطانه نگاه کنیدبعضی هاست‌ها نتیجه تست بار را منتشر می‌کنند. این خوب است، ولی من همیشه دنبال شرایط تست می‌گردم: چند کاربر همزمان، چه نوع صفحه‌ای، و اینکه فروشگاه و خرید هم سنجیده شده یا نه. عددی که شرایطش معلوم نیست، فقط یک عدد قشنگ است.تصمیمی که من معمولا می‌گیرمقانون شخصی من ساده است. سایت تازه را روی پلن اشتراکی خوب شروع می‌کنم. سه ماه آمار و لاگ را نگاه می‌کنم. اگر یکی از آن سه نشانه پیدا شد، ارتقا می‌دهم. این‌طوری نه پول هدر می‌رود و نه سایت زیر بار می‌ماند.مهم‌ترین شرط این قانون این است که ارتقا راحت باشد. اگر برای رفتن به پلن بزرگ‌تر مجبور باشم سایت را دستی منتقل کنم، کل این روش بی‌معنی می‌شود.آرمان رادآرمان رادTue, 03 Nov 2026 11:05:48 +0330https://virgool.ir/@arman_rad/هاست-ارزان-واقعا-چند-درمیاد-حساب-سال-دوم-naiytsyf4kusپارسال برای یه سایت شخصی یه هاست خریدم که تو صفحه اولش نوشته بود ماهی ۳۹ هزار تومان. سال بعد فاکتور تمدید که اومد اولش فکر کردم اشتباه شده.اشتباه نشده بود. فقط من ریز نوشته ها رو نخونده بودم.قیمتی که میبینی با قیمتی که میدیبیشتر قیمتهای جذاب سه تا شرط دارن که معمولا یه جای کمرنگ نوشته شده:با خرید سه ساله یا دو ساله این عدد درمیادفقط برای دوره اول تخفیف دارهمالیات بر ارزش افزوده جدا حساب میشهیعنی اون ۳۹ هزار تومان در عمل یعنی پرداخت یکجای چند سال. و وقتی تموم شد تمدید با قیمت روز و بدون تخفیف حساب میشه.هزینه هایی که تو جدول نیستاینا رو هم من بعدا فهمیدم:دامنه تو سال اول هدیه بود و سال دوم پولی شدبکاپ روزانه افزونه جدا بود و بدون اون فقط بکاپ هفتگی داشتمssl رایگان بود ولی برای زیر دامنه ها جدا باید درخواست میدادموقتی ترافیک یه ماه زیاد شد سایت معلق شد و برای ارتقا باید ما به التفاوت کل دوره رو میدادمیه حساب سادهقبل از خرید این جدول رو برای خودت پر کن. فقط برای سال دوم نه سال اول:قیمت تمدید یه ساله بدون تخفیفقیمت تمدید دامنههزینه بکاپ اگه جداستمالیاتهزینه ارتقا اگه سایتت یه کم بزرگ بشهوقتی اینا رو جمع کردم دیدم هاست ارزون من تو سال دوم از چند تا گزینه ای که اول گرون به نظر میومدن گرونتر شده.مدل ساعتییه مدل دیگه که این اواخر بیشتر دیدم پرداخت ساعتی یا مصرفیه. یه کیف پول شارژ میکنی و هر ساعت به اندازه منابعی که استفاده کردی کم میشه.خوبیش اینه که تمدید غافلگیرکننده نداره و هر وقت خواستی خاموشش میکنی. بدیش اینه که باید حواست به موجودی باشه که سایت وسط کار خاموش نشه. برای پروژه های تستی و سایتهایی که هنوز نمیدونی میگیرن یا نه به نظرم منطقیتره.چیزایی که از پشتیبانی بپرسقیمت تمدید دقیقا چندهاگه وسط دوره خواستم برم پول برمیگرده یا نهبکاپ چند وقت یه بار گرفته میشه و بازگردانیش هزینه داره یا نهمحدودیت منابع دقیقا چیه و وقتی ردش کنم چی میشهجواب این چهار تا سوال از هر جدول مقایسه ای بیشتر بهت میگه.شما تا حالا تو تمدید هاست غافلگیر شدید؟آرمان رادآرمان رادMon, 02 Nov 2026 22:24:32 +0330https://virgool.ir/@arman_rad/لاراول-روی-هاست-اشتراکی-جاهایی-که-بعدا-گیر-میکنی-oin6rfi6z5obلاراول رو میشه روی هاست اشتراکی بالا آورد. اینو همه آموزشها میگن و درست هم میگن. چیزی که کمتر میگن اینه که سه ماه بعد کجا گیر میکنی.من یه پروژه فروشگاهی کوچیک رو همینجوری شروع کردم و این چیزایی بود که یکی یکی بهشون خوردم.پوشه publicاولین گیر همیشه همینه. لاراول میخواد فقط پوشه public در دسترس وب باشه ولی هاست میگه همه چیز رو بریز تو public_html.راه درستش اینه که از پنل هاست document root رو ببری روی پوشه public. اگه هاستت اجازه نمیده پروژه رو بیرون public_html بذار و فقط محتوای public رو بیار داخل و مسیرهای index.php رو درست کن.کاری که هیچوقت نباید بکنی اینه که کل پروژه رو بریزی تو public_html و با htaccess قایمش کنی. یه اشتباه کوچیک تو تنظیمات و فایل env با همه پسوردهات از تو مرورگر باز میشه.ssh و artisanخیلی از هاستهای ارزون ssh نمیدن یا فقط تو پلنهای بالاتر میدن. بدون ssh نه composer داری نه migrate نه cache:clear.اون اول با آپلود پوشه vendor از لوکال و یه route موقت که artisan رو صدا میزد سر کردم. کار میکرد ولی هر بار یه حفره امنیتی باز میذاشتم و یادم میرفت پاکش کنم.قبل از خرید فقط یه سوال از پشتیبانی بپرس: ssh دارید و میشه composer اجرا کرد؟صف یا همون queueاینجا بود که واقعا گیر کردم. ایمیل تایید سفارش رو انداخته بودم تو صف که صفحه پرداخت کند نشه. روی هاست اشتراکی supervisor نیست که queue:work رو همیشه روشن نگه داره.راه دور زدنش اینه که با کرون هر دقیقه queue:work با گزینه stop-when-empty اجرا بشه. جواب میده ولی ایمیلها با تاخیر میرن و اگه یه job سنگین باشه به محدودیت زمان اجرای هاست میخوره.schedulerخود کرون هم داستان داره. بعضی هاستها حداقل فاصله کرون رو پنج یا پونزده دقیقه گذاشتن. schedule:run لاراول فرض میکنه هر دقیقه صدا زده میشه. پس کارهایی که هر دقیقه باید اجرا بشن یا اجرا نمیشن یا قاطی میشن.نسخه php و اکستنشنهایه روز هاست نسخه php رو خودش عوض کرد و یکی از پکیجها خطا داد. یه بار دیگه هم یه پکیج اکستنشن intl میخواست که هاست نداشت و نمیشد نصبش کرد.کی وقتشه که بریاگه پروژت فقط چند تا صفحه و یه فرم تماسه هاست اشتراکی کاملا کافیه. ولی اگه یکی از اینا رو لازم داری وقتشه به یه سرویس ابری یا سرور فکر کنی:صفی که باید همیشه روشن باشهredis برای کش یا سشنwebsocket یا نوتیفیکیشن زندهدیپلوی از گیت بدون آپلود دستیالان سرویسهای ابری هستن که لاراول رو مستقیم از گیت بالا میارن و worker صف رو هم جدا اجرا میکنن. بعضیها هم ساعتی حساب میکنن و برای یه پروژه کوچیک خرجش از چیزی که فکر میکنی کمتر درمیاد.شما با کدوم یکی از اینا بیشتر درگیر شدید؟آرمان رادآرمان رادMon, 02 Nov 2026 18:28:58 +0330https://virgool.ir/@arman_rad/اگه-حوصله-۸-مرحله-دیپلوی-جنگو-رو-نداری-wo7qtlyrdbv8اولین باری که یه پروژه جنگو رو بردم رو سرور فکر میکردم نهایتا یه ساعت کار داره. ساعت دو نصف شب هنوز داشتم با خطای 502 nginx کلنجار میرفتم و نمیفهمیدم چرا gunicorn بالا نمیاد.اگه آموزشهای دیپلوی جنگو رو خونده باشی میدونی چی میگم. معمولا یه لیست هشت نه مرحله ای دارن که روی کاغذ ساده است و تو عمل هر کدومش یه جا گیر داره.اون هشت مرحله معروف۱. ساختن کاربر غیر روت و بستن ورود با پسورد۲. نصب پایتون و ساختن virtualenv۳. نصب و تنظیم postgres یا mysql۴. تنظیم gunicorn و نوشتن فایل سرویس systemd۵. نوشتن کانفیگ nginx۶. گرفتن گواهی ssl و یادت باشه تمدیدش هم خودکار بشه۷. collectstatic و درست کردن مسیر استاتیکها۸. فایروال و بکاپ دیتابیسهیچکدوم از اینا سخت نیست. مشکل اینه که همشون مال توئه. فردا اگه دیسک پر شد یا ssl تمدید نشد یا آپدیت امنیتی اوبونتو اومد باز خودت باید بری سراغش.سوالی که باید قبلش از خودت بپرسیمن بعد از چند تا پروژه به این نتیجه رسیدم که سوال اصلی اینه که میخوام سرور یاد بگیرم یا میخوام محصولم کار کنه. هر دوش درسته ولی جوابش راه رو عوض میکنه.اگه داری دواپس یاد میگیری همون هشت مرحله رو با دست برو. هیچ چیزی جای اون یه شب بی خوابی رو نمیگیره.ولی اگه یه کلاینت منتظره یا یه ایده رو میخوای زود تست کنی وقت گذاشتن روی nginx معمولا بهترین استفاده از وقتت نیست.راه کوتاهترسرویسهای PaaS دقیقا برای همین ساخته شدن. پروژه رو به گیت وصل میکنی و پلتفرم خودش build و اجرا و ssl رو انجام میده. چند تا سرویس ایرانی هم این مدلی کار میکنن و بعضیهاشون هزینه رو ساعتی حساب میکنن که برای تست خیلی به صرفه است.ولی حتی اونجا هم چند تا کار با خودته و اینا رو هیچ پلتفرمی جات انجام نمیده:DEBUG رو False کن و SECRET_KEY رو از متغیر محیطی بخون نه از کددامنه رو هم تو ALLOWED_HOSTS بذار هم تو CSRF_TRUSTED_ORIGINS وگرنه فرم ادمین خطای 403 میدهتنظیمات دیتابیس رو با یه DATABASE_URL بخون که بین لوکال و سرور فرق نکنهبرای استاتیکها whitenoise بذار که دیگه به nginx جدا نیاز نداشته باشیgunicorn رو تو requirements بذار و دستور اجرا رو مشخص کنmigrate رو جزو مراحل دیپلوی بذار نه یه کار دستی که یادت برهیه نکته که خیلیا جا میندازنفایلهایی که کاربر آپلود میکنه یعنی media رو هیچوقت داخل خود کانتینر نگه ندار. تو اکثر پلتفرمها با هر دیپلوی جدید کانتینر از نو ساخته میشه و عکسها میپرن. یا یه دیسک ماندگار بهش وصل کن یا از یه فضای ذخیره سازی جدا استفاده کن.جمع بندیاون هشت مرحله ارزش یک بار یاد گرفتن رو داره. ولی لازم نیست برای هر پروژه کوچیک تکرارش کنی. یه بار تنظیمات جنگوت رو تمیز کن که با متغیر محیطی کار کنه و بعد هر جا خواستی ببرش.شما اولین دیپلوی جنگوتون کجا گیر کرد؟آرمان رادآرمان رادMon, 02 Nov 2026 16:51:36 +0330https://virgool.ir/@arman_rad/سایت-وردپرسی-ام-هک-شد-کارهایی-که-در-چند-ساعت-اول-کردم-و-کارهایی-که-نباید-می-کردم-tlzcbyjk1fmmیک روز صبح یکی از خواننده‌های وبلاگم پیام داد که وقتی از گوگل روی لینک سایتم می‌زند، سر از یک سایت شرط‌بندی درمی‌آورد. خودم که مستقیم آدرس را می‌زدم، همه چیز عادی بود. این اولین درس بود: بعضی بدافزارها فقط به کسی که از موتور جستجو می‌آید خودشان را نشان می‌دهند.اینجا می‌نویسم آن روز چه کردم، و صادقانه بگویم کجا اشتباه کردم.اشتباه اول: عجله برای پاک کردناولین واکنشم این بود که سریع افزونه‌های مشکوک را پاک کنم. بعدا فهمیدم این کار ردپای نفوذ را هم از بین می‌برد. اگر نمی‌دانید هکر از کجا وارد شده، دو روز بعد دوباره از همان در می‌آید.کاری که باید اول می‌کردم این بود: یک نسخه کامل از وضعیت آلوده، شامل فایل‌ها و دیتابیس، جدا ذخیره کنم تا بعدا بررسی‌اش کنم.قرنطینهبعد سایت را در حالت تعمیر گذاشتم تا بازدیدکننده‌ها به سایت مخرب فرستاده نشوند. اگر هاست اجازه بدهد، دسترسی را موقتا فقط به آی‌پی خودم محدود می‌کنم.عوض کردن همه رمزهااین بخش را کامل انجام دادم:رمز همه کاربران مدیر وردپرسرمز پنل هاسترمز کاربر دیتابیس، و به‌روز کردن آن در wp-config.phpرمز FTP یا SFTP اگر فعال استکلیدهای امنیتی وردپرس در wp-config.php که با عوض کردنشان همه نشست‌ها بسته می‌شونددر فهرست کاربران وردپرس هم یک مدیر ناشناس پیدا کردم که هیچ‌وقت نساخته بودم. حذفش کردم ولی اسم و تاریخ ساختش را یادداشت کردم.پیدا کردن فایل‌های آلودههسته وردپرس را از نسخه رسمی با همان شماره نسخه جایگزین کردم. پوشه‌های wp-admin و wp-includes را کامل پاک کردم و تازه گذاشتم. فایل‌های ریشه را هم با نسخه اصلی مقایسه کردم.بعد سراغ wp-content رفتم که سخت‌ترین قسمت است. چیزهایی که دنبالشان گشتم:فایل PHP داخل پوشه uploads که آنجا اصلا جایی نداردفایل‌هایی با تاریخ تغییر نزدیک روز نفوذکدهای رمزگذاری‌شده با توابعی مثل base64_decode و eval در قالب و افزونه‌هاتغییر در فایل htaccess که ریدایرکت مشکوک داشتافزونه‌ها و قالب را هم به جای پاک‌سازی دستی، کامل حذف کردم و از منبع رسمی دوباره نصب کردم.دیتابیس را فراموش نکنیدریدایرکت من در نهایت داخل دیتابیس بود. یک اسکریپت در جدول wp_options جاسازی شده بود. در جدول پست‌ها هم دنبال تگ script و لینک‌های ناآشنا گشتم.راه نفوذآخر کار فهمیدم یک افزونه فرم که ماه‌ها آپدیت نکرده بودم، آسیب‌پذیری شناخته‌شده داشت. تاریخ ساخت آن کاربر ناشناس هم با زمان انتشار این آسیب‌پذیری جور درمی‌آمد. افزونه را با یک جایگزین فعال عوض کردم.برگرداندن اعتماد گوگلبعد از پاک‌سازی، در سرچ کنسول گوگل بخش مشکلات امنیتی را چک کردم و درخواست بررسی دوباره فرستادم. صفحه‌های اسپمی که ساخته شده بود را هم حذف کردم تا خطای ۴۰۴ بدهند.اگر بکاپ سالم داشتمهمه این کارها یک روز کامل وقتم را گرفت. اگر بکاپی از قبل از نفوذ داشتم، می‌توانستم سایت را برگردانم، رمزها را عوض کنم و افزونه آسیب‌پذیر را حذف کنم. بکاپ جای پیدا کردن راه نفوذ را نمی‌گیرد، ولی خیلی سریع‌تر سایت را برمی‌گرداند.عادت‌هایی که بعد از آن پیدا کردمآپدیت هفتگی افزونه‌ها و حذف هر افزونه‌ای که استفاده نمی‌کنمورود دومرحله‌ای برای همه مدیرهابکاپ روزانه که چند نسخه قبل را هم نگه دارد، چون آلودگی گاهی چند روز بعد کشف می‌شودهاستی که هر سایت را جدا نگه دارد تا آلودگی یکی به بقیه نرسدسایت‌های کوچکم را الان روی اکو وردپرس پاستاکلود نگه می‌دارم که از ۱۹۹ هزار تومان شروع می‌شود. بکاپ روزانه با نگهداری چند نسخه دارد و هر سایت فایل و دیتابیس جدای خودش را دارد. این دو، همان چیزهایی بود که آن روز کم داشتم.آرمان رادآرمان رادMon, 02 Nov 2026 14:17:47 +0330https://virgool.ir/@arman_rad/شبی-که-سایت-مشتری-خطای-۵۰۰-داد-و-من-چطور-پیدایش-کردم-nd2us5swqpybساعت حدود یازده شب بود که پیام آمد: «سایت باز نمی‌شود، فقط یک صفحه سفید با نوشته 500». صاحب سایت یک فروشگاه کوچک لوازم تحریر بود و فردا صبح قرار بود کمپین شروع شود. اگر شما هم الان جلوی همین صفحه نشسته‌اید، بگذارید بگویم آن شب چه کردم.خطای ۵۰۰ یعنی چهخطای ۵۰۰ عملا یعنی «سرور یک جایی به مشکل خورد ولی نمی‌گوید کجا». این پیام خودش هیچ اطلاعاتی ندارد. پس اولین قانون من این است: حدس نزن، لاگ را بخوان.قدم اول: پرسیدن آخرین تغییرقبل از باز کردن هر فایلی، از مشتری پرسیدم امروز چه کار کرده. جواب همیشه اولش «هیچ کار» است. بعد که کمی صحبت کردیم، یادش آمد عصر یک افزونه تخفیف تازه نصب کرده و قالب را هم آپدیت کرده.همین یک سوال، نصف راه را کوتاه می‌کند. بیشتر خطاهای ۵۰۰ که دیده‌ام بعد از یک تغییر آمده‌اند: آپدیت، افزونه تازه، تغییر نسخه PHP یا دست بردن در فایل htaccess.قدم دوم: لاگ خطای PHPوارد پنل هاست شدم و لاگ خطا را باز کردم. خط آخر چیزی شبیه این بود:PHP Fatal error: Uncaught Error: Call to undefined function ... in /wp-content/plugins/.../discount.phpمسیر فایل به‌وضوح اسم همان افزونه تخفیف را داشت. اگر هاست لاگ ندهد، می‌شود موقتا دیباگ وردپرس را روشن کرد. در فایل wp-config.php این خطوط را می‌گذارم:define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);با این تنظیم، خطاها در فایل wp-content/debug.log نوشته می‌شوند و به بازدیدکننده نشان داده نمی‌شوند. یادتان باشد بعد از رفع مشکل خاموشش کنید.قدم سوم: غیرفعال کردن افزونه بدون پنلپنل مدیریت هم خطا می‌داد، پس از راه عادی نمی‌شد افزونه را غیرفعال کرد. از مدیر فایل، اسم پوشه افزونه را در wp-content/plugins عوض کردم و یک پسوند off به آخرش اضافه کردم. وردپرس وقتی پوشه را پیدا نکند، افزونه را خودکار غیرفعال می‌کند.سایت بلافاصله بالا آمد.اگر لاگ نداشتم، همین کار را با کل پوشه plugins می‌کردم و بعد افزونه‌ها را یکی‌یکی برمی‌گرداندم تا مقصر پیدا شود.اگر افزونه مقصر نبوددر سایت‌های دیگر علت‌های دیگری هم دیده‌ام:فایل htaccess خراب: اسمش را عوض می‌کنم و از تنظیمات پیوندهای یکتا دوباره ذخیره می‌زنم تا فایل تازه ساخته شودکمبود حافظه PHP: در لاگ پیام Allowed memory size دیده می‌شود. مقدار memory_limit را از پنل بالا می‌برمناسازگاری نسخه PHP: بعد از تغییر نسخه، قالب قدیمی از کار می‌افتد. نسخه را موقتا برمی‌گردانم و بعد قالب را آپدیت می‌کنمقالب: پوشه قالب فعال را تغییر نام می‌دهم تا وردپرس به قالب پیش‌فرض برگرددکاری که بعد از رفع مشکل کردمآن شب بعد از اینکه سایت بالا آمد، سه کار کردم. به سازنده افزونه گزارش دادم. یک افزونه جایگزین روی نسخه آزمایشی سایت تست کردم. و به مشتری گفتم از این به بعد آپدیت‌ها را صبح انجام دهد، نه شب قبل از کمپین.درسی که گرفتمبزرگ‌ترین چیزی که آن شب نجاتم داد، دسترسی سریع به لاگ و بکاپ بود. اگر لاگ نبود، باید ساعت‌ها حدس می‌زدم. اگر افزونه چیزی را در دیتابیس خراب کرده بود، بکاپ دیروز تنها راه برگشت بود.برای همین وقتی هاست انتخاب می‌کنم، اول نگاه می‌کنم لاگ خطا در دسترس است یا نه و بکاپ روزانه شامل دیتابیس هم می‌شود یا نه. در اکو وردپرس پاستاکلود که از ۱۹۹ هزار تومان شروع می‌شود، هر دو در پنل هست و نسخه PHP را هم خودم عوض می‌کنم. اگر حوصله شب‌بیداری مثل آن شب را ندارید، این دو را قبل از خرید هاست چک کنید.آرمان رادآرمان رادMon, 02 Nov 2026 14:15:30 +0330https://virgool.ir/@arman_rad/چک-لیستی-که-قبل-از-خرید-هاست-وردپرس-برای-مشتری-هایم-مرور-می-کنم-nxm9kkwfwgjoهر بار که کسی از من می‌پرسد «بهترین هاست وردپرس کدام است» یک لحظه مکث می‌کنم. نه چون جواب را نمی‌دانم، بلکه چون این سوال جواب یک‌کلمه‌ای ندارد. سایتی که من برای یک کلینیک دندانپزشکی می‌سازم با فروشگاهی که هر شب کمپین تخفیف دارد زمین تا آسمان فرق دارد.در این سال‌ها یاد گرفتم به جای اسم شرکت‌ها، یک فهرست سوال داشته باشم. این فهرست را اینجا می‌نویسم، شاید به درد کسی بخورد که الان بین چند تب مرورگر گیر کرده.اول از خودم می‌پرسم سایت قرار است چه کار کندقبل از اینکه سراغ هیچ پلنی بروم، سه چیز را روی کاغذ می‌نویسم:سایت روزانه حدودا چند بازدید دارد یا خواهد داشتفروشگاه است یا فقط معرفی و وبلاگچند نفر همزمان در پنل مدیریت کار می‌کنندیک سایت شرکتی پنج صفحه‌ای با یک وبلاگ کوچک، به منابع اختصاصی نیاز ندارد. اشتباه رایجی که دیده‌ام این است که صاحب کسب‌وکار از ترس کند شدن، گران‌ترین پلن را می‌خرد و بعد شش ماه پول منابعی را می‌دهد که هیچ‌وقت مصرف نشده. برعکسش هم هست. فروشگاهی که روی ارزان‌ترین هاست اشتراکی مانده و هر بار کمپین می‌زند، سایتش از دسترس خارج می‌شود.بکاپ را خودم امتحان می‌کنم، نه فقط روی کاغذروی صفحه فروش همه هاست‌ها نوشته بکاپ دارد. سوال من این است که بکاپ چند وقت یک بار گرفته می‌شود، چند نسخه نگه داشته می‌شود و برگرداندنش چقدر کار دارد.یک بار سایتی را تحویل گرفتم که صاحبش مطمئن بود بکاپ روزانه دارد. وقتی افزونه‌ای سایت را خراب کرد، معلوم شد بکاپ فقط فایل‌ها را می‌گرفته و دیتابیس را نه. از آن روز به بعد، هفته اول هر هاست تازه یک بار بازگردانی را واقعا انجام می‌دهم. اگر نشد یا پیچیده بود، همان موقع می‌فهمم.نسخه PHP و کشوردپرس امروزی با PHP قدیمی کنار نمی‌آید. چیزی که می‌خواهم این است که بتوانم نسخه PHP را خودم و بدون تیکت عوض کنم. بعضی افزونه‌های قدیمی هنوز روی نسخه‌های جدید مشکل دارند و لازم است گاهی عقب و جلو بروم.کش سمت سرور هم برایم مهم است. با یک کش خوب، همان سایت روی همان منابع خیلی سبک‌تر بالا می‌آید. اگر هاست LiteSpeed دارد، افزونه رایگانش را نصب می‌کنم و معمولا فرقش را حس می‌کنم.سرور کجاستمخاطب بیشتر سایت‌هایی که من می‌سازم داخل ایران است. وقتی سرور داخل باشد، صفحه برای این کاربرها سریع‌تر باز می‌شود و در روزهایی که اینترنت بین‌الملل اختلال دارد هم سایت برای مشتری داخلی در دسترس می‌ماند. البته این را هم می‌دانم که بعضی کارها مثل آپدیت افزونه از مخزن وردپرس در آن روزها ممکن است کند شود.پنل جدا برای هر سایتاگر چند سایت روی یک اشتراک دارم، دوست دارم هر سایت فایل و دیتابیس و تنظیمات خودش را داشته باشد. وقتی یکی از سایت‌ها آلوده شد، نمی‌خواهم بقیه هم درگیر شوند. این را دیر یاد گرفتم و هزینه‌اش را هم دادم.پشتیبانی را قبل از خرید امتحان می‌کنمیک سوال فنی ساده می‌فرستم، مثلا محدودیت آپلود فایل یا اینکه کرون جاب واقعی دارند یا نه. مهم نیست جواب چقدر سریع بیاید، مهم این است که جواب واقعی باشد یا یک متن آماده.نشانه‌هایی که از آن‌ها فرار می‌کنمقیمت تمدید که با قیمت خرید اول فرق زیادی دارد و جایی هم واضح نوشته نشدهعبارت «نامحدود» برای همه چیز، بدون هیچ توضیحی درباره منابع واقعینبود هیچ راهی برای دیدن لاگ خطابکاپی که فقط با تیکت برمی‌گرددجمع‌بندی شخصیاگر بخواهم کل این فهرست را در یک جمله بگویم: هاست را برای اندازه امروز سایت بخر، ولی جایی بخر که وقتی سایت بزرگ شد بتوانی بدون جابجایی سخت، ارتقا بدهی.این روزها برای سایت‌های تازه و کم‌بازدید مشتری‌هایم، اغلب سراغ اکو وردپرس پاستاکلود می‌روم که از ۱۹۹ هزار تومان شروع می‌شود. بکاپ روزانه فایل و دیتابیس، کش LiteSpeed، SSL رایگان و پنل جدا برای هر سایت دارد و سرورش داخل ایران است. موقع ثبت‌نام هم ۱۰۰ هزار تومان اعتبار هدیه می‌دهد که برای امتحان کردن کافی است. هر وقت سایت رشد کرد، می‌شود سراغ پلن‌های با منابع اختصاصی رفت.اگر شما هم چک‌لیست خودتان را دارید، دوست دارم بدانم چه چیزی را اضافه می‌کنید.آرمان رادآرمان رادMon, 02 Nov 2026 14:12:31 +0330