Ошибка подключения к БД после копирования экземпляра WordPress Multisite во второе местоположение


11

Вот мои настройки. У меня есть экземпляр Multisite, работающий по адресу http://example.com , и я хочу заняться разработкой и подготовкой. Перемещение существующего мультисайтового экземпляра WP на localhost - это кошмар, поэтому вместо этого я собираюсь создать dev в промежуточной локации.

Я настроил http://staging.example.com, чтобы он указывал на каталог / public_html / staging / учетной записи хостинга, и скопировал все файлы WP из моего корня в каталог / staging /. Я также скопировал файлы базы данных (дамп SQL, импортировал таблицы в новую базу данных) и изменил файл wp-config.php, чтобы он указывал на новую базу данных.

После запуска SQL для изменения записей базы данных я также изменил эту строку в файле wp-config.php:

/** Turning on WordPress MU, new in 3.0 */
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'example.com' ); // <- I change this line
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Изменился на:

define( 'DOMAIN_CURRENT_SITE', 'staging.example.com' ); // <- now changed

Когда я загружаю http://staging.example.com , я получаю ... Error establishing database connection!

Я проверил и трижды проверил имя пользователя и пароль, убедился, что у пользователя есть все привилегии для новой промежуточной базы данных, и я оставил DBHOST как «localhost» (хотя его изменение на staging.example.com не помощь тоже).

Почему сбой соединения с базой данных? Кто-нибудь? (Заранее спасибо за помощь.)

NB: http://example.com отлично работает на очень похожих настройках соединения с БД, только с другой базой данных, так что проблема с отключением сервера базы данных не возникает.


Хм. Никто, а? Это странная ошибка, конечно.
Джейсон Родс

У меня та же ошибка при попытке выполнить миграцию Wordpress Network на месте - хост не перемещен
Mikko Ohtamaa

ОК. Я выследил различные способы сбоев и сделал из них запись в блоге: opensourcehacker.com/2011/08/22/…
Микко Охтамаа

Ответы:


2

Одна мысль - когда я захожу на www.example.com/staging/wp-admin, он автоматически перенаправляет меня на www.example.com/wp-admin.

Может ли перенаправление с staging.example.com на example.com/staging конфликтовать с существующей установкой?

ОБНОВЛЕНИЕ: похоже, это может быть связано с проблемами .htaccess и сложными ссылками на домен в базе данных.

Из Кодекса РГ:

Перемещение WordPress Multisite

Multisite гораздо сложнее перемещать, так как сама база данных имеет несколько ссылок на имя сервера, а также на расположение папок.

Лучший способ переместить мультисайт - это переместить файлы, отредактировать .htaccess и wp-config.php (если имя папки, содержащее мультисайт, изменилось), а затем вручную отредактировать базу данных. Найдите все экземпляры вашего доменного имени и при необходимости измените их. Этот шаг еще не может быть легко автоматизирован. Если вы перемещаете Multisite из одной папки в другую, вам нужно будет отредактировать записи wp_blogs, чтобы правильно изменить имя папки.


11

Я решил это, и это сработало :)

В wp_blogsтаблице,

Старая структура была

Domain : localhost/smart_facility_linux
Path : /

Но я изменил его, чтобы он работал следующим образом:

Для корневого сайта:

Domain : localhost
Path : /smart_facility_linux/

Для под сайта 1 (любой дочерний сайт под основным сайтом, я только что привел пример):

Domain : localhost
Path : /smart_facility_linux/subsite1/

К сожалению, не работает для меня. Это прекрасный пример глупости использования абсолютных путей в базе данных для WP.
Pegues

@Pegues он сделал работу для 10+ людей здесь :)
Pratik

1
Я счастлив, что это сработало для других. Это не работает для очень многих людей - и из того, что я исследовал, это потому, что есть разница в значениях дБ при переключении с поддомена на подкаталог. И, к моему первоначальному комментарию, использование абсолютных путей не является мудрым для WP. Никогда не было и является причиной стольких проблем. А на корпоративном уровне наладить надлежащий рабочий процесс с помощью конвейера CI / CD не представляется возможным.
Pegues

2

На самом деле есть только один способ сделать простой перенос домена или хоста, который я нашел. Это работает безупречно для меня на одно- и многосайтовых установках.

  1. Экспортируйте свою базу данных в файл .sql. (Я использую PHPMyAdmin для этого)
  2. Создайте новую копию файла для редактирования с немного другим именем.
  3. Откройте файл в предпочитаемом вами текстовом редакторе> (например, gedit)
  4. Запустите поиск / замену в домене И абсолютный путь (/ home / username / public_html / to / home / username / public_html /) от производства до dev.
  5. Сохраните файл.
  6. Скопируйте всю установку в ваш каталог разработки.
  7. Добавьте следующую строку в ваш файл wp-config.php:

    DEFINE ( ​​'RELOCATE', правда);

  8. Войдите в систему и сохраните настройки постоянных ссылок.

  9. Удалите определенное правило, которое вы поместили в свой wp-config.php.


1
Это работает нормально, за исключением случаев, когда вы в конечном итоге заменяете строку в сериализованных данных, таких как виджет или параметр темы, строкой с другой длиной. Сериализованные данные выглядят так: s: 76: "hxxp: //www-dev.example.com/wp-content/uploads/company_logo_swoosh.gif": 70: "hxxp: //www.example.com/ wp-content / uploads / company_logo_swoosh.gif '(примечание: длины 76 и 70 больше не соответствуют представленным строкам - я отредактировал детали своего сайта и не отслеживал количество новых символов.) Единственное решение для этого - обновить счетчики вручную - или оставить длину промежуточного домена такой же.
Марфарма

Я также заменил tt на xx, чтобы URL-адреса не были скрыты - вы не могли видеть разницу между ними.
Марфарма

Это хорошо знать. Это означает, что мы должны, по крайней мере, потратить время на просмотр всех записей, когда они найдены и заменены, а не заменять все.
Джефф Себринг

1
Вы можете использовать этот скрипт для поиска / замены сериализованных данных: interconnectit.com/products/…
Коста,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.