انتقال سایت وردپرس از لوکال هاست به هاست واقعی، فرآیندی چندلایه است که بدون ترتیب منطقی مراحل، به خطاهای زنجیره‌ای و از دست رفتن داده منتهی می‌شود. نخستین گام، پشتیبان‌گیری کامل از فایل‌ها و پایگاه داده در محیط لوکال است، زیرا هر خطا در مراحل بعدی، بدون پشتیبان جبران‌ناپذیر می‌شود. جایگزینی آدرس‌های لوکال با دامنه واقعی در پایگاه داده، حساس‌ترین مرحله محسوب می‌شود که نیازمند ابزارهای دقیق مانند WP-CLI با گزینه --precise است. پیکربندی فایل wp-config.php با اطلاعات اتصال سرور جدید، پیش از آپلود فایل‌ها باید انجام شود. بازسازی فایل .htaccess، تنظیم مجوزهای فایل و پایش مستمر پس از انتقال، سه گام پایانی این فرآیند محسوب می‌شوند. بدون درک ساختار پایگاه داده وردپرس و رفتار داده‌های سریالایز، جایگزینی ساده آدرس می‌تواند به نامعتبر شدن تنظیمات افزونه‌ها منجر شود.

نخستین باری که یک سایت وردپرسی را از محیط لوکال به سرور واقعی منتقل کردم، تصور می‌کردم آپلود فایل‌ها و ایمپورت پایگاه داده کافی است. اما پس از بارگذاری، به‌جای صفحه اصلی، با ریدایرکت مکرر به localhost مواجه شدم. بررسی دقیق‌تر نشان داد که ده‌ها رکورد در جدول wp_options و wp_postmeta همچنان به آدرس لوکال اشاره می‌کنند. آن تجربه، رویکرد به مهاجرت را از یک عملیات ساده به یک فرآیند مهندسی‌شده تغییر داد. آنچه در ادامه می‌آید، چارچوبی عملی برای این انتقال است.

چرا انتقال از لوکال به هاست واقعی نیازمند رویکرد سیستماتیک است؟

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

نخستین دلیل نیاز به رویکرد سیستماتیک، ماهیت داده‌های وردپرس است. بخشی از داده‌ها، به‌صورت متن ساده ذخیره می‌شوند و جایگزینی آنها ساده است. بخش دیگر، به‌صورت سریالایز (Serialized) ذخیره می‌شوند که در آنها طول رشته نیز ذخیره شده است. در این داده‌ها، جایگزینی ساده آدرس، طول رشته را تغییر می‌دهد و داده را نامعتبر می‌کند. این نامعتبر شدن، به از دست رفتن تنظیمات افزونه‌ها و ویجت‌ها منجر می‌شود.

دومین دلیل، تفاوت محیط‌های توسعه و تولید است. محیط لوکال، معمولاً با تنظیمات آزادانه‌تر، بدون محدودیت‌های امنیتی و با نسخه‌های متفاوت PHP و MySQL اجرا می‌شود. محیط تولید، محدودیت‌های دقیق‌تری دارد و ممکن است از نسخه‌های متفاوتی از نرم‌افزارها استفاده کند. این تفاوت‌ها، می‌توانند به بروز خطاهای ناسازگاری منجر شوند که در محیط لوکال ظاهر نمی‌شدند.

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

سومین دلیل، وابستگی به افزونه‌ها و قالب‌های سفارشی است. بسیاری از پروژه‌های وردپرسی، از افزونه‌ها و قالب‌های سفارشی استفاده می‌کنند که ممکن است به مسیرهای فایل، توابع سیستمی یا کتابخانه‌های خاص وابسته باشند. این وابستگی‌ها، در محیط جدید ممکن است به‌درستی برقرار نشوند و به بروز خطاهای مرگبار (Fatal Error) منجر شوند.

تفاوت‌های بنیادی محیط لوکال و هاست واقعی

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

محور اول: آدرس سایت

در محیط لوکال، آدرس سایت معمولاً چیزی شبیه http://localhost/mysite یا http://mysite.local است. در سرور واقعی، آدرس https://example.com خواهد بود. این تفاوت آدرس، در ده‌ها نقطه از پایگاه داده و فایل‌های پیکربندی تکرار شده است. تفاوت پروتکل (HTTP در برابر HTTPS)، دامنه و مسیر، سه بخش اصلی این تفاوت محسوب می‌شوند.

محور دوم: پشته نرم‌افزاری

محیط لوکال و سرور واقعی، ممکن است از نسخه‌های متفاوتی از PHP، MySQL یا وب‌سرور استفاده کنند. این تفاوت‌ها، به بروز خطاهای ناسازگاری منجر می‌شوند. به‌ویژه، تفاوت نسخه PHP می‌تواند به تغییر رفتار توابع، حذف توابع قدیمی یا تغییر سینتکس منجر شود.

محور سوم: مجوزها و مالکیت فایل‌ها

در محیط لوکال، کاربر معمولاً مالک تمام فایل‌ها است و مجوزها آزادانه‌تر تنظیم می‌شوند. در سرور واقعی، فایل‌ها به کاربر وب‌سرور تعلق دارند و کاربر انسانی دسترسی محدودی دارد. این تفاوت، می‌تواند به بروز خطا در نوشتن فایل‌ها یا اجرای افزونه‌ها منجر شود.

