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

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

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

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

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

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

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

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

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

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

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

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

نشانه‌های رایج و علت هر یک

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

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

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

• خطای سینتکس در فایل functions.php یا یکی از افزونه‌ها
• عدم تطابق نسخه PHP
• کمبود حافظه مجاز PHP
• ناسازگاری افزونه با سرور جدید

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

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

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

• نام کاربری یا رمز عبور پایگاه داده اشتباه
• نام پایگاه داده اشتباه
• میزبان پایگاه داده اشتباه
• عدم دسترسی کاربر پایگاه داده به سرور

برای راهنمای کامل، خطای اتصال به دیتابیس وردپرس را ببینید.

ریدایرکت به آدرس لوکال

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

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

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

خطای ۵۰۰ Internal Server Error

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

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

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

جدول نگاشت نشانه‌ها و علل

عدم تطابق آدرس: ریشه اصلی مشکل

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

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

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

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

روش‌های جایگزینی آدرس

چندین روش برای جایگزینی آدرس وجود دارد:

• WP-CLI: دستور wp search-replace با قابلیت Dry Run
• افزونه‌های مهاجرت: مانند Duplicator یا All-in-One WP Migration
• جستجو و جایگزینی در phpMyAdmin: روش دستی با دقت بالا
• افزونه Search & Replace: افزونه تخصصی برای این کار

نمونه دستور WP-CLI

wp search-replace 'http://localhost/mysite' 'https://example.com' --all-tables --precise --dry-run

اجرای این دستور با --dry-run، پیش‌نمایش تغییرات را نشان می‌دهد. پس از اطمینان، می‌توانید --dry-run را حذف کنید.

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

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

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

پیکربندی نادرست wp-config.php

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

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

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

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

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

کلیدهای امنیتی (Security Keys)

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

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

برای تولید کلیدهای جدید، می‌توانید از سرویس رسمی وردپرس در api.wordpress.org/secret-key/1.1/salt/ استفاده کنید.

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

پس از انتقال، تنظیمات محیطی زیر باید بررسی شوند:

• 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، باید آدرس‌های قدیمی در پایگاه داده جایگزین شوند. این مرحله، حساس‌ترین بخش انتقال است. برای بررسی روش‌های مختلف، مهاجرت دیتابیس WordPress به سرور جدید را مطالعه کنید.

روش دستی با 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 جایگزینی انجام می‌دهد. برای سایر جداول نیز باید کوئری مشابه اجرا شود.

روش WP-CLI

WP-CLI، روش سریع‌تر و ایمن‌تری ارائه می‌دهد. دستور wp search-replace، تمام جداول را به‌طور خودکار بررسی می‌کند:

# اجرای آزمایشی
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، از جایگزینی ناخواسته در داده‌های سریالایز شده جلوگیری می‌کند. این گزینه، برای جلوگیری از بروز خطا در تنظیمات افزونه‌ها ضروری است.

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

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

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

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

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

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

پس از جایگزینی

• کش مرورگر و کش سرور را پاک کنید
• سایت را در یک مرورگر ناشناس تست کنید
• بخش مدیریت را بررسی کنید
• فرم‌ها و بخش‌های تعاملی را تست کنید

ساختار پیوندهای یکتا و فایل .htaccess

پس از انتقال، ممکن است صفحه اصلی سایت باز شود اما سایر صفحات خطای ۴۰۴ بدهند. این مشکل، به ساختار پیوندهای یکتا و فایل .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 در فایل‌های وردپرس را مطالعه کنید.

عدم تطابق نسخه PHP و MySQL

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

تأثیر نسخه PHP

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

بررسی نسخه PHP

php -v

یا از طریق تابع PHP:

<?php echo phpversion(); ?>

تأثیر نسخه MySQL

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

رفع عدم تطابق نسخه

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

جدول سازگاری نسخه‌ها

مجوز فایل‌ها و پوشه‌ها

مجوزهای فایل و پوشه، یکی دیگر از عواملی است که می‌تواند مانع بالا آمدن سایت پس از انتقال شود. در محیط لوکال، مجوزها اغلب آزادانه‌تر تنظیم می‌شوند، اما در سرور واقعی، محدودیت‌های دقیق‌تری اعمال می‌شود. برای راهنمای کامل، خطای 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

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

افزونه‌ها و کتابخانه‌های گمشده

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

کتابخانه‌های رایج

• GD یا Imagick: برای پردازش تصاویر
• cURL: برای ارتباط با سرویس‌های خارجی
• mbstring: برای پردازش رشته‌های چندبایتی
• json: برای پردازش داده‌های JSON
• zip: برای فشرده‌سازی و استخراج
• xml: برای پردازش داده‌های XML

بررسی کتابخانه‌های نصب‌شده

<?php phpinfo(); ?>

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

نصب کتابخانه‌های گمشده

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

غیرفعال‌سازی افزونه‌های مشکل‌دار

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

# تغییر نام پوشه افزونه‌ها
mv /path/to/wordpress/wp-content/plugins /path/to/wordpress/wp-content/plugins-disabled

