انتقال وردپرس بدون افزونه؛ راهنمای دستی و امن

خطای «Error establishing a database connection» را دیده‌اید؟

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

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

پیش‌نیازها: چه چیزهایی لازم دارید؟

پیش از شروع، این ابزارها را آماده کنید:

• دسترسی SSH به هر دو سرور (مبدأ و مقصد) — اگر فقط cPanel دارید، بخش جایگزینی URL با WP-CLI را از File Manager هم می‌توانید انجام دهید، اما SSH کار را بسیار ساده‌تر می‌کند.
• دسترسی به phpMyAdmin یا خط فرمان MySQL در سرور مقصد.
• یک دامنه که DNS آن به سرور جدید اشاره کرده باشد. اگر DNS را هنوز تغییر نداده‌اید، می‌توانید از فایل /etc/hosts در سیستم محلی خود استفاده کنید تا سایت را قبل از انتقال رسمی تست کنید.

نسخه PHP و MySQL را هم چک کنید. وردپرس ۶.۴ به PHP 7.2 یا بالاتر نیاز دارد، اما اجرای آن روی PHP 8.1 یا 8.2 توصیه می‌شود. اگر هاست مقصد PHP 5.6 دارد، متوقف شوید و ابتدا آن را ارتقا دهید.

مرحله ۱: کپی فایل‌ها با rsync، نه FTP

انتقال فایل‌ها با FTP پر از اشکال است: قطع شدن اتصال در فایل‌های حجیم، از دست رفتن مجوزهای فایل (permissions)، و سرعت پایین. از rsync استفاده کنید که هم سرعت بالاتری دارد و هم مجوزها و ownership را حفظ می‌کند.

rsync -avz --progress /home/user/public_html/ user@new-server:/var/www/html/

فلگ -a یعنی archive mode و symlinkها، مجوزها و timestamps را حفظ می‌کند. فلگ -z فشرده‌سازی را فعال می‌کند که برای انتقال از طریق اینترنت ضروری است. اگر فایل‌های حجیم مثل ویدیو دارید، فلگ --partial را هم اضافه کنید تا در صورت قطع اتصال، از همان‌جا ادامه یابد.

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

این‌جا اشتباه می‌کنند: فراموش کردن پوشه‌های مخفی مثل .htaccess و .user.ini. اگر از FTP استفاده می‌کنید، این فایل‌ها را نمی‌بینید و منتقل نمی‌شوند. نتیجه؟ سایت لود می‌شود اما permalinkها کار نمی‌کنند یا خطای 500 می‌گیرید. با rsync این مشکل وجود ندارد، چون همه فایل‌ها را منتقل می‌کند.

مرحله ۲: دامپ دیتابیس با mysqldump

حالا نوبت دیتابیس است. در سرور مبدأ، این دستور را اجرا کنید:

mysqldump -u username -p --single-transaction --quick --lock-tables=false database_name > database_backup.sql

فلگ --single-transaction برای جداول InnoDB ضروری است؛ بدون آن، دامپ شما ممکن است ناسازگار باشد و جداول را در حالی که در حال نوشتن هستند، کپی کند. فلگ --quick هم برای دیتابیس‌های بزرگ لازم است تا خروجی به جای نگهداری در حافظه، مستقیم روی دیسک نوشته شود.

اگر دیتابیس شما بزرگ است (بیش از ۱ گیگابایت)، خروجی را فشرده کنید:

mysqldump -u username -p --single-transaction database_name | gzip > database_backup.sql.gz

سپس فایل را به سرور مقصد منتقل کنید و آنجا import کنید:

gunzip -c database_backup.sql.gz | mysql -u username -p database_name

اگر دیتابیس مقصد را هنوز نساخته‌اید، اول با cPanel یا دستور CREATE DATABASE آن را بسازید. نام کاربری و رمز عبور دیتابیس جدید را هم یادداشت کنید؛ در مرحله بعد به آن نیاز دارید.

مرحله ۳: ویرایش wp-config.php

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

define( 'DB_NAME', 'new_database_name' );
define( 'DB_USER', 'new_database_user' );
define( 'DB_PASSWORD', 'new_database_password' );
define( 'DB_HOST', 'localhost' );

مقدار DB_HOST معمولاً localhost است، اما برخی هاست‌ها از آدرس دیگری مثل mysql.example.com استفاده می‌کنند. این اطلاعات را از صفحه مدیریت دیتابیس هاست خود بردارید.

اگر کلیدهای امنیتی (Authentication Unique Keys) را هم عوض کنید، بهتر است. این کار باعث می‌شود همه کاربران از سیستم خارج شوند و نشست‌های قدیمی باطل شوند. این کلیدها را می‌توانید از این صفحه بگیرید.

مرحله ۴: جایگزینی URL با WP-CLI

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

روش اشتباه: استفاده از کوئری SQL ساده مثل UPDATE wp_options SET option_value = 'new_url' WHERE option_name = 'siteurl'. این کار فقط دو فیلد را عوض می‌کند و بقیه لینک‌ها در جداول wp_posts، wp_postmeta و wp_options دست‌نخورده می‌مانند.

روش درست: WP-CLI. اگر به سرور مقصد SSH دارید، این دستور را از پوشه ریشه وردپرس اجرا کنید:

wp search-replace 'http://old-domain.com' 'http://new-domain.com' --all-tables --precise

فلگ --all-tables همه جداول وردپرس را بررسی می‌کند، نه فقط جداول پیش‌فرض. اگر افزونه‌هایی نصب کرده‌اید که جداول خودشان را دارند (مثل WooCommerce یا Yoast)، این فلگ ضروری است. فلگ --precise هم از جایگزینی اشتباه رشته‌هایی که بخشی از کلمه بزرگ‌تر هستند جلوگیری می‌کند.

اگر WP-CLI روی سرور نصب نیست، می‌توانید از اسکریپت Search Replace DB استفاده کنید. این اسکریپت را در پوشه ریشه آپلود کنید، از مرورگر اجرا کنید و بعد از اتمام، حتماً آن را حذف کنید. این فایل یک آسیب‌پذیری امنیتی جدی است اگر روی سرور بماند.

یک جایگزین دیگر: افزونه «Better Search Replace» را موقتاً نصب کنید، جایگزینی را انجام دهید و سپس افزونه را حذف کنید. این روش برای کسانی که به SSH دسترسی ندارند کار می‌کند، اما به خاطر داشته باشید که افزونه را حذف کنید.

این‌جا اشتباه می‌کنند: فراموش کردن http در مقابل https. اگر سایت قبلی با HTTPS کار می‌کرد و سایت جدید هم HTTPS دارد، رشته جایگزینی باید دقیقاً شامل https:// باشد. اگر فقط http://old-domain.com را جایگزین کنید، لینک‌هایی که با https:// ذخیره شده‌اند دست‌نخورده می‌مانند و نیمی از سایت خراب می‌شود.

مرحله ۵: چک‌لیست بعد از انتقال

انتقال فایل‌ها و دیتابیس تمام شد. حالا نوبت بررسی است. این چک‌لیست را به ترتیب اجرا کنید:

1. صفحه اصلی سایت را باز کنید. اگر خطای 500 گرفتید، فایل wp-config.php را بررسی کنید و define( 'WP_DEBUG', true ); را اضافه کنید تا خطای واقعی را ببینید.
2. یک نوشته و یک برگه را باز کنید و مطمئن شوید permalinkها درست کار می‌کنند. اگر 404 گرفتید، به تنظیمات permalink بروید و دوباره ذخیره کنید تا فایل .htaccess بازنویسی شود.
3. یک تصویر از کتابخانه رسانه باز کنید و آدرس آن را چک کنید. اگر به دامنه قدیمی اشاره می‌کند، مرحله جایگزینی URL را دوباره انجام دهید.
4. یک نوشته جدید بسازید و منتشر کنید. این کار مطمئن می‌شود که دیتابیس قابل نوشتن است و cron jobs وردپرس درست کار می‌کنند.
5. فرم تماس یا هر فرم دیگری را تست کنید. اگر از SMTP استفاده می‌کند، تنظیمات ایمیل را هم بررسی کنید.
6. سایت را با تست سرعت سایت بررسی کنید. اگر TTFB بالاست، احتمالاً کش سرور مقصد را فعال نکرده‌اید یا PHP-FPM تنظیمات بهینه ندارد.

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

انتقال از هاست اشتراکی به هاست لینوکس اختصاصی

اگر از هاست اشتراکی به هاست لینوکس یا سرور مجازی منتقل می‌شوید، یک تفاوت مهم وجود دارد: ownership فایل‌ها. در هاست اشتراکی، فایل‌ها معمولاً متعلق به کاربر شما هستند. در سرور مجازی، باید مطمئن شوید فایل‌ها متعلق به کاربری هستند که PHP با آن اجرا می‌شود (معمولاً www-data یا کاربر cPanel).

chown -R www-data:www-data /var/www/html/

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

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

اگر دیتابیس شما بیش از ۲ گیگابایت است، روش استاندارد دامپ و import ممکن است با خطای timeout مواجه شود. در این حالت، به جای دامپ کل دیتابیس، جداول را جداگانه دامپ کنید:

mysqldump -u username -p --single-transaction database_name wp_posts wp_postmeta > content_tables.sql

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

پرسش‌های پرتکرار

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

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

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

جایگزینی URL را کامل انجام نداده‌اید. دستور wp search-replace را دوباره اجرا کنید و مطمئن شوید هر دو حالت http:// و https:// را پوشش داده‌اید. همچنین کش مرورگر و کش DNS را پاک کنید.

خطای 500 بعد از انتقال وردپرس؛ از کجا شروع کنم؟

اول فایل wp-config.php را بررسی کنید و define( 'WP_DEBUG', true ); را اضافه کنید. خطای واقعی را می‌بینید. شایع‌ترین علت، مجوزهای اشتباه فایل یا عدم تطابق نسخه PHP است. اگر خطایی نمایش داده نشد، فایل .htaccess را موقتاً حذف کنید.

آیا می‌توانم سایت را قبل از تغییر DNS تست کنم؟

بله. فایل /etc/hosts را در سیستم محلی خود ویرایش کنید و آدرس IP سرور جدید را به دامنه خود نسبت دهید. به این ترتیب فقط از سیستم شما، سایت با دامنه جدید لود می‌شود و بقیه کاربران همچنان هاست قبلی را می‌بینند.