Перенос сайта с DLE на WordPress 2017

Перенос сайта с DLE на WordPress

Однажды, с сайтом одного из проектов, с которыми я работаю случилась неприятность - его взломали и удалили все файлы с хостинга. Сайт был создан на платформе Data Life Engine (DLE), разумеется, на ломаной (nulled) версии. Полагаю, нас взломали сами авторы движка. Бекапы конечно у нас были и тогда я понял, что в движке полно уязвимостей и пора выполнить перенос сайта с DLE на WordPress. О том, как это сделать, я хочу рассказать вам в этой статье. В интернете есть несколько статей на эту тему, однако в них описано не все и код для переноса не полностью переносит все, что нужно для полноценной работы, содержит косяк с переносом анонсов, да и плагины WordPress там указаны устаревшие.

Шаг первый: бекап и установка WordPress

Для начала, рекомендую сделать бэкап базы данных DLE и его файлов. Затем посмотрите настройки подключения к БД в файле engine\data\dbconfig.php. Нас интересует DBNAME, DBUSER и DBPASS - скопируйте их куда-нибудь. Теперь нужно выполнить несколько простых действий:

Удаляем все файлы с корня сайта, кроме папки uploads и всех, созданных вами папок и файлов в корне, если такие есть.
Скачиваем WordPress
Распаковываем файлы движка в корень сайта. Все файлы и папки, начинающиеся на "wp-", должны оказаться в корневой папке сайта, где от DLE осталась только папка uploads.
Заходим на сайт в браузере, появится страница установки WordPress, при установке укажите параметры подключения к той же БД, где остались данные DLE (параметры подключения мы копировали).
После успешной установки, авторизуемся в админке
- В разделе плагины нажимаем "Добавить новый", в поиске в углу вводим "Cyr to Lat enhanced" и устанавливаем этот плагин.
- Затем ищем и устанавливаем "Yoast SEO" - отличный плагин для СЕО, он вам обязательно будет полезен, но на начальном этапе нужен он нам для другого.
- Активируем оба плагина, заходим в раздел SEO -> Дополнительно -> Постоянные ссылки и в первом пункте ставим "Убрать". Это уберет стандартный префикс "/category/", который добавляется во все URL
- Далее в консоли WordPress идем в Настройки -> Постоянные ссылки, выбираем "Произвольно" и вписываем "/%category%/%post_id%-%postname%.html". Это приведет ссылки к такому виду, в каком они были на DLE.
- Теперь вам нужно найти и установить нужный вам шаблон (тему). Сделать это можно через Внешний вид -> Темы. Можно загружать свои шаблоны, которые вы найдете в интернете.
- Важно: не пытайтесь создавать новые посты и рубрики в WordPress, они все равно исчезнут на следующем шаге и будут заменены теми, которые были в DLE.

Первый шаг переноса сайта с DLE на WordPress завершен, осталась половина задачи.

Шаг второй: Миграция базы данных

Начну с того, что принцип хэширования паролей пользователей на движках отличается, поэтому пароли с DLE на WordPress не мигрируют вообще! Если у вас есть пользователи и открыта регистрация, то после переноса сайта, сделайте рассылку на E-Mail с просьбой восстановить свои пароли через кнопку "Забыли пароль".

Дополнительные поля в записях (если они есть) не будут перенесены, поэтому если хотите их перенести, вам придется найти их в таблицах DLE, понять, где они должны быть в таблицах WP и изменить SQL код, который представлен ниже, чтобы он и их переносил куда следует.

А вообще это должно решиться заменой d_p.full_story в коде на CONCAT(d_p.full_story,d_p.xfields).

Записи, созданные пользователем, который был потом удален, тоже могут быть не перенесены. Рекомендую сначала проверить, чтобы всем записям был указан какой-нибудь автор (существующий пользователь). Добавить автора всем записям, где его нет можно следующим SQL запросом:

UPDATE 'dle_post' SET author='ЛОГИН ПОЛЬЗОВАТЕЛЯ' WHERE author=''

1	UPDATE 'dle_post' SET author='ЛОГИН ПОЛЬЗОВАТЕЛЯ' WHERE author=''

Теперь о SQL коде для миграции

Если вы зайдете в phpMyAdmin, вы увидите, что в базе данных есть таблицы, начинающиеся на "wp_" и на "dle_". Если все так - значит вы нигде не ошиблись при установке WordPress.