# ایجاد پوشه جدید
mkdir /path/to/wordpress/wp-content/plugins

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

غیرفعال‌سازی افزونه‌ها از پایگاه داده

روش دیگر، غیرفعال‌سازی افزونه‌ها از طریق پایگاه داده است:

UPDATE wp_options
SET option_value = ''
WHERE option_name = 'active_plugins';

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

تنظیمات 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 چیست و چقدر طول می‌کشد را مطالعه کنید.

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

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

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

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

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

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

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

فعال‌سازی حالت دیباگ و بررسی خطاها

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

فعال‌سازی WP_DEBUG

در فایل wp-config.php، تنظیمات زیر را اضافه یا تغییر دهید:

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

با این تنظیمات، خطاها در فایل wp-content/debug.log ثبت می‌شوند و در صفحه نمایش داده نمی‌شوند.

بررسی فایل debug.log

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

نمایش خطاها در صفحه

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

define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );

این تنظیم، تنها در محیط توسعه توصیه می‌شود و در محیط تولید باید غیرفعال باشد.

غیرفعال کردن دیباگ در محیط تولید

پس از رفع مشکل، باید تنظیمات دیباگ را به حالت پیش‌فرض بازگردانید:

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

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

گام‌به‌گام رفع مشکل پس از مهاجرت

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

گام اول: بررسی فایل wp-config.php

• اطلاعات اتصال پایگاه داده را بررسی کنید
• مقدار DB_HOST را با مستندات هاست تطبیق دهید
• کلیدهای امنیتی را بازتولید کنید

گام دوم: بررسی آدرس سایت

• با phpMyAdmin یا WP-CLI، آدرس سایت را در پایگاه داده بررسی کنید
• در صورت نیاز، آدرس را جایگزین کنید
• پس از جایگزینی، کش را پاک کنید

گام سوم: بررسی پیوندهای یکتا

• به بخش «تنظیمات» و «پیوندهای یکتا» بروید
• ساختار را ذخیره کنید تا فایل .htaccess بازسازی شود
• فایل .htaccess را بررسی کنید

گام چهارم: بررسی مجوز فایل‌ها

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

گام پنجم: بررسی افزونه‌ها

• افزونه‌ها را غیرفعال کنید
• سایت را با قالب پیش‌فرض بارگذاری کنید
• افزونه‌ها را یکی‌یکی فعال کنید
• افزونه مشکل‌دار را شناسایی و جایگزین کنید

گام ششم: بررسی قالب

• قالب را به قالب پیش‌فرض وردپرس تغییر دهید
• در صورت رفع مشکل، قالب فعلی را بررسی کنید
• در صورت نیاز، قالب را از نسخه اصلی نصب مجدد کنید

گام هفتم: بررسی خطاها با دیباگ

• WP_DEBUG را فعال کنید
• فایل debug.log را بررسی کنید
• خطاهای شناسایی‌شده را یکی‌یکی رفع کنید

گام هشتم: بررسی DNS و دامنه

• رکوردهای DNS را بررسی کنید
• اتصال دامنه به سرور را تست کنید
• در صورت نیاز، TTL را کاهش دهید

گام نهم: تست نهایی

• سایت را در مرورگرهای مختلف تست کنید
• تمام صفحات اصلی را بررسی کنید
• فرم‌ها و بخش‌های تعاملی را تست کنید
• بخش مدیریت را بررسی کنید

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

اشتباهات رایج در انتقال از لوکال

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

عدم پشتیبان‌گیری پیش از انتقال

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

عدم جایگزینی آدرس‌ها در پایگاه داده

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

نادیده گرفتن فایل wp-config.php

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

عدم بررسی نسخه PHP و MySQL

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

نادیده گرفتن مجوز فایل‌ها

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

عدم بررسی افزونه‌ها

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

عدم بررسی قالب

قالب نیز ممکن است با سرور جدید سازگار نباشد. بررسی قالب و در صورت نیاز، نصب مجدد آن ضروری است.

عدم تست پس از انتقال

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

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

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

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

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

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

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

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

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

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

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

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

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

این مشکل، ناشی از ساختار پیوندهای یکتا و فایل .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-CLI با گزینه --precise برای جایگزینی استفاده کنید.
• فایل .htaccess را بازسازی یا با محتوای استاندارد جایگزین کنید.
• مجوز پوشه‌ها را به 755 و فایل‌ها را به 644 تنظیم کنید.
• پس از انتقال، افزونه‌ها را یکی‌یکی فعال و بررسی کنید.
• حالت دیباگ را فعال کنید تا خطاها شناسایی شوند.
• DNS و اتصال دامنه را بررسی کنید.
• سایت را در مرورگرهای مختلف و دستگاه‌های متفاوت تست کنید.
• پس از رفع مشکل، تنظیمات دیباگ را غیرفعال کنید.
• عملکرد سایت را پیش و پس از انتقال اندازه‌گیری کنید.
• برنامه بازگشت داشته باشید تا در صورت بروز مشکل، سایت به وضعیت قبلی بازگردد.

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