Перенос сайта с локальной сборки на онлайн-сервер является один из самых распространенных случаев миграций WordPress. Если вы занимаетесь разработкой веб-сайта на локальном компьютере, и вам требуется загрузить его на хостинг, чтобы показать своим клиентам или членам команды разработки, вам понадобится переместить свой сайт на онлайн-сервер. В данном случае вам понадобится переместить три компонента:
- Сам WordPress – вам нужно будет установить систему на новом месте;
- Базу данных – вы можете ее перенести с помощью phpMyAdmin;
- Файлы вашей темы, ее загрузки и плагины;
Итак, процесс переноса сайта с локального компьютера на хостинг состоит из следующих шагов.
1. Выключаем постоянные ссылки.
Отключаем постоянные ссылки на экране «Permalinks», который находится в меню «Settings». Установим их по умолчанию, выбрав пункт «Default» и щелкнув по кнопке «Save Changes».
2. Делаем бэкап базы данных.
Создаем копию базы данных и даем ей новое название (к примеру, добавив префикс «old» к ее старому названию).
3. Устанавливаем WordPress на новом месте и загружаем контент.
Устанавливаем WordPress на онлайн-сервер. С помощью FTP или SFTP копируем файлы из локальной папки «wp-content» в аналогичную папку на сервере, сохраняя ту же самую файловую структуру, что и в локальной сборке.
Уходим пить кофе, поскольку эти файлы обычно загружаются достаточно долго.
4. Редактируем базу данных.
Просто открыть оригинальный файл базы данных из локальной сборки и отредактировать его не получится. Данные в БД сериализированы, поэтому их нельзя редактировать с помощью обычных текстовых редакторов. Лучше всего для этого воспользоваться специальным инструментом Search-Replace-DB. Замените старый URL-адрес, относящийся к локальной сборке, на новый URL-адрес, относящийся к онлайн-сайту.
К примеру, если ваш старый URL был http://localhost/example, то вам понадобится изменить его, допустим, на http://example.com.
Использование команды replace позволит заметно ускорить данный процесс – в базе данных могут быть храниться тысячи таких экземпляров. Сохраняем базу данных.
5. Удаляем существующую базу данных на хостинге.
Примечание: данный шаг применим только в том случае, если вы использовали для установки WordPress скрипты, такие как Softaculous или Fantastico, поскольку эти скрипты автоматически создают базу данных. Если вы устанавливали WordPress вручную, вы можете проигнорировать данный шаг.
В phpMyAdmin удалите базу данных, которая была создана на сайте при установке WordPress:
Выбираем базу данных, которая нам требуется.
Щелкаем по вкладке Structure
Сразу под списком таблиц выбираем Check All
В выпадающем меню выбираем пункт With selected, после чего пункт Drop.
Вылезет предупреждение, спрашивающее, действительно ли вы желаете удалить все таблицы. Щелкаем Yes.
В конце концов вы увидите сообщение, которое сообщит вам, что все прошло успешно:
6. Загружаем новую базу данных.
Пока вы находитесь в phpMyAdmin, загрузите базу данных, которую вы ранее отредактировали:
Переходим к вкладке Import
Щелкаем по кнопке Choose file
Выбираем базу данных, сохраненную на шаге 4, после чего щелкаем Choose или OK.
Через некоторое время (в зависимости от размера базы данных) мы увидим сообщение, что загрузка была успешно завершена.
7. Чистим кэш браузера.
Чтобы избежать разных проблем, очистим на всякий случай кэш браузера (вдруг он будет использовать кэшируемый контент из старой версии удаленной базы данных).
8. Заходим в панель администратора на сайте и обновляем постоянные ссылки.
Ваш логин и ваш пароль будут теми же самыми, что и в локальной сборке. Если вы устанавливали иные данные для входа в консоль на сайте, они будут переписаны данными, хранящимися в импортируемой БД.
Переходим к экрану Permalinks и возвращаем обратно постоянные ссылки.
Все готово!
Источник: wp.smashingmagazine.com
Я делал проще. Сохранял базу данных в файл, открывал его notepad++ и через поиск и замену менял везде адрес сайта с mytestsite.ru на нужный, ну и в настроках конфиг файла WP естественно и загружал на хостинг и всё.
Кстати пользуюсь денвером, а там есть возможность создавать сайт непосредственно с настоящим адресом, а не с адресом вида http://localhost/mytestsite. В таком случае, если адреса сайтов совпадают, то и менять ничего не нужно, кроме конфиг файла на хостинге, т.к. там свои названия баз данных.
Редактировать БД напрямую не советуют, потому что некоторые данные там хранятся в сериализованном виде, и можно ее просто повредить.
Что значит «в сериализованном виде»?
http://php.net/manual/ru/function.serialize.php
http://ru.wikipedia.org/wiki/Сериализация
А как пользоваться Search-Replace-DB? И есть ли другие способы переноса сайта?
На Github в разделе Usage описано использование скрипта. Шаги переноса те же самые, могут лишь незначительно отличаться в плане применяемых для этого инструментов.
Спасибо. Я сразу не понял, что БД редактируется в локальной установке.
Спасибо, всё замечательно работает!!!
Не за что!)
Дитьотй, добрый день.
Пожалуйста, опишите, подробней, как пользоваться скриптом Search-Replace-DB.
Прочитала Usage, но не совсем понятно, куда именно подгружать его.
Заранее благодарна!
Дмитрий, добрый день :)
Со скриптом разобралась. После этого нужно сделать еще одну копию БД в phpmyAdmin? И снова подгрузить через фтп-клиент на реальный сервер?
Спасибо.
Не совсем понял про копии.
Если вы про пятый шаг, то надо смотреть по ситуации, в зависимости от того, был ли предустановлен WP на ваш хостинг.
Дмитрий а какому хостеру вы отдаете предпочтение?
У меня хостинг — Агава.
Спасибо за статью, но у меня это так и не вышло сделать, хорошо что хостер Handyhost сам все перенес к себе на хостинг
У меня возник вопрос. А если не включать постоянные ссылки в режим по умолчанию, могут ли возникнуть проблемы с ними на хостинге?
Немного предыстории. Заказала небольшая компания мне сайт на WordPress. В качестве демо установил локально на свой ноут на xampp или wamp (уже точно не помню). Сайт настроил, кое-где подправил код, установил всё необходимое, наполнил контентом. Показал заказчику. Всё понравилось. Решили залить на их сервер CentOS. Заливал всё сам, так как своего админа у них не было. Перед установкой удалил сайт на Drupal. В настройке ссылок ЧПУ на тот момент необходимости не было, но через год компания решила продвинуть свой сайт по SEO. Опять обратились ко мне. И тут я обнаружил, что произвольные ссылки не работают… Что делать, как исправить, в каком направлении двигаться? Ума не приложу. С CentOS дело имею в первый и пока единственный раз.
CentOS v. 6.6
Apache v. 2.2.15
php v. 5.3.3
MySQL v. 14.14
Wordpress v. 4.8.3
Посмотрите вот тут:
https://www.digitalocean.com/community/questions/wordpress-permalinks-centoos-7
Здесь для Centos 7 приводится решение, но, возможно, что и для вашей версии подойдет.
Здравствуйте! Сделала сайт на локальном сервере хамп. С базой данных и фтп файлами понятно. Не пойму 1 шаг — установка ВордПресса на новом месте. Если я его устанавливаю, то автоматически создаются, кажется, 18 файлов и 3 папки. Точно такие же как на моём локальном сервере. Мне их удалять получается, чтоб свои закачать??? Если я их удалю, то удалится и движок, или что-то не так поняла. Дмитрий, если можно первый шаг поподробнее пожалуйста
Загружаете с заменой. Ваша папка с xamp должна заменить соответствующую папку на вашем сервере.
Дмитрий, спасибо огромное!!! Всё получилось!
Здравствуйте, Дмитрий! Переношу сайт на VPS хостинг с локального сервера. Всё идёт не так гладко, как хотелось бы. Разрешите уточнить некоторые моменты:
1 — после переноса при попытке входа в панель управления WordPress начинается его установка. Хотя я в wp-config базу данных, пользователя, пароль и имя сервера прописал как нужно, в options БД siteurl и homeurl поменял с .loc на .ru. Соединение с базой данных есть. Где ещё я мог что-то не учесть?
2 — на локальном сервере у меня был настроен двойной вход для администратора через .htaccess и .htpasswd. Там всё работает. На хостинге же форма появляется просто при заходе на сайт. Хотя путь до .htpasswd я прописал. Естественно, если я переименовываю .htaccess в папке wp-admin, то к сайту обращение есть и, как в пункте 1, начинается установка WordPress.
3 — самый непонятный для меня. При импорте базы данных появилась одна ошибка:
Error
SQL query:
ALTER TABLE `wp_posts` ADD FULLTEXT KEY `yarpp_title` (`post_title`);
MySQL said: Documentation
#1214 — The used table type doesn’t support FULLTEXT indexes
делаю то, что сказано на по этой ссылке — https://mattgadient.com/how-to-remove-a-fulltext-index-in-mysql-switching-from-myisam-to-innodb/ — после этого первая ошибка исчезает, но появляется другая:
Error
SQL query:
— Indexes for table `wp_wc_avatars_cache`
ALTER TABLE `wp_wc_avatars_cache`
ADD PRIMARY KEY (`id`),
ADD UNIQUE KEY `user_email` (`user_email`),
ADD KEY `user_id` (`user_id`),
ADD KEY `url` (`url`),
ADD KEY `hash` (`hash`),
ADD KEY `maketime` (`maketime`),
ADD KEY `cached` (`cached`);
MySQL said: Documentation
#1071 — Specified key was too long; max key length is 767 bytes
Если я хоть что-то понимаю в этом, то myISAM и InnoDB это разные форматы таблиц данных. То есть для Yet Another Related Posts Plugin судя по указаниям нужна InnoDB, а для wpDiscuz — myISAM. Наверное, надо как-то точечно задать это для них.
Надеюсь, не сильно Вас загрузил. Если не получится решить пункт №1 вручную, тогда попробую плагин Duplicator.
Да, с Duplicator то же проблема — Database Notices: Critical Error. В панели управления появилось сообщение — There has been a critical error on your website. Please check your site admin email inbox for instructions. Из-за ошибки все страницы не найдены. Да, буду разбираться.
>Наверное, надо как-то точечно задать это для них.
Можно выборочно конвертировать таблицы в нужный формат. Как пример, тут описано туда-обратно: https://ok2web.ru/myisam-protiv-innodb-mysql-engine-dlja-wordpress-chto-luchshe/
Я написал в службу поддержки хостинга. Оказалась причина всего в том, что на сервере версия mySQL 5.5, а на локальном сервере была выбрана в самом начале разработки сайта (уже 1 год прошёл с того момента) версия 5.7. Я, естественно, об этом не знал и в уроке по Open Server автор просто сказал последние версии поставить. Не знаете можно ли как-то саму базу данных понизить до 5.5 версии?
Эх, если заново всё делать, ещё пару месяцев посидеть нужно будет, чтобы вручную все плагины настроить и страницами наполнять.
>Database Notices: Critical Error.
Если Duplicator сигнализирует о проблемах, то значит, есть более серьезные косяки с БД, надо разобраться. Возможно, неверно что-то задано в ней.
Даунгрейд сделать можно, но нужно будет проходить по всем основным версиям.
Т.е. сразу с 5.7 к 5.5 не получится сделать переход.
Я скачал Navicat, экспортировал таблицы в csv и импортировал в OpenServer в версию mySQL 5.6. Сайт недогружается, а вверху выходит сообщение (то же самое при входе в админ панель) Warning: Invalid argument supplied for foreach() in D:\OSPanel\domains\site.loc\wp-includes\class-wp-roles.php on line 288 Не знаете что это може быть? И вообще правильно ли я делаю? Уроков не нашёл по понижению версии — в основном все по повышению. Но примерно же алгоритм похожий? У Вас есть какие-нибудь ссылки на статьи по этому вопросу?
Если не получится, буду вручную создавать и наполнять страницы (их уже 50 объёмных), статей пока благо нет, картинки все исчезли и сбились настройки плагинов. Эх, ну не знал я что, надо было версию 5.5 ставить. В уроке одного автора он так и сказал «Ставьте самую свежую версию». Но почему-то хостинги на 5.5 работают. Хотя оно и понятно — для совместимости.
Здесь больше писать не буду, чтобы не тревожить Вас лишний раз — итак за всё время много у Вас спросил и плодотворно.
Про даунгрейд советую посмотреть тут: http://mysql.babo.ist/#/en/downgrading.html
По поводу проблемы: что-то связано с ролями и права доступа. Посмотрите ответ тут, возможно, даст какие-либо подсказки: https://wordpress.org/support/topic/after-updating-to-wordpress-4-9-7-i-am-having-major-problems-with-user-roles/
Здравствуйте, Дмитрий! Повторил действия с Navicat, только перед самим экспортом выбрал режим — Copy (очистка и перезаполнение таблиц). И… сработало. Теперь с настройками php5.5 сайт на локальном сервере работает. В базе данных сохранилось всё, кроме рубрик и меток, что не так плачевно. Исчезла ошибка — «Warning: Invalid argument supplied for foreach() in D:\OSPanel\domains\site.loc\wp-includes\class-wp-roles.php on line 288».
Но даже база 5.5 не помогла — опять запускается установка WordPress при импорте базы на удалённый сервер. Я плюнул и сказал сисадминам хостинга, чтобы поставили сайт и убрали установку, но и они 3 часа возились и ничего не смогли сделать сделали. Делали то же самое и вылазили те же ошибки, что я в первом комментарии упоминал + таблицы тоже переводили в utf8mb4_unicode_520_ci. И никто не может найти ошибку.
Сейчас пытаюсь соединиться с удалённым сервером, чтобы перекинуть туда CSV таблицы, но вылетает ошибка соединения. Написал в службу поддержки. Да, не думал, что можно вот так застрять на переносе.
Бывает, что некоторые плагины хранят свои таблицы в другом формате.
Вот как пример с одним из плагинов: https://ploshadka.net/mysql_error_1273/
Так что, похоже, надо таблицы менять на utf8mb4_unicode_ci
Оказывается с рубриками и метками проблема похлеще: в базе данных в таблице wp_terms они есть, но в админке WordPress их нет, но если их добавить в админке, то там они есть, но если перезагрузить страницу, они исчезают. Во дела….
Бывает такая проблема с используемой темой. Попробуйте менять тему на базовую, которая поставляется с WP.
Часто какой-то плагин может приводить к конфликтам при использовании с темой. Если смена темы поможет, то дальше уже можно пытаться выявить плагин.
Решил проблему с рубриками. Я сначала установил WordPress, а потом обновлял таблицы. В прошлый раз с рубриками и метками косяк был из-за того, что я удалил таблицы все и импортировал без переустановки WordPress. Сейчас пытаюсь по Navicat соединиться с базой данных на хостинге, но пока безуспешно. Пробовал через phpMyAdmin обновить таблицы в базе данных, но только wp_posts импоритуется в формате csv без ошибок.
Время подвести итоги моей эпопеи с переносом:
1 — подключение через Navicat настроил — можно обновлять таблицы.
2 — все страницы и рубрики импортируются успешно. Только нет меню и виджетов. Дмитрий, Вы случайно не знаете какая таблица в базе данных отвечает за их показ?
3 — проблема с рубриками и метками возникает, когда я обновляю таблицу Options. Видимо что-то сбивается и они не добавляются и не отображаются. Буду тогда вручную производить настройки.
4 — в целом содержание перенести можно и ссылки поправить тоже.
Так что осталось только настроить плагины и WordPress.
Всё. Перенёс сайт успешно. Все таблицы добавил и разобрался, что за что отвечает. Все медиафайлы, ссылки, рубрики, меню и прочее — всё перенёс. Так что на этом закрываю эту серию комментриев. Благодарю, Дмитрий, что уделяли внимание.
Отлично! Рад, что все получилось.