محور چهارم: تنظیمات امنیتی

محیط لوکال، معمولاً بدون محدودیت‌های امنیتی سخت‌گیرانه اجرا می‌شود. سرور واقعی، ممکن است از دیوار آتش، محدودیت‌های PHP و دیگر لایه‌های امنیتی استفاده کند. این تفاوت، می‌تواند به بروز خطا در افزونه‌هایی که به سرویس‌های خارجی متصل می‌شوند، منجر شود.

محور پنجم: کش و لایه‌های بهینه‌سازی

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

جدول مقایسه محیط لوکال و سرور واقعی

ویژگی محیط لوکال سرور واقعی
آدرس سایت localhost یا .local دامنه واقعی با HTTPS
پشته نرم‌افزاری متفاوت و قابل تغییر ثابت و پیکربندی‌شده
مجوز فایل‌ها آزادانه محدود و دقیق
لایه‌های امنیتی حداقلی چندلایه
کش معمولاً غیرفعال فعال
عملکرد بدون محدودیت محدود به منابع هاست

پشتیبان‌گیری پیش از انتقال: گام صفر

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

پشتیبان‌گیری از فایل‌ها

پشتیبان کامل از پوشه وردپرس، شامل هسته، افزونه‌ها، قالب‌ها و فایل‌های آپلود، باید تهیه شود. این پشتیبان، می‌تواند به‌صورت فایل ZIP یا از طریق ابزارهای پشتیبان‌گیری تهیه شود.

پشتیبان‌گیری از پایگاه داده

پایگاه داده، شامل تمام محتوای سایت، تنظیمات و داده‌های کاربران است. پشتیبان‌گیری از این بخش، اهمیت ویژه‌ای دارد. برای اصول این کار، چگونه از دیتابیس وردپرس بکاپ بگیریم را ببینید.

پشتیبان‌گیری با mysqldump

mysqldump -u username -p local_database_name > local_backup.sql

این دستور، پشتیبان کاملی از پایگاه داده در فایل local_backup.sql ایجاد می‌کند. این فایل، در مراحل بعدی برای ایمپورت در سرور جدید استفاده می‌شود.

تست بازیابی پشتیبان

پشتیبان بدون تست بازیابی، هیچ تضمینی ایجاد نمی‌کند. پیش از آغاز مهاجرت، باید فرآیند بازیابی در یک محیط آزمایشی تست شود. برای راهنما، بازیابی سایت از بکاپ را مطالعه کنید.

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

خروجی‌گیری از محیط لوکال

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

خروجی‌گیری از پایگاه داده

پایگاه داده لوکال، باید به‌صورت یک فایل SQL خروجی گرفته شود. این کار از طریق phpMyAdmin یا خط فرمان انجام می‌شود. در phpMyAdmin، گزینه Export امکان انتخاب فرمت و تنظیمات را فراهم می‌کند.

تنظیمات خروجی‌گیری

  • فرمت: SQL
  • کدگذاری: utf8mb4
  • ساختار: شامل ساختار جداول و داده‌ها
  • گزینه‌های اضافی: افزودن DROP TABLE IF EXISTS برای جلوگیری از تداخل

آماده‌سازی فایل‌ها

فایل‌های وردپرس، باید به‌صورت یک آرشیو ZIP آماده شوند. این آرشیو، شامل تمام فایل‌های وردپرس، از جمله هسته، افزونه‌ها، قالب‌ها و فایل‌های آپلود است.

نکات مهم در خروجی‌گیری

  • فایل‌های کش و موقت را حذف کنید
  • فایل‌های پشتیبان قدیمی را حذف کنید
  • فایل‌های .DS_Store یا Thumbs.db را حذف کنید
  • مطمئن شوید که فایل wp-config.php لوکال در آرشیو نیست (یا با نسخه جدید جایگزین می‌شود)

حذف فایل‌های غیرضروری

فایل‌هایی که در محیط لوکال ایجاد شده‌اند اما در سرور واقعی نیازی به آنها نیستند، باید حذف شوند. این کار، حجم آرشیو را کاهش می‌دهد و انتقال را سریع‌تر می‌کند.

آماده‌سازی فایل wp-config.php برای سرور جدید

فایل wp-config.php، قلب پیکربندی وردپرس است. این فایل، باید پیش از آپلود به سرور، با اطلاعات سرور جدید آماده شود. برای اصول امن‌سازی این فایل، چگونه فایل wp-config را امن کنیم بدون شکستن سایت را مطالعه کنید.

اطلاعات اتصال پایگاه داده

اطلاعات اتصال پایگاه داده، باید با اطلاعات سرور جدید تطبیق داده شوند:

define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'new_database_password' );
define( 'DB_HOST', 'localhost' ); // یا آدرس سرور پایگاه داده
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

مقدار DB_HOST، در برخی هاست‌ها ممکن است localhost باشد و در برخی دیگر، آدرس IP سرور یا نام میزبان اختصاصی. این مقدار باید از مستندات ارائه‌دهنده هاست استخراج شود.

