Скажите, если это звучит знакомо: вы встречаетесь с новым клиентом, который хочет, чтобы вы разработали новую тему для его сайта, поэтому вы создали сайт разработки и приступили к работе. Прошло несколько дней, и вы заложили основу для новой темы, и вы думаете, что пора задействовать текущий контент сайта, чтобы вы могли вникнуть в детали. Вы настраиваете WP Migrate DB Pro на обоих сайтах, извлекаете базу данных и затем понимаете, что ваш сайт разработки был установкой из подкаталога, в то время как рабочий сайт клиента был стандартной установкой из корневого каталога, а ваш сайт разработки полностью испорчен.

У WP MIGRATE DB Pro, есть нескольких подводных камней которые являются тем фактом, что он не поддерживает миграцию между стандартными инсталляциями WordPress, где WordPress’ файлы устанавливается в корневой папке папки и подкаталоги инсталляций, где WordPress’ установлены файлы в подкаталоге общественности папка. Сначала это может показаться произвольным ограничением, и многие пользователи даже не осознают, что их два сайта изначально установлены по-разному, поэтому давайте потратим несколько минут, чтобы посмотреть, как вы можете определить, является ли ваш сайт WordPress root или подкаталог, и почему сложно перейти между ними.

Как узнать, установлен ли WordPress в подкаталоге

Если вы установили WordPress вручную, вы, вероятно, знаете, выполняли ли вы установку из корневого каталога или подкаталога, но, возможно, вы унаследовали сайт или использовали установщик в один щелчок, предоставленный вашим хостом, или, может быть, прошло очень много времени с тех пор, как вы впервые настроили сайт. Если это так, все, что вам нужно сделать, это войти в систему администратора WordPress и перейти в «Настройки»> «Общие». Там вы увидите настройки «Адрес WordPress (URL)» и «Адрес сайта (URL)». Если эти две настройки совпадают, значит, у вас установлен корневой WordPress:

И если эти настройки отличаются, то вы, вероятно, смотрите на WordPress, установленный в подкаталоге:

В этом случае, если вы начали с внешнего интерфейса своего сайта на example.com, вы также, вероятно, заметили бы, что при входе в систему вы входите в систему по URL-адресу, который является подкаталогом example.com, например example.com. / wp / wp-admin /.

Почему я не могу переключаться между ними?

Что затрудняет переход из корневого каталога в установку подкаталога, так это то, что при корневой установке WordPress все ссылки и ссылки на ресурсы используют один и тот же URL-адрес, но в установках подкаталога ссылки на сообщения или страницы будут использовать URL-адрес сайта, а ссылки или ссылки на мультимедиа. или ресурсы используют URL-адрес WordPress. Таким образом, выполнение простого поиска / замены, где вы заменяете //example.localна, //example.comбольше невозможно, поскольку некоторые экземпляры //example.localнеобходимо заменить на, //example.comа другие – на//example.com/wp

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

Кроме того, вы обычно переходите между производственным или промежуточным сайтом и сайтом разработки, и все эти среды должны отражать друг друга. Если ваш производственный сайт установлен в подкаталоге, но ваш сайт разработки установлен в общедоступном корне, то изменение, которое вы делаете на своем сайте разработки, может сломаться при его переносе на производственный сайт, особенно если это изменение сделано в коде, а не в в базе данных – поскольку вам все равно нужно будет выполнить поиск и замену в базе данных для обновления URL-адресов для другой структуры, но ваш код не получит такой же обработки.

Преобразование установки из подкаталога в установку из корневого каталога

Преобразование установки из подкаталога в установку из корневого каталога почти всегда проще, чем наоборот, если это позволяет ситуация.

Чтобы преобразовать установку из подкаталога в установку из корневого каталога, нам необходимо обновить как базу данных, так и файловую структуру, в идеале с минимальным временем простоя.

Шаг 0: Определите проблему

Прежде чем что-либо делать, давайте выясним, что именно произойдет, если мы попытаемся просто перейти с установки подкаталога на корневую установку с настройками WP Migrate DB Pro по умолчанию (плюс дополнительная замена заголовка сайта, чтобы мы могли отличить их друг от друга)

Здесь я перехожу с того, wp-in-a-subdirectory.localкакой WordPress установлен в /subdirкаталоге, в wp-standard-install.localкоторый выполняется установка root.

