Организация страниц WP на основе старой базы данных веб-сайта

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

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

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

Solutions Collecting From Web of "Организация страниц WP на основе старой базы данных веб-сайта"

Прежде чем перейти в « Импорт» , я бы ознакомился как с стандартным типом post и с post_meta, так и с пользовательскими типами сообщений и таксономиями . Если ваша конечная цель выиграет от последней, вы избавитесь от своей головной боли, используя их во время подготовки импорта.


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

Другим вариантом, в духе импортера, было бы отправить сообщения со старого сайта на конечные точки app wp-json на сайте wordpress и таким образом обработать миграцию.

Как отметил @Rarst , на самом деле нет ярлыка, но, как отметил в своем комментарии @Max, Импортер может по крайней мере помочь вам в этом процессе на стороне WordPress.

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

Использование импортера WordPress ( инструменты> Импорт )

Существует множество опций (и еще большее множество вещей, которые нужно учитывать перед использованием любого из них), для импорта контента в WordPress. Это будет самый безопасный метод. Вы можете ознакомиться со многими из них здесь: Импорт содержимого в WordPress

В том числе:

  • Blogger
  • Drupal
  • Электронная таблица Excel / CSV / XML / JSON
  • Конвертеры блога Google
  • Joomla
  • Живой журнал
  • Magento
  • Mambo
  • Подвижный тип
  • Nucleus CMS
  • Plone
  • Posterous
  • SPIP
  • Tumblr
  • щебет
  • TypePad
  • и т. д., вы получаете точку

В этих страницах также перечислены различные плагины для импорта экспорта предыдущих cms (перечислены несколько типов).

CSV, XML, RSS … в любом случае. Разумеется, вам нужно будет создать файл, который необходимо обработать.


Дамп базы данных> Импорт

( Не зная никакой информации о текущей БД ), вы можете сбросить содержимое старых страниц БД и преобразовать его в импорт sql. Даже не думайте об этом, если вы действительно не знаете, что делаете. Вы могли бы серьезно отбросить все. Но жизнеспособный вариант, если вам это нравится.

Я бы не рассматривал это решение WordPress , просто отметив его как подход.


Импорт моста с WP-JSON API

Если у вас все еще есть доступ к старой базе данных / сайту, вы можете использовать wp-json api , написав что-то на своем конце, чтобы posts в соответствующую конечную точку в конце wordpress для каждой записи в вашей старой БД.

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


Расширяя это вместо дополнительных вопросов ОП в комментариях:

Во-первых, вы захотите пометить этот ресурс для работы с классом WP_REST_request

Предполагая, что мы написали немного кода на старом сайте, который захватывает соответствующий контент и помещает его в форматированный объект POST, и предполагая конечную конечную точку:

[Old Site Data ] POST http для маршрутизации http://new-WP-site.com/wp-json/v2/plugin_namespace/v1/posts/

В конце WP /plugin_namespace/v1/posts/ мы создадим. Чтобы это произошло, мы сначала extend класс WP_REST_Controller .

Затем внутри нашего класса мы регистрируем наши маршруты, используя register_rest_routes() . Что-то вроде:

 public function __construct() { add_action( 'rest_api_init', array($this, 'register_routes' ) ); }//end __construct public function register_routes() { $version = '1'; $namespace = 'plugin_namespace/v' . $version; $base = 'posts'; register_rest_route( $namespace, '/'. $base, array( array( 'methods' => 'GET', 'callback' => array( $this, 'this_is_a_callback_function' ), //'permission_callback' => array( $this, 'key_permissions_check' ), ), array( 'methods' => 'POST', 'callback' => array( $this, 'this_is_a_callback_function' ), //'permission_callback' => array( $this, 'key_permissions_check' ), ),) ); }//register_routes public function this_is_a_callback_function(WP_REST_Request $request) { //if posted in body like form data $posted_data = $request->get_body_params(); } 

С этого момента у $posted_data есть то, что было POST ed, и вы можете пройти через него или передать его другой функции.

Эта функция должна была бы построить post_array из каждой записи и передать ее вместе с wp_insert_post()

Подход можно использовать с использованием WP_REST_Server::CREATABLE вместо methods => POST . Мой – просто быстрый / неполный пример.

Также я прокомментировал permissions_callbacks , но эта функция обратного вызова – это то, где обычно проверяются ваши проверки полномочий.

Обратите внимание, что wp_insert_post() позволит вам передать массив мета также, но wp_update_post не будет. wp_insert_post также требуются значения title и content . Если вы передадите любой идентификатор, отличный от 0, он запустит wp_upate_post .

Вы можете захотеть использовать что-то вроде requestb.in , сортируя свой старый код сайта, чтобы проверить, что он отправляет, и почтальон работает достаточно хорошо для проверки ответа api.

Как я уже упоминал в комментариях, ngrok можно использовать для полной миграции не-wp в wp в среде dev.

Надеюсь, это даст вам достаточно информации, чтобы перевести его кому угодно.


Соответствующие таблицы WP (сообщения)

Независимо от того, строите ли sql-импорт или записываете какой-либо другой мост, для сообщений , таблицы, которые должны отображаться на конец WordPress, будут:

Название таблицы : данные в таблице

wp_posts: сообщения

wp_postmeta: post meta values

wp_term_relationships: сообщения для таксономии

wp_term_taxonomy: таксономии

wp_terms: значения тегов и категорий

Вот полная схема базы данных введите описание изображения здесь

Вы можете использовать собственное правило перезаписи, чтобы WP интерпретировал определенные URL-адреса для вызова и представления данных из старой базы данных. Однако вы хотите продолжать управлять данными в старой базе данных? Как в интерфейсе WP / admin для сохранения данных таким образом, который им чужд? В этот момент вы в значительной степени пишете собственную CMS рядом с WP.

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

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

В двух словах: чем больше будет отвечать WP, тем лучше будет рассматривать полную миграцию.