کلیدهای امنیتی جدید

کلیدهای امنیتی وردپرس، باید بازتولید شوند تا نشست‌های فعال در محیط لوکال باطل شوند. برای تولید کلیدهای جدید، می‌توانید از سرویس رسمی وردپرس استفاده کنید:

define( 'AUTH_KEY',         'new-unique-phrase' );
define( 'SECURE_AUTH_KEY',  'new-unique-phrase' );
define( 'LOGGED_IN_KEY',    'new-unique-phrase' );
define( 'NONCE_KEY',        'new-unique-phrase' );
define( 'AUTH_SALT',        'new-unique-phrase' );
define( 'SECURE_AUTH_SALT', 'new-unique-phrase' );
define( 'LOGGED_IN_SALT',   'new-unique-phrase' );
define( 'NONCE_SALT',       'new-unique-phrase' );

تنظیمات محیطی

تنظیمات محیطی زیر باید در فایل wp-config.php بررسی شوند:

  • WP_DEBUG: در محیط تولید باید false باشد
  • WP_HOME و WP_SITEURL: در صورت استفاده، به آدرس جدید به‌روزرسانی شوند
  • WP_MEMORY_LIMIT: در صورت نیاز، افزایش یابد
  • DISALLOW_FILE_EDIT: در محیط تولید، true باشد
  • FORCE_SSL_ADMIN: در صورت استفاده از HTTPS، true باشد

تنظیم WP_HOME و WP_SITEURL

در برخی موارد، تعریف این ثابت‌ها در wp-config.php به‌جای پایگاه داده، انعطاف‌پذیری بیشتری فراهم می‌کند:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

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

افزودن قواعد امنیتی

برخی قواعد امنیتی، می‌توانند در فایل wp-config.php تعریف شوند:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'WP_AUTO_UPDATE_CORE', true );

این تعاریف، سطح حمله را کاهش می‌دهند و به‌روزرسانی خودکار را فعال می‌کنند.

آپلود فایل‌ها به سرور واقعی

پس از آماده‌سازی فایل‌ها و wp-config.php، نوبت به آپلود آنها به سرور واقعی می‌رسد. این مرحله، نیازمند دقت در انتخاب روش انتقال و پرهیز از خطاهای رایج است.

روش‌های آپلود

  • FTP/SFTP: روش سنتی و پرکاربرد که امکان انتقال فایل‌ها را فراهم می‌کند
  • File Manager کنترل‌پنل: روش ساده‌تر برای آپلود آرشیو ZIP و استخراج آن
  • SSH و rsync: روش سریع‌تر برای پروژه‌های بزرگ
  • ابزارهای مهاجرت خودکار: مانند Duplicator یا All-in-One WP Migration

آپلود با SFTP

SFTP، نسخه امن FTP است که انتقال داده‌ها را رمزنگاری می‌کند. این روش، برای انتقال فایل‌های حساس توصیه می‌شود.

آپلود آرشیو ZIP

روش سریع‌تر، آپلود یک آرشیو ZIP و استخراج آن در سرور است. این روش، تعداد فایل‌های منتقل‌شده را کاهش می‌دهد و زمان انتقال را کوتاه‌تر می‌کند.

استخراج آرشیو در سرور

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

unzip wordpress_backup.zip -d /path/to/public_html/

حذف آرشیو پس از استخراج

پس از استخراج، آرشیو ZIP باید از سرور حذف شود تا فضای دیسک آزاد شود و از دسترسی غیرمجاز به آن جلوگیری گردد.

نکات مهم در آپلود

  • پیش از آپلود، مطمئن شوید که پوشه مقصد خالی است
  • در حین آپلود، سایت را در حالت نگهداری قرار دهید
  • پس از آپلود، مجوز فایل‌ها را بررسی کنید
  • در صورت بروز خطا در آپلود، فایل‌های ناقص را حذف کنید

ایمپورت پایگاه داده در سرور جدید

پس از آپلود فایل‌ها، نوبت به ایمپورت پایگاه داده در سرور جدید می‌رسد. این مرحله، نیازمند دقت در انتخاب کدگذاری و تنظیمات ایمپورت است.

ایجاد پایگاه داده در سرور جدید

پیش از ایمپورت، باید یک پایگاه داده جدید در سرور ایجاد شود. این کار از طریق کنترل‌پنل هاست انجام می‌شود. نام پایگاه داده، نام کاربری و رمز عبور، باید در فایل wp-config.php ثبت شوند.

ایمپورت از طریق phpMyAdmin

در phpMyAdmin، گزینه Import امکان بارگذاری فایل SQL را فراهم می‌کند. در این مرحله، باید کدگذاری utf8mb4 انتخاب شود.

ایمپورت از طریق خط فرمان

mysql -u username -p new_database_name < local_backup.sql

این دستور، فایل SQL را در پایگاه داده جدید ایمپورت می‌کند. این روش، برای فایل‌های بزرگ سریع‌تر از phpMyAdmin است.

