Italiano
Español
RomânăОшибка подключения к БД после копирования экземпляра WordPress Multisite на второе местоположение
Вот моя конфигурация. У меня есть экземпляр Multisite, работающий на http://example.com, и я хочу настроить разработку и staging. Перенос существующего экземпляра Multisite WP на localhost - это кошмар, поэтому я буду вести разработку на staging-площадке.
Я настроил http://staging.example.com для указания на директорию /public_html/staging/ хостинг-аккаунта и скопировал все файлы WP из корневой директории в /staging/. Я также скопировал файлы базы данных (SQL дамп, импортировал таблицы в новую базу данных) и изменил файл wp-config.php для указания на новую базу данных.
После выполнения SQL для изменения записей базы данных, я также изменил эту строку в файле wp-config.php:
/** Включение WordPress MU, новое в 3.0 */
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'example.com' ); // <- Я меняю эту строку
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
Изменено на:
define( 'DOMAIN_CURRENT_SITE', 'staging.example.com' ); // <- теперь изменено
Когда я загружаю http://staging.example.com, я получаю... Error establishing database connection!
Я проверил и перепроверил имя пользователя и пароль, убедился, что пользователь имеет все привилегии в новой staging базе данных, и оставил DBHOST как 'localhost' (хотя изменение его на staging.example.com тоже не помогло).
Почему может не работать подключение к базе данных? Кто-нибудь? (Заранее спасибо за помощь.)
Примечание: http://example.com работает нормально с очень похожими настройками подключения к БД, просто с другой базой данных, так что проблема не в том, что сервер базы данных не работает.
К сожалению, у меня не сработало. Это идеальный пример глупости использования абсолютных путей в базе данных для WordPress.
Pegues
@Pegues это сработало для 10+ человек здесь :)
Pratik Joshi
Я рад, что сработало для других. Для многих людей это не работает - и, как я выяснил, это связано с различиями в значениях базы данных при переходе с субдомена на подкаталог. И к моему первоначальному комментарию - использование абсолютных путей в WordPress неразумно. Никогда не было разумным и является причиной множества проблем. И настройка правильного workflow с CI/CD пайплайном на enterprise уровне практически невозможна.
Pegues
Это работает нормально, за исключением случаев, когда вы заменяете строку в сериализованных данных, таких как виджеты или настройки темы, на строку с другой длиной. Сериализованные данные выглядят так - s:76:"hxxp://www-dev.example.com/wp-content/uploads/company_logo_swoosh.gif' 's:70:"hxxp://www.example.com/wp-content/uploads/company_logo_swoosh.gif' (примечание: длины 76 и 70 больше не соответствуют представленным строкам - я убрал детали своего сайта и не отслеживал новое количество символов.) Единственное решение для этого - вручную обновить счётчики - или сохранять длину домена для тестирования такой же.
marfarma
Я также заменил tt на xx, чтобы URL-адреса не были скрыты - вы не смогли бы увидеть разницу между ними.
marfarma
Это полезно знать. Это означает, что нам следует хотя бы потратить время на просмотр всех записей по мере их обнаружения и замены, вместо того чтобы заменять всё сразу.
Jeff Sebring
Вы можете использовать этот скрипт для поиска/замены сериализованных данных: https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
Costa