И вот результаты (вполне ожидаемые):

Заглянув в HTML и сетевые ошибки, мы можем увидеть, что любые ссылки на другие страницы или сообщения на сайте на самом деле в порядке и все еще работают, но ссылки на любые таблицы стилей, javascript или изображения не работают, поскольку они теперь указаны wp-standard-install.local/subdir. Кроме того, если я попытаюсь войти в систему wp-admin, WordPress выполнит перенаправление на wp-standard-install.local/subdir/wp-login.php.

Шаг 1. Подготовка

Прежде чем мы действительно изменим что-либо в базе данных, мы хотим убедиться, что это не вызовет проблем с доступом к wp-admin во время процесса. Мы можем сделать это, указав URL-адреса сайта и WordPress в нашем wp-config.php перед запуском миграции. Это переопределит соответствующие настройки базы данных, что предотвратит исключение нас из wp-admin после выполнения миграции поиска / замены.



define('WP_SITEURL', 'http:

define('WP_HOME', 'http:

Теперь мы также можем изменить index.phpфайл в корне сайта, чтобы отображалось сообщение об обслуживании. Просто закомментируйте строку, require( dirname( __FILE__ )[...] закрыв тег php, и напишите приятное сообщение своим пользователям о кратком простое, которое вот-вот произойдет.

Теперь любой, кто посетит наш сайт, увидит это:

Но мы все еще можем посетить wp-admin, посетив http://wp-in-a-subdirectory.local/subdir/wp-admin/

Шаг 2: Обновите БД

Теперь все, что нам нужно сделать, это обновить базу данных, чтобы удалить все ссылки на наш подкаталог, мы можем сделать это с помощью функции поиска //wp-in-a-subdirectory.local/subdirи замены WP Migrate DB Pro, выполнив поиск и заменив ее //wp-in-a-subdirectory.local, мы также захотим запустить замену в файле. path, на случай, если в базе данных есть ссылки на файлы, для этого сайта мы будем искать /app/public/subdirи заменять на /app/public(и я снова обновляю заголовок сайта для демонстрационных целей):

После того, как мы запустим эту миграцию, мало что изменится. Передняя часть по-прежнему показывает страницу обслуживания, а бэкэнд все еще работает, потому что мы жестко запрограммировали WP_SITEURLконстанту, чтобы по-прежнему использовать подкаталог, но если вы посмотрите на некоторый контент публикации, вы заметите, что ваши изображения не работают, а внутренние ссылки теперь не хватает подкаталога:

Шаг 3. Перемещение WordPress из подкаталога

Первым, что мы будем делать теперь удалить WP_SITEURLи WP_HOMEопределение от нашего wp-config.php. Вы также можете просто обновить, WP_SITEURLчтобы удалить /subdirчасть, но их полное удаление также работает.

Как только вы это сделаете, ваш wp-admin больше не будет работать, так что давайте сразу переместим файлы. Все, что нам нужно сделать, это переместить все, что находится в subdirкаталоге, обратно в общедоступный корневой каталог нашего сайта.

Вы можете сделать это из командной строки или через SSH, если ваш сайт находится на удаленном сервере, с помощью такой команды:

Или вы можете перетащить файлы в проводник вашего браузера или в программу FTP, если вы работаете на удаленном сервере, просто не забудьте выбрать опцию перезаписи файла index.php:

Это оно!

Теперь ваш сайт больше не находится в этом ужасном подкаталоге, и вы можете без проблем перейти на другую корневую установку. Вы можете посетить, http://wp-in-a-subdirectory.localчтобы убедиться, что все работает:

Также рекомендуется войти в свой wp-admin (теперь он находится по адресу http://wp-in-a-subdirectory.local/wp-adminвместо http://wp-in-a-subdirectory.local/subdir/wp-admin), перейти к Settings> Permalinksи нажать save changesкнопку, чтобы убедиться, что ваши постоянные ссылки сброшены, а ваши URL-адреса по-прежнему будут работать.

Преобразование корневой установки в установку из подкаталога

Многие разработчики WordPress скажут вам, что установка подкаталогов – это лучшая практика, и мы, вероятно, согласимся, поскольку именно так мы рекомендуем создать новый проект WordPress. Но преобразовать существующую корневую установку в установку подкаталога немного сложнее, поскольку все наши URL-адреса в корневой установке одинаковы, но у нас есть две разные структуры URL-адресов в установке подкаталога, одна для ссылок, а другая для медиафайлов и ресурсов темы.. Это означает, что поиск / замена, которую мы запускаем в базе данных, будет немного сложнее, и мы, вероятно, также захотим выполнить некоторую ручную проверку через наш сайт после того, как все будет сказано и сделано, просто чтобы убедиться, что мы не пропустили что-нибудь.

Шаг 0: определите проблему

Прежде чем что-либо делать, давайте выясним, что именно произойдет, если мы попытаемся просто перейти с корневой установки на установку подкаталога с настройками WP Migrate DB Pro по умолчанию (плюс дополнительная замена заголовка сайта, чтобы мы могли различить их)

Здесь я перехожу с wp-standard-install.localкорневой установки, в wp-in-a-subdirectory.localкоторой установлен WordPress в /subdirкаталоге. Кроме того, если вы следите за происходящим, wp-in-a-subdirectory.localон был восстановлен, поскольку мы преобразовали его в корневую установку в предыдущем разделе.

И снова вот (полностью ожидаемые) результаты:

Подобно тому, как мы перенесли установку из подкаталога в установку из корневого каталога, перенос этой установки из корневого каталога в установку из подкаталога не привел к полной загрузке сайта; ссылки по-прежнему работают должным образом, но во всех ссылках на изображения или таблицы стилей отсутствует подкаталог. Поэтому, прежде чем мы сможем запустить эту миграцию, нам нужно преобразовать нашу корневую установку в установку из подкаталога.

Шаг 1. Подготовка

Прежде чем приступить к этому процессу, вы, вероятно, захотите увидеть, что кодекс говорит о предоставлении WordPress собственного каталога. Поскольку мы конвертируем существующий сайт, мы должны учитывать тот факт, что у нас уже есть контент, но в остальном этот процесс очень похож, и мы можем подготовить наш сайт, указав URL-адреса сайта и домашней страницы в wp-config.php и подбрасывает страницу обслуживания, как и раньше.

В этом случае нам не нужно устанавливать константы WP_SITEURLили, WP_HOMEпоскольку наш поиск / замена не коснется их, и нам нужно будет обновить настройку адреса WordPress вручную немного позже.

Однако мы можем добавить тот же код, что и раньше, на страницу в стадии разработки. Единственная разница здесь в том, что файл index.php еще не был изменен и указывал на подкаталог:

Теперь посетители будут видеть только страницу обслуживания, но мы по-прежнему можем получить доступ к wp-admin, посетив http://wp-standard-install.local/wp-admin/

Шаг 2: Обновите базу данных

Мы переместим WordPress в /subdirподкаталог с подходящим названием, поэтому нам нужно обновить базу данных, чтобы использовать подкаталог, но только для URL-адресов, которые будут содержаться в подкаталоге. Ранее мы видели, что нужно обновить только ссылки на файлы изображений и, возможно, любые ссылки на ресурсы, содержащиеся в папках тем или плагинов, и все они находятся под ними /wp-content, поэтому мы можем использовать это для таргетинга на URL-адреса, которые нам нужно изменить путем поиска. for //wp-standard-install.local/wp-contentи заменив его на //wp-standard-install.local/subdir/wp-content.

Кроме того, мы хотим заменить все строки, содержащие путь к файлу, чтобы использовать подкаталог, и здесь мы можем найти путь к нашему общедоступному корневому файлу /app/publicи добавить подкаталог /app/public/subdir, поскольку мы перемещаем все в подкаталог. Вот как это будет выглядеть при использовании миграции Find / Replace в WP Migrate DB Pro (и снова включая обновление заголовка сайта):

И снова, если мы проверим содержание публикации после запуска этой миграции, мы должны увидеть, что наши ссылки на другие страницы на сайте не включают подкаталог, но любые встроенные изображения включают:

Теперь, когда наша база данных обновлена, мы можем работать над перемещением WordPress в подкаталог. По большей части мы можем просто следовать процессу, описанному в разделе «Метод II (с изменением URL-адреса)» в той статье кодекса, которую я упоминал ранее, но я также расскажу об этом здесь.

Первое, что вам нужно сделать, это обновить настройку адреса (URL) WordPress, чтобы использовать подкаталог. Это нарушит внутреннюю часть вашего сайта, поэтому убедитесь, что вы закончили работу с администратором, а затем перейдите в Настройки> Общие и добавьте имя подкаталога в конец адреса WordPress:

Как только вы прокрутите страницу вниз и нажмете «сохранить изменения», вы перейдете на страницу обслуживания. Это происходит потому, что WordPress теперь думает, что все файлы wp-admin находятся в папке, /app/public/subdir/wp-adminпоэтому он пытался перенаправить нас, http://wp-standard-install.local/subdir/wp-login.phpно этот файл еще не существует, поэтому вместо этого нам отображается страница обслуживания.

Шаг 3. Перемещение файлов WordPress в подкаталог

Теперь, когда наш сайт полностью непригоден для использования, нам нужно исправить это, переместив файлы туда, где их ожидает WordPress. Первое, что мы сделаем, это создадим subdirподкаталог в нашем публичном корне, а затем переместим в него все. Затем мы скопируем файлы index.php и .htaccess /subdirобратно в общедоступный корневой каталог, чтобы наша страница обслуживания продолжала отображаться, пока мы закончим.

Затем мы можем восстановить index.php внутри подкаталога до заводского состояния, удалив служебный html и раскомментировав require( dirname( __FILE__) [...]строку:

Теперь вы должны снова получить доступ к своему администратору WordPress, перейдя в http://wp-standard-install.local/subdir/wp-admin/

Вы можете еще раз воспользоваться этой возможностью, чтобы проверить весь свой контент, чтобы убедиться, что все работает правильно и изображения отображаются правильно.

Теперь все, что осталось сделать, это обновить index.phpфайл, который находится в нашем общедоступном корне, чтобы вывести сайт из режима обслуживания, а также обновить оператор require, чтобы он находился в wp-blog-header.phpновом месте в нашем новом подкаталоге. Этот файл должен выглядеть так:

Это оно!

Теперь ваш сайт больше не привязан к этой ужасно плоской файловой структуре, и вы можете без проблем перейти на другую корневую установку. Вы можете посетить, http://wp-standard-install.localчтобы убедиться, что все работает:

И снова, также неплохо войти в систему своего администратора и перейти к Settings> Permalinksи нажать save changesкнопку, чтобы убедиться, что ваши постоянные ссылки сброшены, а ваши URL-адреса по-прежнему будут работать.

Подведение итогов

Теперь вы, вероятно, думаете про себя, что вся эта статья основана на том факте, что WP Migrate DB Pro не поддерживает миграцию из корневой установки в установку подкаталога (или наоборот), но мы использовали WP Migrate DB Pro для преобразования эти сайты на месте, ну и что это дает ?! Разве я не могу просто запустить миграции, которые сделают правильный поиск / замену и завершат работу?

Вы, конечно, можете выполнять миграции туда и обратно между сайтами, которые установлены по-разному, но вам действительно нужно знать все, что о них отличается, и хотя сайты, которые мы преобразовали в этой статье, содержали контент, который нужно было обновить, у них не было множество плагинов, которые могут потребовать дополнительного внимания. В конце концов, это, вероятно, возможно, но поскольку WP Migrate DB Pro не может сделать это за вас автоматически, разумным шагом будет сначала убедиться, что оба ваших сайта установлены одинаково, прежде чем вы начнете выполнять миграции. между ними. Соответствие структуры каталогов ваших сайтов не только упрощает миграцию, но и помогает вам быть более уверенным в том, что при разработке и развертывании все будет работать одинаково на обоих сайтах.

Вы согласны с тем, что оба ваших сайта должны использовать одинаковую структуру каталогов? Или вы можете придумать вескую причину, по которой вы хотели бы мигрировать между двумя сайтами, которые были установлены по-разному? Мы обсуждали это в выпуске github уже почти 3 года:

Так что, возможно, пришло время задать вам вопрос: думаете ли вы, что WP Migrate DB Pro должен поддерживать миграцию между сайтами, которые установлены по-разному, или вы согласны с нашей текущей позицией, что вам следует сначала преобразовать один из своих сайтов, прежде чем начинать? перемещать данные между ними? Дайте нам знать об этом в комментариях!

Источник записи: https://deliciousbrains.com