مشکلات رایج در ایمپورت

  • حداکثر حجم فایل: برخی سرورها محدودیت حجم برای ایمپورت دارند
  • حداکثر زمان اجرا: ایمپورت فایل‌های بزرگ ممکن است به تایم‌اوت منجر شود
  • کدگذاری نادرست: عدم تطابق کدگذاری، به نمایش نادرست کاراکترهای فارسی منجر می‌شود
  • تداخل جداول: وجود جداول قدیمی، به خطای ایمپورت منجر می‌شود

رفع مشکلات ایمپورت

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

  • افزایش محدودیت حجم و زمان اجرا از طریق فایل php.ini یا .htaccess
  • تقسیم فایل SQL به بخش‌های کوچک‌تر
  • استفاده از ابزارهای تخصصی مانند BigDump
  • بررسی کدگذاری پایگاه داده

بررسی صحت ایمپورت

پس از ایمپورت، باید صحت داده‌ها بررسی شود. این کار از طریق مقایسه تعداد رکوردها در جداول اصلی انجام می‌شود:

SELECT COUNT(*) FROM wp_posts;
SELECT COUNT(*) FROM wp_options;
SELECT COUNT(*) FROM wp_users;

نتایج این کوئری‌ها باید با محیط لوکال مطابقت داشته باشند.

جایگزینی آدرس‌ها: حساس‌ترین مرحله انتقال

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

محل ذخیره آدرس در پایگاه داده

آدرس سایت در چندین نقطه کلیدی پایگاه داده ذخیره می‌شود:

  • wp_options: رکوردهای siteurl و home
  • wp_posts: ستون guid و محتوای نوشته‌ها
  • wp_postmeta: تنظیمات افزونه‌های صفحه‌ساز
  • wp_options: تنظیمات افزونه‌ها و ویجت‌ها
  • جداول اختصاصی افزونه‌ها: تنظیمات داخلی افزونه‌ها

روش WP-CLI

WP-CLI، سریع‌ترین و ایمن‌ترین روش برای جایگزینی آدرس است:

# اجرای آزمایشی
wp search-replace 'http://localhost/mysite' 'https://example.com' --all-tables --precise --dry-run

# اجرای واقعی
wp search-replace 'http://localhost/mysite' 'https://example.com' --all-tables --precise

گزینه --precise، از جایگزینی ناخواسته در داده‌های سریالایز شده جلوگیری می‌کند. این گزینه، برای جلوگیری از بروز خطا در تنظیمات افزونه‌ها ضروری است.

روش جستجو و جایگزینی در phpMyAdmin

در phpMyAdmin، می‌توان از قابلیت جستجو و جایگزینی برای هر جدول استفاده کرد. این روش، دقت بالایی دارد اما زمان‌بر است:

UPDATE wp_options
SET option_value = REPLACE(option_value, 'http://localhost/mysite', 'https://example.com')
WHERE option_value LIKE '%http://localhost/mysite%';

این کوئری، تنها در جدول wp_options جایگزینی انجام می‌دهد. برای سایر جداول نیز باید کوئری مشابه اجرا شود.

روش افزونه تخصصی

افزونه‌هایی مانند Better Search Replace، امکان جستجو و جایگزینی ایمن را فراهم می‌کنند. این افزونه‌ها، رابط کاربری ساده‌تری دارند و برای کاربران غیرمتخصص مناسب‌ترند.

ترتیب جایگزینی

  1. نخست، جدول wp_options را جایگزین کنید
  2. سپس، جدول wp_posts را جایگزین کنید
  3. سپس، جداول wp_postmeta و wp_usermeta را جایگزین کنید
  4. در نهایت، جداول اختصاصی افزونه‌ها را جایگزین کنید

نکات مهم در جایگزینی

  • پیش از جایگزینی، پشتیبان کامل تهیه کنید
  • ترتیب جایگزینی را رعایت کنید
  • از الگوهای Regex برای پوشش موارد پیچیده استفاده کنید
  • پس از جایگزینی، کش را پاک کنید
  • سایت را به‌طور کامل تست کنید

مدیریت داده‌های سریالایز در جایگزینی آدرس

داده‌های سریالایز، یکی از چالش‌های اصلی در جایگزینی آدرس محسوب می‌شوند. در این داده‌ها، طول رشته ذخیره شده است و اگر جایگزینی به‌درستی انجام نشود، داده نامعتبر می‌شود.

ساختار داده سریالایز

داده سریالایز، به‌صورت زیر ذخیره می‌شود:

a:2:{s:4:"name";s:10:"John Doe";s:3:"url";s:21:"http://localhost/mysite";}

در این ساختار، s:21 نشان‌دهنده طول رشته http://localhost/mysite است. اگر آدرس جایگزین شود اما طول رشته به‌روزرسانی نشود، داده نامعتبر می‌شود.

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

  • WP-CLI با --precise: این گزینه، طول رشته را به‌طور خودکار به‌روزرسانی می‌کند
  • افزونه‌های تخصصی: افزونه‌هایی مانند Better Search Replace، داده سریالایز را به‌درستی مدیریت می‌کنند
  • روش دستی: در موارد خاص، ممکن است نیاز به اصلاح دستی داده‌ها باشد