Для нормальной работы сайта, мы хотим в автоматическом режиме перенести пользователей, категории, записи и комментарии в соответствующие таблицы WordPress.

Я читал другие статьи на эту тему и понял, что везде дают один и тот же код для миграции БД, однако этот код имеет существенные недостатки:

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

При переносе сайта c DLE на WordPress, я доработал этот код, теперь он переносит данные пользователей, добавляет аттрибуты прав и не переносит анонсы записей. Но если вам все же нужно объединить обе версии каждой записи, то найдите в SQL коде "d_p.full_story" и замените на "CONCAT(d_p.short_story, '' ,d_p.full_story".

Внимание: если на вашем сайте DLE большое количество записей, рекомендую выполнять этот код не в phpMyAdmin, а через десктопный софт для удаленного подключения к БД, например бесплатный HeidiSQL.

В phpMyAdmin выбираем нашу базу данных, переходим на вкладку "SQL" и вставляем в поле этот код:

DELETE FROM `wp_users` WHERE `wp_users`.`ID` != 1;
INSERT INTO wp_users (ID, user_login, user_nicename, user_email, user_registered, display_name) SELECT user_id, name, name, email, FROM_UNIXTIME( reg_date ), name FROM dle_users WHERE user_id != 1;

INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "first_name", fullname FROM dle_users;
INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "description", info FROM dle_users;
INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "admin_color", "fresh" FROM dle_users;
INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "show_admin_bar_front", "false" FROM dle_users;
INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "wp_capabilities", "a:1:{s:10:\"subscriber\";b:1;}" FROM dle_users;
INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "wp_user_level", 0 FROM dle_users;

TRUNCATE `wp_terms`;
INSERT INTO `wp_terms` (`term_id`, `name`, `slug`) SELECT `id`, `name`, `alt_name` FROM `dle_category`;

TRUNCATE `wp_term_taxonomy`;
INSERT INTO `wp_term_taxonomy` (`term_taxonomy_id`, `term_id`, `description`, `parent`) SELECT `id`, `id`, `descr`, `parentid` FROM `dle_category`;
UPDATE `wp_term_taxonomy` SET `taxonomy`='category';

TRUNCATE `wp_term_relationships`;
INSERT INTO wp_term_relationships (object_id, term_taxonomy_id) SELECT id, category FROM dle_post;

TRUNCATE wp_posts;
INSERT INTO wp_posts (id, post_author, post_date, post_content, post_title, post_name) SELECT d_p.id, d_u.user_id, d_p.DATE, d_p.full_story, d_p.title, d_p.alt_name FROM dle_post AS d_p, dle_users AS d_u WHERE d_p.autor = d_u.name;

TRUNCATE `wp_comments`;
INSERT INTO wp_comments (comment_ID,comment_post_ID, comment_author, comment_author_email, comment_date, comment_content) SELECT id, post_id, autor, email, DATE, text FROM dle_comments;

DELETE FROM `wp_users` WHERE `wp_users`.`ID` != 1;

INSERT INTO wp_users (ID, user_login, user_nicename, user_email, user_registered, display_name) SELECT user_id, name, name, email, FROM_UNIXTIME( reg_date ), name FROM dle_users WHERE user_id != 1;

INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "first_name", fullname FROM dle_users;

INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "description", info FROM dle_users;

INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "admin_color", "fresh" FROM dle_users;

INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "show_admin_bar_front", "false" FROM dle_users;

INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "wp_capabilities", "a:1:{s:10:\"subscriber\";b:1;}" FROM dle_users;

INSERT INTO wp_usermeta (user_id, meta_key, meta_value) SELECT user_id, "wp_user_level", 0 FROM dle_users;

TRUNCATE `wp_terms`;

INSERT INTO `wp_terms` (`term_id`, `name`, `slug`) SELECT `id`, `name`, `alt_name` FROM `dle_category`;

TRUNCATE `wp_term_taxonomy`;

INSERT INTO `wp_term_taxonomy` (`term_taxonomy_id`, `term_id`, `description`, `parent`) SELECT `id`, `id`, `descr`, `parentid` FROM `dle_category`;

UPDATE `wp_term_taxonomy` SET `taxonomy`='category';

TRUNCATE `wp_term_relationships`;

