Comments 51
При переносе с localhost'а на реальный сервер нельзя забывать про адрес сайта. Смена домена с одновременным переносом по вашей инструкции сделает сайт абсолютно неработоспособным. По-этому в инструкцию стоит добавить ещё один шаг (актуальный при смене домена, в т.ч. — при переносе с локального сервера на боевой). Для примера будем считать, что сайд переносится с домена mysite.local на домен mysite.ru.
В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++). После замены аккуратно сохраняем БД, не забывая о кодировке (в случае с более или менее современными версиями WordPress нужна кодировка UTF-8 без BOM).
В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++). После замены аккуратно сохраняем БД, не забывая о кодировке (в случае с более или менее современными версиями WordPress нужна кодировка UTF-8 без BOM).
Большое спасибо. Подзабыл об этом, т.к. обычно на локалхосте разрабатываю под таким же доменом, как потом выкладываю в сеть.
Добавлю комментарий к топику, с вашего позволения.
Добавлю комментарий к топику, с вашего позволения.
Также после импорта базы данных можно выполнить следующую MySQL-команду:
UPDATE wp_options SET option_value = 'http://mysite.ru' WHERE option_value = 'http://mysite.local';
или использовать плагин Root Relative URLs
да меня тоже выбешивают абсолютные урлы в бд.
да меня тоже выбешивают абсолютные урлы в бд.
Немного смущает, что этот плагин уже полтора года не обновлялся. В какой-то момент он может начать некорректно отрабатывать на новых версиях WordPress. Но в целом относительные пути — это отличная вещь.
Можно проще сделать!
В файле wp-config.php добавить строки:
define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');
Тут больше способов, как сменить url сайта: codex.wordpress.org/Changing_The_Site_URL
В файле wp-config.php добавить строки:
define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');
Тут больше способов, как сменить url сайта: codex.wordpress.org/Changing_The_Site_URL
В базе данных WP может быть сотня мест, где сохранились прямые ссылки. Изменить их путем sql-запроса или путем правки строк в SQL-дампе ни в коем случае нельзя (nik_vr дал плохой совет!), так как большинство из них сериализованные. Для таких случаев придумана вот эта утилита: interconnectit.com/products/search-and-replace-for-wordpress-databases/
Её, впрочем, можно использовать и для других целей.
Её, впрочем, можно использовать и для других целей.
Спасибо. Добавлю в пост.
Ссылки, которые хранит сам WordPress у меня за 6 лет ни разу не было проблем (в плане замены). Не один десяток сайтов так перенёс. Возможно, могут быть проблемы с плагинами, которые хранят ссылки как-то нестандартно.
Что касается сериализованных данных, то не вижу особых проблем — если всё делать аккуратно, ссылки в «наборах» прекрасно заменяются.
Но за ссылку на утилиту — спасибо, интересная штука, надо будет попробовать.
Что касается сериализованных данных, то не вижу особых проблем — если всё делать аккуратно, ссылки в «наборах» прекрасно заменяются.
Но за ссылку на утилиту — спасибо, интересная штука, надо будет попробовать.
Не очень понял, что значит аккуратно делать? Вот есть у вас сериализованная строка:
Знаете, что будет, если вы её слепо замените на
Вы получите
Или под аккуратно вы имеете ввиду менять еще и число символов руками? Ну тогда это это страшная вещь, я вам скажу :)
s:17:"http://localhost/";
Знаете, что будет, если вы её слепо замените на
s:17:"http://mysupersite.com/";
Вы получите
PHP Notice: unserialize(): Error at offset 23 of 31 bytes in - on line 3
Или под аккуратно вы имеете ввиду менять еще и число символов руками? Ну тогда это это страшная вещь, я вам скажу :)
Работаю в хостинге и переношу до нескольких десятков сайтов в день. Ни разу не видел подобной проблемы. В большинстве случаев вопрос решается проходом sed по дампу базы. Иногда нужно чуть поправить конфиги.
То, что вы не встречали проблемы, еще не значит, что можно брать и менять строку на другую произвольной длины в сериализованном объекте или массиве, а с учетом того, что WP по умолчанию подавляет любые сообщения уровня Notice, то можно предполагать, что проблемы были, но вы о них недогадывались. Но чтобы не напрасно не спорить тут, просто накидайте небольшой кусочек PHP-кода и убедитесь сами в наличии проблемы.
sed'ом, думаю, можно конечно поменять и размер строки в сериализованном виде. Но выглядит это извращением.
p.s. Вордпресс по умолчанию подавляет любые сообщения уровня notice, поэтому даже если проблема есть вы её с большой вероятностью никогда не увидите, если не будете проверять на её наличие.
sed'ом, думаю, можно конечно поменять и размер строки в сериализованном виде. Но выглядит это извращением.
p.s. Вордпресс по умолчанию подавляет любые сообщения уровня notice, поэтому даже если проблема есть вы её с большой вероятностью никогда не увидите, если не будете проверять на её наличие.
Аккуратно, это значит — проверить наличие сериализованных данных. Вот сейчас, например, я открыл БД последнего сайта, который переносил подобным образом и прошёлся поиском на предмет упоминаний домена. Домен ни разу не упоминается в сериализованных данных. Все вхождения — в обычных ключах. Для примера глянул БД одного сайта на Joomla — там кругом массивы и автозамена не покатит, конечно же.
В принципе, пару раз и руками доводилось менять данные в массивах. Но не домены, кстати. По-моему в стандартных таблицах WordPress домен хранится только в отдельных ключах. Возможно какие-то плагины хранят его и в массивах, но мне пока везёт :)
В принципе, пару раз и руками доводилось менять данные в массивах. Но не домены, кстати. По-моему в стандартных таблицах WordPress домен хранится только в отдельных ключах. Возможно какие-то плагины хранят его и в массивах, но мне пока везёт :)
Во время миграции, чтобы не лазить лишний раз в MySQL удобнее намного пользоваться вот этими двумя строками wp-config
Прямые ссылки, например на картинки, сейчас Wordpress сам не проставляет, разве что пользователь сам введет какие-то, которые будут вести на старый сайт. На этот случай удобнее пользоваться плагином для поиска и замены: wordpress.org/plugins/search-and-replace/
define('WP_HOME','http://example.com');
define('WP_SITEURL','http://example.com');
codex.wordpress.org/Changing_The_Site_URL
Прямые ссылки, например на картинки, сейчас Wordpress сам не проставляет, разве что пользователь сам введет какие-то, которые будут вести на старый сайт. На этот случай удобнее пользоваться плагином для поиска и замены: wordpress.org/plugins/search-and-replace/
Буквально с месяц назад переносил сайт на WordPress 4.0 с локалхоста на сервер — ссылки на изображения в постах прямые были.
Тоже смотрю, что в визуальный редактор менеджер изображений вставляет абсолютные пути.
И не только в визуальный. Я plaintext-редактор использую — штатный загрузчик изображений и туда вставляет полные пути. Вот прямо сейчас проверил на свежем WordPress 4.1 — ничего не поменялось. В принципе, можно каждый раз ручками править, но оно кому-то надо? Не так уж часто с домена на домен приходится переносить.
(del)
Wordpress — это одна из самых лояльных к миграции систем. Тут всё настолько просто, насколько это вообще можно представить — проще только CMS без БД. Здесь ведь даже никаких подготовительных действий не нужно совершать, по большому счету.
Лучше расскажите, как осуществлять миграцию в три-четыре действия таких CMS как MODx или, прости господи, Bitrix. Вот это действительно интересно.
Лучше расскажите, как осуществлять миграцию в три-четыре действия таких CMS как MODx или, прости господи, Bitrix. Вот это действительно интересно.
Ну, для битрикса, справедливости ради, надо сказать, работает следующий способ:
1. Делаем резервную копию в папку сайта.
2. Скачиваем и заливаем архив резервной копии на нужный домен (или локально).
3. Скачиваем restore.php (ссылку на него можно найти при выполнении п.1) и закидываем рядом с архивом.
4. Запускаем site.tld/restore.php. Дождавшись распаковки сайта, вводим данные для доступа к БД.
6. Правим .htacсess, если нужно.
При грамотной работе с битриксом, в общем-то всё.
1. Делаем резервную копию в папку сайта.
2. Скачиваем и заливаем архив резервной копии на нужный домен (или локально).
3. Скачиваем restore.php (ссылку на него можно найти при выполнении п.1) и закидываем рядом с архивом.
4. Запускаем site.tld/restore.php. Дождавшись распаковки сайта, вводим данные для доступа к БД.
6. Правим .htacсess, если нужно.
При грамотной работе с битриксом, в общем-то всё.
Дочитываю Wordpress Missing Manual и буду мигрировать с Joomla.
Почти все понял, но кое-что в WP мне хочется изменить, а пока не знаю как. Например, хочется Media Library, в которой я могу сам создавать папки в любом месте в любой момент и закачивать туда картинки.
Почти все понял, но кое-что в WP мне хочется изменить, а пока не знаю как. Например, хочется Media Library, в которой я могу сам создавать папки в любом месте в любой момент и закачивать туда картинки.
Я вас огорчу, в Media Library вообще нет понятия папок. Но вы можете поискать готовое стороннее решение, или же написать своё :)
В принципе, насколько нужны папки при таком устройстве галлереи, как в WP?
я знаю, что стандартными средствами не реализовать. буду искать готовое.
Php пока не знаю. Буду учить сразу после прочтения WP. Правильнее до, но у меня поддержка моей версии джумлы заканчивается + из-за проблем с хостингом сайт глючит сильно.
Php пока не знаю. Буду учить сразу после прочтения WP. Правильнее до, но у меня поддержка моей версии джумлы заканчивается + из-за проблем с хостингом сайт глючит сильно.
Подскажу где искать.
Бесплатный плагин: wordpress.org/plugins/wp-filemanager/
Платный плагин: codecanyon.net/item/file-manager-plugin-for-wordpress/2640424
Обзор различных плагинов:
crunchify.com/top-5-file-management-plugins-for-wordpress/
Бесплатный плагин: wordpress.org/plugins/wp-filemanager/
Платный плагин: codecanyon.net/item/file-manager-plugin-for-wordpress/2640424
Обзор различных плагинов:
crunchify.com/top-5-file-management-plugins-for-wordpress/
Зачем все эти сложности в 2014-2015 году? Давно создали полностью автоматизированный плагин для таких переездов: wordpress.org/plugins/duplicator/. На старом сервере заходите в плаг — создать архив.
Создается файл архива + installer.php. Переносите их на новый сервер, запускаете installer.php. Установщик спросит вас новые логины\пароли от базы данных. Все хардлинки заменит сам.
Сохраняется всё вплоть до расположения окон в админке.
В итоге всё вместе занимает 10 минут времени.
Создается файл архива + installer.php. Переносите их на новый сервер, запускаете installer.php. Установщик спросит вас новые логины\пароли от базы данных. Все хардлинки заменит сам.
Сохраняется всё вплоть до расположения окон в админке.
В итоге всё вместе занимает 10 минут времени.
Вот именно за тем, что не все об этом знают. Спасибо за открытие, до того не слышал даже об этом плагине, хотя долгие годы работаю с WP.
Плагин по моему еще с первых версий вордпресса появился. Есть альтернативные с более красивым интерфейсом, но Duplicator мною лично опробован несколько десятков раз. Самый большой плюс — сохраняет абсолютно всё на своих местах.
Когда я только знакомился с ВП, переносил все руками. И обязательно была какая-то жопа — то настройки админки сбрасывались, то пермалинки умирали и т.п.
Когда я только знакомился с ВП, переносил все руками. И обязательно была какая-то жопа — то настройки админки сбрасывались, то пермалинки умирали и т.п.
Ещё раз большое человеческое спасибо. Я всё по-старинке, да по-старинке делал… Так надёжнее. Но если можно применить инновации, почему бы и нет?
Забыл одну ерунду…
Плагин во время запаковки сайта может упереться в php_max_execution_time или в ограничение по оперативке. Простых сайтов это не касается, но вот если это интернет-магазин на WP+WooCommerce с 5000+ товаров — может долго тупить на запаковке картинок к товарам. Приходится картинки отдельно переносить иногда. Но это обычно касается очень больших и тяжелых сайтов.
Плагин во время запаковки сайта может упереться в php_max_execution_time или в ограничение по оперативке. Простых сайтов это не касается, но вот если это интернет-магазин на WP+WooCommerce с 5000+ товаров — может долго тупить на запаковке картинок к товарам. Приходится картинки отдельно переносить иногда. Но это обычно касается очень больших и тяжелых сайтов.
Отлично сработало! Спасибо за совет.
А можете подсказать хороший форум по WP? Можно англоязычный.
Хочу до НГ перенести сайт, но чувствую, что сам на все 100% не сделаю. Надо еще и ссылки сохранить старые, как в Joomla. /category/ уже нашел как удалять через WordPress SEO by Yoast, но могут быть глюки из-за этого
Хочу до НГ перенести сайт, но чувствую, что сам на все 100% не сделаю. Надо еще и ссылки сохранить старые, как в Joomla. /category/ уже нашел как удалять через WordPress SEO by Yoast, но могут быть глюки из-за этого
А как называется ftp-менеджер на скрине «Воссоздание файловой структуры»?
Это не просто FTP, это редактор кода + FTP + SSH + MySQL + документация + ещё много чего:
panic.com/coda
panic.com/coda
Существует такая штука — wp-cli, интерфейс командной строки для WordPress. Там много разных полезных команд (я статью написал про него), в том числе для действий с базой данных, в том числе для поиска/замены в дампе с учётом сериализованных данных.
На wp-cli основан плагин WP Migrate DB Pro, который упрощает процесс переноса базы.
На wp-cli основан плагин WP Migrate DB Pro, который упрощает процесс переноса базы.
До кучи ещё один плагин для сабжа плюс бекапов: Xcloner
Ну коли такая пьянка пошла, расскажу и я про свой процесс деплоя )
1. Есть WP сайт на локалке.
2. Есть ssh досптуп на сервак
3. Есть phpmyadmin сервака
Использую git, composer, плагин wp-migrate-db.
На локалке делается git pull, после делается бэкап с помощью wp-migrate-db и сохраняется локально.
После идем на сервак, заходим в папку с сайтом и пишем git pull. Если что-то доставлялось локально (плагины или темы или еще что), то пишем composer update. После идем в phpmyadmin сервака и импортиреум сделанный wp-migrate-db ранее файл.
ВСЕ! Профит.
1. Есть WP сайт на локалке.
2. Есть ssh досптуп на сервак
3. Есть phpmyadmin сервака
Использую git, composer, плагин wp-migrate-db.
На локалке делается git pull, после делается бэкап с помощью wp-migrate-db и сохраняется локально.
После идем на сервак, заходим в папку с сайтом и пишем git pull. Если что-то доставлялось локально (плагины или темы или еще что), то пишем composer update. После идем в phpmyadmin сервака и импортиреум сделанный wp-migrate-db ранее файл.
ВСЕ! Профит.
В сохранённом дампе базы данных WordPress ищем все вхождения mysite.local и заменяем на mysite.ru. Можно это сделать в любом нормальном текстовом редакторе (например, Notepad++)
Так нельзя делать. Например, в опциях могут храниться сериализованные данные, и если вы ручками будете их править, то можете переломать всё к чертям. Используйте для этого WP-CLI либо Search-Replace-DB, а лучше ознакомьтесь с более правильным переносом
Так нельзя делать.
Вообще-то я об этом написал еще 24 декабря 2014 в 21:31. Или вы просто решили ссылочкой на свой сайт поделиться?
Search-Replace-DB
И об этом я тоже писал.
Почему бы вам вместо того, чтобы постить коммент для получения беклинка в теме, которой скоро год, не написать отдельный пост на Хабре? Пользы будет больше.
Или вы просто решили ссылочкой на свой сайт поделиться?
Полезной ссылкой чего б и не поделиться?)
Почему бы вам вместо того, чтобы постить коммент для получения беклинка в теме, которой скоро год, не написать отдельный пост на Хабре?
А смысл? Всё, что надо, уже написано, а что появится нового, так статья будет дополняться
Не могу найти информацию толковую по правильному трансферу с хостинга WP. Судя по их докам, они не дают прямого доступа к базе и по FTP нельзя тоже. Есть только миграция контента через Импорт в админке, но там переносится именно контент, а всё остальное потом руками допиливать придётся. Не понятно даже как старый добрый бэкап сделать хотя бы.
Sign up to leave a comment.
Руководство по миграции WordPress-сайта