پیامدهای داده سریالایز نامعتبر

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

  • از دست رفتن تنظیمات افزونه‌ها
  • نمایش نادرست ویجت‌ها
  • خطا در نمایش محتوای صفحه‌سازها
  • عدم بارگذاری بخش‌هایی از سایت

بازیابی داده سریالایز

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

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

پس از جایگزینی آدرس‌ها، باید ساختار پیوندهای یکتا و فایل .htaccess بررسی شوند. این مرحله، از بروز خطای ۴۰۴ در صفحات داخلی جلوگیری می‌کند. برای راهنمای جامع، راهنمای کامل رفع خطای پیوند یکتای وردپرس را مطالعه کنید.

نقش فایل .htaccess

فایل .htaccess، مسئول هدایت درخواست‌های URL به فایل index.php وردپرس است. اگر این فایل وجود نداشته باشد یا محتوای آن نادرست باشد، صفحات داخلی خطای ۴۰۴ می‌دهند.

محتوای استاندارد .htaccess

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

این محتوا، استاندارد وردپرس است. اگر فایل .htaccess خالی است یا محتوای متفاوتی دارد، باید با این محتوا جایگزین شود.

ذخیره مجدد تنظیمات پیوند یکتا

ساده‌ترین راه بازسازی فایل .htaccess، ذخیره مجدد تنظیمات پیوند یکتا در پیشخوان وردپرس است:

  1. به بخش «تنظیمات» و سپس «پیوندهای یکتا» بروید
  2. یک ساختار دیگر انتخاب کنید (مثلاً «نام نوشته»)
  3. روی «ذخیره تغییرات» کلیک کنید
  4. مجدداً ساختار مورد نظر خود را انتخاب و ذخیره کنید

این فرآیند، فایل .htaccess را با محتوای صحیح بازسازی می‌کند.

تنظیمات Nginx

اگر سرور شما از Nginx استفاده می‌کند، تنظیمات پیوند یکتا در فایل پیکربندی سایت قرار می‌گیرد، نه در فایل .htaccess:

location / {
    try_files $uri $uri/ /index.php?$args;
}

این تنظیم، مشابه عملکرد فایل .htaccess در Apache است.

بررسی مجوز فایل .htaccess

فایل .htaccess باید مجوز 644 داشته باشد. مجوزهای نامناسب، می‌توانند مانع خواندن این فایل توسط سرور شوند.

مجوز فایل‌ها و مالکیت در سرور جدید

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

مجوزهای استاندارد

  • پوشه‌ها: 755
  • فایل‌ها: 644
  • wp-config.php: 600 یا 644
  • .htaccess: 644

اعمال مجوزها در لینوکس

# تنظیم مجوز پوشه‌ها
find /path/to/wordpress -type d -exec chmod 755 {} \;

# تنظیم مجوز فایل‌ها
find /path/to/wordpress -type f -exec chmod 644 {} \;

این دستورات، تمام پوشه‌ها را با مجوز 755 و تمام فایل‌ها را با مجوز 644 تنظیم می‌کنند.

مالکیت فایل‌ها

مالکیت فایل‌ها نیز بر عملکرد سایت اثر می‌گذارد. فایل‌های وردپرس باید به کاربر وب‌سرور (معمولاً www-data یا nginx) تعلق داشته باشند:

chown -R www-data:www-data /path/to/wordpress

مالکیت نادرست، می‌تواند مانع نوشتن فایل‌ها توسط وردپرس شود.

پوشه wp-content

پوشه wp-content و زیرپوشه‌های آن، باید دسترسی نوشتن داشته باشند تا وردپرس بتواند فایل‌های آپلودی را ذخیره کند. برای این پوشه، می‌توان مجوز 755 تنظیم کرد.

بررسی مجوز با خط فرمان

ls -la /path/to/wordpress

این دستور، مجوز و مالکیت فایل‌ها و پوشه‌ها را نمایش می‌دهد. بررسی خروجی، به شناسایی مجوزهای نامناسب کمک می‌کند.

اتصال دامنه و تنظیمات DNS

پس از انتقال فایل‌ها و پایگاه داده، باید دامنه به سرور جدید متصل شود. تنظیمات نادرست DNS، می‌تواند مانع دسترسی به سایت شود. برای اصول این حوزه، DNS چیست و چگونه کار می‌کند را مطالعه کنید.

رکوردهای DNS مورد نیاز

  • رکورد A: اتصال دامنه به آدرس IPv4 سرور
  • رکورد AAAA: اتصال دامنه به آدرس IPv6 سرور
  • رکورد CNAME: برای زیردامنه‌ها
  • رکورد MX: برای ایمیل سازمانی

تنظیم رکورد A

رکورد A، اصلی‌ترین رکورد در اتصال دامنه به سرور است:

Type: A
Name: @
Value: 192.0.2.1
TTL: 3600

مقدار Value، باید آدرس IP سرور جدید باشد که از ارائه‌دهنده هاست دریافت می‌شود.

پروپاگیشن DNS

پس از تغییر رکوردهای DNS، این تغییرات باید در سراسر اینترنت منتشر شوند. این فرآیند، بسته به TTL، می‌تواند از چند دقیقه تا ۴۸ ساعت طول بکشد. برای بررسی این فرآیند، پروپاگیشن DNS چیست و چقدر طول می‌کشد را مطالعه کنید.