INSERT INTO wp_term_relationships (object_id, term_taxonomy_id) SELECT id, category FROM dle_post;

TRUNCATE wp_posts;

INSERT INTO wp_posts (id, post_author, post_date, post_content, post_title, post_name) SELECT d_p.id, d_u.user_id, d_p.DATE, d_p.full_story, d_p.title, d_p.alt_name FROM dle_post AS d_p, dle_users AS d_u WHERE d_p.autor = d_u.name;

TRUNCATE `wp_comments`;

INSERT INTO wp_comments (comment_ID,comment_post_ID, comment_author, comment_author_email, comment_date, comment_content) SELECT id, post_id, autor, email, DATE, text FROM dle_comments;

После выполнения этого кода, все ваши пользователи, посты, категории и комментарии будут копированы в WordPress и вы смело можете посмотреть работу сайта. Если пути к картинками в DLE были прописаны правильно, они должны будут отображаться, ведь папку uploades с картинками мы оставили. Вам останется только сделать основные настройки сайта (заголовок, описание, другие настройки в консоли WordPress) и конечно поработать с шаблоном, чтобы все было как вы хотите.

С помощью этого кода, я успешно в 2012 году перенес с DLE на WordPress сайт проекта Club-FL с ~2000 записями и более 3000 пользователями.

Опубликовано 23 сентября 2017
Категории: PHP и WordPress, Блог
Теги: DLE, MySQL, PHP, WordPress, перенос сайта, сайты

11 комментариев Перенос сайта с DLE на WordPress

Wstory - 22.11.2017 - 20:03 Ответить

Здравствуйте! Подскажите, а как перенести статические страницы из базы DLE в WP?
- Alexell - 28.11.2017 - 21:02 Ответить
  
  Здравствуйте. У меня сейчас нет рабочего DLE, чтобы посмотреть его базу данных и ответить на ваш вопрос. При том давнем переносе, мы не переносили страницы, у нас их было мало. Создали новые.
Андрей - 05.12.2017 - 20:23 Ответить

добрый день
Перенес статьи. А при открытии некоторые выдают ошибку: Ой! Страница не найдена.
Но стоит её пересохранить и статья открывается как надо. В чём может быть подвох? пересохранять не вариант каждую статью
- Alexell - 07.12.2017 - 13:14 Ответить
  
  Проверьте настройки ЧПУ, включая файл .htaccess
  Скорее всего ЧПУ в WordPress настроили не так, как было на DLE.
Валерий - 09.07.2019 - 19:30 Ответить

Сейчас поменялось что-то в БД и выдает ошибку:

#1292 — Incorrect datetime value: ‘0000-00-00 00:00:00’ for column ‘post_date_gmt’ at row 1

Не подскажите, как решить.
Джони - 27.09.2019 - 11:56 Ответить

Сделал всё по инструкции, но проблема в том, что не отображаются прикрепленные картинки… Я так полагаю, что проблема с путями, но как это решить — ума не приложу
Ulvi - 20.02.2020 - 23:30 Ответить

Я проверял, но отказался от миграции: дело в том, что файлы, которые были предназначены для закачки, не переносились, вследствии чего их невозможно было скачивать на WordPress, а добавление вручную требовал много времени.
Александр - 30.10.2020 - 01:35 Ответить

Огромное спасибо за материал! Все получилось, сэкономил кучу времени. Пути подправил утилитой, а миниатюры с помощью плагина.
- Alexell - 19.11.2020 - 09:21 Ответить
  
  Рад что помогло!
Елена - 08.11.2020 - 19:40 Ответить

Тоже думаю так сделать, в принципе все просто — перенести посты и пользователей. Но когда постов меньше 100 и ручками можно добавить. Но вот пароли хотелось бы сохранить.
- Alexell - 19.11.2020 - 09:26 Ответить
  
  Если выяснить как хешируются пароли на DLE, как хешируются на Вордпрессе, теоретически можно написать скрипт и массово дохешировать пароли под вариант Вордпресса.
  Например, если в DLE пароли хешируются в один md5, а в Вордпрессе в md5+md5, то можно скриптом все md5 пароли из базы еще раз в md5 хешировать и получим md5+md5. Но это маловероятно, скорее всего в Вордпресс хеширование паролей куда сложнее, но если в структуре хеширования Вордпресса первым идет md5, то может получиться.

Alexell.Ru