کاهش TTL پیش از مهاجرت

پیش از مهاجرت، توصیه می‌شود مقدار TTL رکوردهای DNS را به حداقل کاهش دهید. این کار، سرعت انتشار تغییرات را افزایش می‌دهد و بازه قطعی سرویس را کاهش می‌دهد.

پایش پروپاگیشن

ابزارهایی مانند whatsmydns.net یا dnschecker.org، وضعیت پروپاگیشن را در سرورهای مختلف جهان نمایش می‌دهند. این ابزارها، به شناسایی مشکلات احتمالی کمک می‌کنند.

تست اتصال دامنه

ping example.com
dig example.com
nslookup example.com

این دستورات، به بررسی اتصال دامنه و صحت رکوردهای DNS کمک می‌کنند.

خطاهای مرتبط با DNS

در صورت بروز مشکل در اتصال دامنه، عیب‌یابی مشکلات DNS در چند دقیقه را مطالعه کنید.

تست و پایش پس از انتقال

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

چک‌لیست تست پس از انتقال

  • بارگذاری صفحه اصلی و صفحات داخلی
  • بررسی نمایش صحیح استایل‌ها و تصاویر
  • تست فرم‌ها و بخش‌های تعاملی
  • بررسی عملکرد بخش مدیریت
  • تست ورود و خروج کاربران
  • بررسی عملکرد افزونه‌های حیاتی
  • تست عملکرد درگاه‌های پرداخت (در فروشگاه‌ها)
  • بررسی سرعت بارگذاری سایت
  • تست سایت در مرورگرها و دستگاه‌های مختلف

فعال‌سازی حالت دیباگ

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

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

خطاها در فایل wp-content/debug.log ثبت می‌شوند. پس از رفع مشکل، این تنظیمات باید غیرفعال شوند.

پایش عملکرد

پس از انتقال، عملکرد سایت باید با ابزارهایی مانند Google PageSpeed Insights یا GTmetrix اندازه‌گیری شود. مقایسه نتایج با محیط لوکال، به شناسایی تفاوت‌های عملکردی کمک می‌کند.

پایش خطاهای ۴۰۴

بررسی خطاهای ۴۰۴ پس از انتقال، از اهمیت بالایی برخوردار است. این خطاها معمولاً ناشی از ساختار پیوندهای یکتا یا لینک‌های داخلی نادرست هستند. برای رفع این خطاها، چگونه خطای 404 در وردپرس را رفع کنیم را مطالعه کنید.

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

خطاهای رایج پس از انتقال و رفع آن‌ها

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

خطای اتصال به پایگاه داده

این خطا، ناشی از اطلاعات نادرست اتصال در فایل wp-config.php است. نام پایگاه داده، نام کاربری، رمز عبور و میزبان باید با اطلاعات سرور جدید تطبیق داده شوند. برای راهنمای کامل، خطای اتصال به دیتابیس وردپرس را مطالعه کنید.

صفحه سفید (White Screen of Death)

صفحه سفید، معمولاً به خطای مرگبار PHP اشاره دارد. با فعال‌سازی WP_DEBUG، می‌توان خطا را شناسایی و رفع کرد. برای راهنما، رفع خطای سفید صفحه مرگ در وردپرس را ببینید.

ریدایرکت به localhost

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

نمایش سایت بدون استایل

اگر سایت بالا می‌آید اما فاقد استایل CSS است، احتمالاً آدرس فایل‌های استایل به localhost اشاره می‌کند. این مشکل با به‌روزرسانی آدرس‌ها در پایگاه داده برطرف می‌شود.

خطای ۵۰۰ Internal Server Error

این خطا، معمولاً ناشی از سینتکس نادرست در فایل .htaccess یا پیکربندی نادرست سرور است. برای راهنمای رفع، چگونه خطای 500 داخلی سرور را در وردپرس حل کنیم را مطالعه کنید.

خطای ۴۰۴ در صفحات داخلی

اگر صفحه اصلی باز شود اما سایر صفحات خطای ۴۰۴ بدهند، مشکل در ساختار پیوندهای یکتا و فایل .htaccess است. برای راهنمای کامل، راهنمای کامل رفع خطای پیوند یکتای وردپرس را ببینید.

عدم نمایش تصاویر

اگر تصاویر نمایش داده نمی‌شوند، احتمالاً آدرس آنها در پایگاه داده به‌روزرسانی نشده است. این مشکل با جایگزینی دقیق آدرس‌ها برطرف می‌شود.

خطای افزونه‌ها

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

جدول خطاها و راه‌حل‌ها

خطا علت احتمالی راه‌حل
خطای اتصال به دیتابیس اطلاعات نادرست در wp-config.php بررسی تنظیمات پایگاه داده
صفحه سفید خطای PHP، کمبود حافظه فعال‌سازی دیباگ، افزایش حافظه
ریدایرکت به localhost عدم به‌روزرسانی آدرس در پایگاه داده جستجو و جایگزینی آدرس
خطای ۵۰۰ سینتکس نادرست .htaccess بازنشانی فایل .htaccess
خطای ۴۰۴ در صفحات ساختار پیوندهای یکتا ذخیره مجدد تنظیمات پیوند یکتا

پرسش‌های پرتکرار درباره انتقال از لوکال به هاست واقعی

چگونه سایت وردپرس را از لوکال هاست به هاست واقعی منتقل کنم؟

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

چرا سایت پس از انتقال از لوکال بالا نمی‌آید؟

دلایل رایج شامل عدم جایگزینی آدرس‌ها در پایگاه داده، پیکربندی نادرست wp-config.php، عدم تطابق نسخه PHP و MySQL، مجوز نامناسب فایل‌ها و افزونه‌های ناسازگار است.

چگونه آدرس سایت را در پایگاه داده جایگزین کنم؟

از طریق WP-CLI با دستور wp search-replace، افزونه‌های تخصصی یا جستجو و جایگزینی در phpMyAdmin. گزینه --precise در WP-CLI، از بروز خطا در داده‌های سریالایز جلوگیری می‌کند.

چرا سایت به آدرس localhost ریدایرکت می‌شود؟

این مشکل، ناشی از باقی ماندن آدرس localhost در جداول wp_options یا wp_posts است. با جایگزینی دقیق آدرس‌ها، این مشکل برطرف می‌شود.

چرا صفحه سفید بعد از انتقال ظاهر می‌شود؟

صفحه سفید، معمولاً به خطای PHP اشاره دارد. با فعال‌سازی WP_DEBUG، می‌توان خطا را شناسایی و رفع کرد.

چرا صفحات داخلی خطای ۴۰۴ می‌دهند؟

این مشکل، ناشی از ساختار پیوندهای یکتا و فایل .htaccess است. با ذخیره مجدد تنظیمات پیوند یکتا، این مشکل برطرف می‌شود.

آیا باید افزونه‌ها را پس از انتقال غیرفعال کنم؟

در صورت بروز خطا، غیرفعال کردن افزونه‌ها به شناسایی افزونه مشکل‌دار کمک می‌کند. سپس، افزونه‌ها یکی‌یکی فعال و بررسی می‌شوند.

چرا سایت پس از انتقال کندتر شده است؟

کندی ممکن است ناشی از تفاوت در پشته سرور، نبود کش سطح سرور یا تنظیمات نادرست باشد.

آیا نسخه PHP بر انتقال اثر می‌گذارد؟

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

چگونه مجوز فایل‌ها را پس از انتقال تنظیم کنم؟

پوشه‌ها با مجوز 755 و فایل‌ها با مجوز 644. مالکیت نیز باید به کاربر وب‌سرور تنظیم شود.

آیا باید کلیدهای امنیتی را پس از انتقال بازتولید کنم؟

بله، بازتولید کلیدهای امنیتی، نشست‌های فعال در محیط لوکال را باطل می‌کند و امنیت سایت را تقویت می‌نماید.

چگونه مشکل اتصال به پایگاه داده را رفع کنم؟

اطلاعات اتصال در فایل wp-config.php را با مستندات هاست تطبیق دهید.

آیا فایل .htaccess پس از انتقال باید بازسازی شود؟

در بیشتر موارد، بله. ذخیره مجدد تنظیمات پیوند یکتا، فایل .htaccess را با محتوای صحیح بازسازی می‌کند.

چرا برخی تصاویر پس از انتقال نمایش داده نمی‌شوند؟

این مشکل، ناشی از باقی ماندن آدرس localhost در متادیتای تصاویر است. با جایگزینی دقیق آدرس‌ها، این مشکل برطرف می‌شود.

آیا می‌توان بدون WP-CLI، آدرس‌ها را جایگزین کرد؟

بله، از طریق phpMyAdmin یا افزونه‌های تخصصی مانند Better Search Replace. WP-CLI رویکرد سریع‌تر و ایمن‌تری ارائه می‌دهد اما برای کاربران غیرمتخصص، افزونه‌ها گزینه ساده‌تری هستند.

چگونه بفهمم چه افزونه‌ای مشکل را ایجاد می‌کند؟

با غیرفعال کردن تمام افزونه‌ها و فعال‌سازی تدریجی آنها.

نگاه مهندسی به فرآیند مهاجرت محیط توسعه به تولید

از منظر مهندسی نرم‌افزار، مهاجرت از محیط لوکال به سرور تولید، فرآیندی است که بر مفاهیمی مانند تفکیک محیط، مدیریت پیکربندی و بازتولید وضعیت بنا شده است. درک عمیق این فرآیند، نیازمند آشنایی با اصول DevOps و مدیریت محیط است. برای مطالعه بیشتر درباره این مفاهیم، می‌توانید به Deployment environment در ویکی‌پدیا مراجعه کنید.

نخستین بُعد مهندسی، تفاوت میان پیکربندی کد و پیکربندی محیط است. در رویکردهای مدرن DevOps، پیکربندی محیط از کد جدا می‌شود و از طریق متغیرهای محیطی (Environment Variables) مدیریت می‌گردد. وردپرس، در طراحی سنتی خود، این تفکیک را به‌طور کامل رعایت نمی‌کند و آدرس‌ها را در پایگاه داده ذخیره می‌کند. این تصمیم طراحی، منشأ بسیاری از مشکلات مهاجرت است.

بُعد دوم، تفاوت میان داده‌های ساختاریافته و داده‌های جاسازی‌شده است. در پایگاه داده وردپرس، برخی داده‌ها (مانند تنظیمات افزونه‌ها) به‌صورت سریالایز ذخیره می‌شوند که شامل طول رشته هستند. جایگزینی ساده آدرس در این داده‌ها، به نامعتبر شدن آنها منجر می‌شود. ابزارهایی مانند WP-CLI با گزینه --precise، این مشکل را برطرف می‌کنند.

بُعد سوم، تفاوت میان محیط‌های حالت‌دار و بی‌حالت است. محیط لوکال، اغلب حالت‌دار است و داده‌های موقت در آن انباشته می‌شوند. محیط سرور واقعی، بی‌حالت‌تر است و داده‌های موقت به‌طور منظم پاک می‌شوند. این تفاوت، می‌تواند به رفتارهای متفاوت در دو محیط منجر شود.

بُعد چهارم، تفاوت میان کش درون‌برنامه‌ای و کش خارجی است. وردپرس، از چندین لایه کش استفاده می‌کند: کش شیء درون‌برنامه‌ای، کش صفحه در سطح سرور و کش مرورگر. در محیط لوکال، این لایه‌ها ممکن است غیرفعال یا محدود باشند. در سرور واقعی، این لایه‌ها فعال‌تر هستند و می‌توانند رفتار سایت را تغییر دهند.

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

بُعد ششم، تفاوت میان نسخه‌های نرم‌افزاری است. محیط لوکال ممکن است از نسخه‌ای از PHP، MySQL یا وب‌سرور استفاده کند که با سرور واقعی متفاوت است. این تفاوت، به بروز خطاهای ناسازگاری منجر می‌شود که در محیط لوکال ظاهر نمی‌شدند. رویکرد DevOps، بر یکسان‌سازی محیط‌ها از طریق کانتینرها (Containers) تأکید دارد.

بُعد هفتم، تفاوت میان پیکربندی سرور و پیکربندی برنامه است. پیکربندی سرور (مانند Nginx یا Apache) خارج از کد وردپرس قرار دارد و باید در زمان مهاجرت به‌درستی تنظیم شود. عدم تطابق این پیکربندی، به بروز خطاهای ۴۰۴ یا ۵۰۰ منجر می‌شود.

بُعد هشتم، تفاوت میان بکاپ منطقی و بکاپ فیزیکی است. بکاپ منطقی، از طریق ابزارهایی مانند mysqldump تهیه می‌شود و شامل کوئری‌های SQL است. بکاپ فیزیکی، از طریق کپی مستقیم فایل‌های پایگاه داده تهیه می‌شود. رویکرد نخست، قابل حمل‌تر و برای مهاجرت مناسب‌تر است.

بُعد نهم، تفاوت میان مهاجرت یک‌باره و مهاجرت تدریجی است. مهاجرت یک‌باره، تمام سایت را در یک مرحله منتقل می‌کند. مهاجرت تدریجی، بخش‌های مختلف را در بازه‌های زمانی جداگانه منتقل می‌کند. رویکرد نخست، ساده‌تر است اما ریسک بالاتری دارد. رویکرد دوم، پیچیده‌تر است اما امکان بازگشت سریع‌تر را فراهم می‌کند.

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

چک‌لیست عملی برای انتقال موفق

  • پیش از انتقال، پشتیبان کامل از فایل‌ها و پایگاه داده تهیه کنید.
  • نسخه PHP و MySQL سرور جدید را با محیط لوکال هماهنگ کنید.
  • اطلاعات اتصال پایگاه داده را در فایل wp-config.php به‌روزرسانی کنید.
  • کلیدهای امنیتی وردپرس را بازتولید کنید.
  • فایل wp-config.php را پیش از آپلود آماده کنید.
  • فایل‌ها را به‌صورت آرشیو ZIP آپلود و در سرور استخراج کنید.
  • پایگاه داده را از طریق phpMyAdmin یا خط فرمان ایمپورت کنید.
  • آدرس‌ها را در تمام جداول پایگاه داده جایگزین کنید.
  • از WP-CLI با گزینه --precise برای جایگزینی استفاده کنید.
  • فایل .htaccess را بازسازی یا با محتوای استاندارد جایگزین کنید.
  • مجوز پوشه‌ها را به 755 و فایل‌ها را به 644 تنظیم کنید.
  • پس از انتقال، افزونه‌ها را یکی‌یکی فعال و بررسی کنید.
  • حالت دیباگ را فعال کنید تا خطاها شناسایی شوند.
  • DNS و اتصال دامنه را بررسی کنید.
  • سایت را در مرورگرهای مختلف و دستگاه‌های متفاوت تست کنید.
  • پس از رفع مشکل، تنظیمات دیباگ را غیرفعال کنید.
  • عملکرد سایت را پیش و پس از انتقال اندازه‌گیری کنید.
  • برنامه بازگشت داشته باشید تا در صورت بروز مشکل، سایت به وضعیت قبلی بازگردد.

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