AIT Directory Migrations - Плагин WordPress

Руководство по AIT Directory Migrations для переноса старого каталога WordPress

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

Материал рассчитан на владельца каталога, вебмастера или разработчика, который уже получил архив плагина и хочет безопасно проверить его на копии сайта. Здесь нет инструкций по покупке, лицензированию или обходу активации. Фокус - установка, настройка, практический сценарий, контроль результата и диагностика типичных сбоев.

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

Где плагин действительно нужен, а где он не заменит обычную миграцию сайта

Самая частая ошибка при выборе такого инструмента - ждать от него возможностей универсального мигратора WordPress. AIT Directory Migrations не предназначен для клонирования всего сайта, переноса базы данных на новый домен, замены адресов в сериализованных данных или копирования медиафайлов между серверами. Его задача ближе к переносу каталожного содержимого: элементов каталога, связанных рубрик, локаций и некоторых данных, которые нужны для работы AIT-каталога после смены темы или перехода на новую структуру.

Если у вас был портал на старых решениях AIT вроде Directory или Business Finder, главная ценность плагина в том, что он помогает не воссоздавать записи вручную. На большом каталоге ручная работа быстро становится опасной: легко перепутать город, пропустить координаты, потерять иерархию категорий, забыть отзыв или связать объект не с тем владельцем. Миграционный инструмент уменьшает объём ручного копирования, но не отменяет проверку.

Если же вы переносите обычный блог, корпоративный сайт, WooCommerce-магазин или сайт без AIT-каталога, этот плагин почти наверняка не будет главным инструментом. В таких случаях лучше смотреть на резервное копирование, стандартный экспорт WordPress, WP All Import, Duplicator, WP Migrate или аналогичный инструмент под конкретную задачу. Для AIT Directory Migrations важен контекст: старый AIT-каталог, новый каталог, сопоставимые данные и понятная цель.

Есть ещё одна граница. Современная документация AitThemes для Citadela Listing говорит о CSV-подходе и стандартных структурах WordPress: данные можно экспортировать, сопоставить поля и импортировать через WP All Import или похожие инструменты. Поэтому AIT Directory Migrations лучше рассматривать как часть миграционного набора, а не как единственную кнопку, которая сама решит все проблемы старого сайта.

Какие данные каталога стоит считать критичными

В старых AIT-каталогах ценность обычно лежит не в одном поле заголовка. Каталог держится на связях: запись относится к категории, находится в локации, имеет координаты, может иметь отзывы, изображения, контактные данные, режим работы, владельца и дополнительные поля. Если перенести только названия и описания, публичная часть сайта формально наполнится контентом, но посетитель не сможет нормально искать, фильтровать и сравнивать объекты.

Подтверждённые описания продукта и старых AIT-страниц указывают на перенос Items, Item Categories, Item Locations и Reviews. В старых материалах также встречается упоминание выбора языка для миграции и настройки вопросов для отзывов. Эти пункты нужно проверять в интерфейсе именно вашей версии плагина: старые AIT-решения развивались неравномерно, а часть функций могла зависеть от установленного набора расширений.

Items как ядро каталога

Items - это сами объекты каталога: компании, места, услуги, события или другие записи, вокруг которых построен сайт. Для них важны заголовки, описания, изображения, адреса, координаты, телефоны, ссылки, пользовательские поля и статус публикации. На тестовом переносе выберите 10-20 разных объектов: опубликованные, черновики, записи с картой, записи без координат, объекты с длинным описанием, объекты из разных городов и категорий.

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

Категории и локации как навигация

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

Перед миграцией выгрузите или хотя бы зафиксируйте количество категорий, количество локаций и несколько примеров сложной вложенности. После переноса сравните не только общее число терминов, но и структуру. Для каталога «Страна -> Область -> Город» потеря одного уровня может быть хуже, чем отсутствие нескольких второстепенных описаний.

Отзывы и вопросы к отзывам

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

Не считайте отзыв перенесённым только потому, что число комментариев совпало. Откройте несколько объектов с отзывами в публичной части и в админ-панели, проверьте рейтинг, текст, дату, автора и состояние модерации. Для каталога с пользовательским доверием ошибка в отзывах может быть заметнее, чем ошибка в описании.

Кому подходит AIT Directory Migrations и кому лучше выбрать другой путь

AIT Directory Migrations будет полезен в ситуации, где у вас есть старый AIT-каталог и нужно перенести его содержимое в более новую AIT-тему или в рабочий процесс, совместимый с City Guide или Citadela Listing. Это инструмент для аккуратного перехода, а не для редизайна с нуля. Чем больше в старом каталоге объектов, категорий и локаций, тем выше ценность автоматизации.

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

Инструмент может не подойти, если исходный сайт давно переделан вручную, старые AIT post types изменены кастомным кодом, поля переименованы без документации, а часть данных хранится в сторонних плагинах. Он также не будет лучшим выбором, если вы хотите перейти не на AIT/Citadela-структуру, а на другой каталог с собственной моделью данных. В таком случае рациональнее строить CSV-карту и импортировать через инструмент, который умеет работать с нужными custom fields и taxonomies.

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

Подготовка перед установкой: что зафиксировать до первого запуска

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

Сделайте тестовый стенд, а не эксперимент на живом сайте

Разработчики AIT в документации по переходу на новую тему отдельно подчёркивают ценность development-окружения. Практически это значит: создайте копию сайта на поддомене, локальном сервере или staging-площадке хостинга. На этой копии должны быть те же старые AIT-тема и плагины, та же база данных, те же медиафайлы и те же пользовательские роли. Если тестовый стенд отличается от живого сайта, результат миграции будет менее надёжным.

На живом сайте до начала работ желательно заморозить добавление новых объектов каталога. Если это невозможно, заведите журнал изменений: какие записи были добавлены после копирования на тестовый стенд, какие отзывы появились, какие пользователи зарегистрировались. Иначе после успешного теста придётся отдельно переносить свежие изменения.

Снимите контрольные числа

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

Минимальный набор для сверки

• Количество объектов каталога по статусам: опубликованные, черновики, ожидающие проверки.
• Количество категорий и локаций, включая родительские и дочерние уровни.
• Количество отзывов, если на сайте установлен и используется соответствующий AIT-модуль.
• Список 10-20 контрольных объектов с разными полями: адрес, карта, изображение, телефон, сайт, рейтинг, несколько категорий.
• Список языков, если каталог многоязычный или когда в интерфейсе миграции есть выбор языка.

Эти цифры не гарантируют идеального переноса, но дают быстрый сигнал. Если было 1200 объектов, а после миграции стало 1198, нужно понять, какие именно две записи не прошли. Если число объектов совпало, но локации просели на треть, проблема находится не в Items, а в таксономиях или сопоставлении терминов.

Проверьте зависимости старого каталога

Старые AIT-сайты часто состоят из набора связанных компонентов: тема, AIT Toolkit, Item Reviews, языковые плагины, Page Builder, расширения карты, платежные или подписочные модули. AIT Directory Migrations может переносить только то, что предусмотрено его моделью. Данные сторонних расширений, кастомные поля от другого плагина или ручные изменения шаблонов могут потребовать отдельного экспорта.

Безопасная проверка: перед миграцией отключайте на тестовом стенде только то, что явно мешает процессу. Не удаляйте старые AIT-плагины до экспорта, потому что вместе с ними может исчезнуть интерфейс управления нужными post types и полями.

Установка и первичная проверка в админ-панели WordPress

Установка выполняется как у обычного ZIP-плагина WordPress. В админ-панели откройте Plugins, затем Add New, нажмите Upload Plugin, выберите ZIP-архив и установите его через Install Now. После завершения нажмите Activate Plugin. Если WordPress сообщает, что архив не содержит корректного плагина, проверьте, не находится ли нужный ZIP внутри общего пакета с документацией или дополнительными файлами.

После активации в старых описаниях продукта ожидается отдельный пункт Directory Migrations в левом меню WordPress. Если пункт не появился, не запускайте перенос через догадки. Сначала проверьте, активны ли старые AIT-компоненты, видит ли сайт исходные Items, нет ли PHP-ошибок и не конфликтует ли плагин с текущей темой. Иногда проблема не в миграционном инструменте, а в том, что исходная структура уже недоступна.

Что проверить сразу после активации

Проверка после установки должна ответить на три вопроса: плагин видит исходные данные, целевая структура доступна, а интерфейс миграции предлагает ожидаемые типы данных. Не нажимайте кнопку запуска, пока эти три условия не выполнены.

1. Откройте старые разделы каталога и убедитесь, что Items, категории и локации отображаются в админ-панели.
2. Проверьте, что целевая тема или целевой плагин уже установлены и не показывают критических ошибок.
3. Откройте интерфейс Directory Migrations и найдите параметры выбора сущностей: Items, Item Categories, Item Locations, Reviews или близкие к ним пункты.
4. Если сайт многоязычный, проверьте наличие языкового выбора и сопоставьте его с фактическими языками старого каталога.
5. Сохраните скриншот или заметку с доступными настройками, чтобы при повторном запуске не угадывать, что было выбрано.

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

Настройка миграции: язык, сущности и порядок переноса

AIT Directory Migrations ценен тем, что разделяет каталожные данные на сущности. Это позволяет переносить не всё одним непрозрачным действием, а понятными слоями. На практике порядок важен: сначала структуры, от которых зависят записи, затем сами Items, затем связанные данные вроде отзывов. Если интерфейс вашей версии предлагает другой порядок, используйте подсказки разработчика, но мыслите теми же зависимостями.

Сначала категории и локации

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

Для многоуровневой географии отдельно проверьте родительские связи. Например, город должен остаться внутри региона, а район - внутри города, если такая структура была в старой системе. Для категорий проверьте не только дерево, но и slug. Иногда новый сайт должен сохранить старые URL, иногда наоборот лучше построить новую структуру. Это решение принимает не плагин, а владелец сайта до миграции.

Затем Items и пользовательские поля

После подготовки таксономий переносите Items. Здесь важны не только базовые поля WordPress, но и custom fields. В документации AIT по CSV-подходу отдельно упоминаются широта и долгота как пользовательские поля старой темы. Это хороший пример поля, которое легко упустить: запись без координат может выглядеть нормальной в списке, но не появиться на карте или попасть в неверную область поиска.

Если вы используете промежуточный CSV, держите файл простым и проверяемым. Минимальная учебная структура может выглядеть так:

title,description,category,location,latitude,longitude,old_item_id
Coffee Point,"Short description",Cafe,Prague,50.087,14.421,ait-1001
City Museum,"Short description",Culture,Brno,49.195,16.608,ait-1002

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

Отзывы переносите только после проверки Item-связей

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

Если в старой системе использовались Review Questions, проверьте, как они представлены в целевой системе. Старые описания продукта упоминают возможность сопоставить уже определённые вопросы для миграции, но этот пункт зависит от набора AIT-расширений. Если вы не видите такого параметра, не добавляйте его в план как гарантированную функцию. Зафиксируйте ограничение в notes проекта и перенесите отзывы только в поддерживаемом формате.

Что включать только при необходимости

Не включайте все доступные пункты миграции просто потому, что они есть. Если на старом сайте не использовались отзывы, не переносите пустой слой. Если сайт одноязычный, не усложняйте процесс языковыми вариантами. Если данные пользователей и packages не подтверждены в вашей версии, не планируйте их как обязательную часть результата. Чем меньше лишних слоёв, тем проще понять, где возникла ошибка.

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

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

Хорошая настройка миграции - это не максимальное количество галочек, а управляемая последовательность. Вы запускаете один слой, проверяете результат, фиксируете вывод, затем переходите к следующему. Такой подход медленнее в первый час, но экономит много времени, если что-то пошло не так.

Практический пример: перенос городского каталога на тестовый сайт

Представим реальную задачу: есть старый городской каталог на AIT Business Finder, в нём компании, рубрики, районы, координаты и отзывы. Нужно подготовить тестовую версию на новой AIT-структуре, чтобы владелец сайта увидел, что данные сохранились и публичный поиск работает. Это типовой сценарий, где AIT Directory Migrations имеет смысл, потому что вручную переносить сотни объектов опасно.

Цель

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

Подготовка

До запуска создайте копию старого сайта, установите целевую тему или целевой listing-плагин, активируйте нужные AIT-компоненты, снимите контрольные числа и выберите набор тестовых объектов. В контрольный набор включите разные случаи: объект с картой, объект с несколькими категориями, объект из вложенной локации, объект с отзывом, объект без изображения и объект с нестандартным полем.

Шаги

1. Установите AIT Directory Migrations через Plugins -> Add New -> Upload Plugin.
2. Откройте пункт Directory Migrations и проверьте, видны ли исходные данные старого каталога.
3. Сначала перенесите Item Categories и Item Locations, если интерфейс позволяет запускать слои отдельно.
4. Сверьте количество терминов и несколько примеров вложенности в админ-панели целевого сайта.
5. Перенесите Items или подготовьте CSV для импорта, если ваш процесс строится через экспорт и WP All Import.
6. Проверьте несколько карточек: заголовок, описание, изображение, адрес, координаты, рубрика, город и статус публикации.
7. После проверки Items перенесите Reviews, если они используются и поддерживаются вашей конфигурацией.
8. Сохраните отчёт: что перенеслось автоматически, что требует ручной правки, какие поля нужно сопоставить повторно.

Проверка

Откройте публичную часть сайта и не ограничивайтесь главной страницей. Проверьте страницу отдельного объекта, архив категории, архив локации, поиск по ключевому слову, карту, страницу с отзывами и страницу без отзывов. Если в целевой системе есть блоки Citadela Listing, выведите список Items, карту и форму поиска на тестовой странице, чтобы увидеть, попадают ли перенесённые записи в реальные блоки.

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

Нюанс, который часто мешает

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

Практичные идеи применения после успешного переноса

Миграция не заканчивается в момент, когда записи появились в новой админ-панели. Если старый каталог годами рос без единой структуры, переход на новую систему - удобный момент превратить перенос в редакторскую уборку. Ниже несколько сценариев, которые опираются на подтверждённую логику directory-сайтов: объекты, категории, локации, отзывы, блоки вывода и CSV-проверку.

Редакторская чистка старых категорий

После переноса откройте категории и проверьте, какие из них реально используются. В старых каталогах часто остаются дубли: «Рестораны», «Restaurant», «Restaurants», «Еда» и «Food». Если целевой сайт должен быть аккуратным, лучше объединить такие группы на тестовом стенде и затем проверить, не сломались ли архивы. Это не функция самого плагина, а практическая задача, которую удобно выполнить именно после переноса.

Географическая проверка для локального портала

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

Обновление карточек перед открытием нового сайта

Перенос старых Items в новую структуру часто показывает, какие карточки устарели. Сделайте список объектов без изображения, без телефона, без сайта или без точных координат. Редактор может пройти по этому списку до публикации новой версии каталога. В результате миграция становится не просто техническим действием, а подготовкой более полезного каталога для посетителей.

Проверка платных или пользовательских сценариев

Если на старом сайте были владельцы объектов, пакеты размещения или пользовательские права, не считайте их перенесёнными автоматически. Современная документация Citadela Listing описывает отдельные механики подписок, WooCommerce-связей и прав владельцев Items. Эти сценарии нужно тестировать отдельно: может ли владелец увидеть свои записи, может ли редактировать карточку, не получил ли доступ к чужим объектам.

Как проверить результат в публичной части и админ-панели

Проверка результата должна идти двумя путями: сверху вниз и снизу вверх. Сверху вниз - это когда вы открываете публичный сайт как посетитель и смотрите, можно ли найти нужные объекты. Снизу вверх - когда вы открываете запись в админ-панели и проверяете, какие поля реально сохранились. Только один путь не даёт полной картины.

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

Начните с пользовательских маршрутов. Найдите объект через поиск, откройте категорию, откройте локацию, перейдите на страницу объекта, посмотрите карту и отзывы. Если каталог поддерживает фильтры, проверьте фильтрацию по категории и локации вместе. Если есть похожие элементы или блоки списка, убедитесь, что перенесённые Items появляются в них ожидаемо.

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

Проверка админ-панели

В админ-панели откройте те же контрольные объекты. Сравните заголовок, slug, статус, автора, категории, локации, произвольные поля, координаты и миниатюру. Если использовался CSV, проверьте строку исходного файла. Если у записи есть старый идентификатор, временно сохраните его в служебном поле или в таблице сверки, чтобы быстрее разбирать спорные случаи.

Проверка SEO и URL

Миграция каталога может изменить URL. Иногда это нормально, если сайт переходит на новую структуру. Но если старые страницы уже имеют поисковый трафик, нужно подготовить редиректы и карту соответствий. AIT Directory Migrations не должен восприниматься как SEO-инструмент, который сам сохранит видимость сайта. Он переносит данные, а SEO-слой требует отдельной проверки: slug, архивы, заголовки, метаописания, канонические адреса и редиректы.

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

Особенности совместимости со старой AIT-структурой и Citadela Listing

Самый важный технический контекст AIT Directory Migrations - старые и новые AIT-решения не являются одной и той же системой с новым дизайном. AitThemes прямо объясняет в документации по переходу к Citadela, что Citadela имеет другой core, другую базу и другие настройки. Это означает, что миграция должна переводить данные, а не просто включать новую тему поверх старой структуры.

Citadela Listing, по официальной документации, использует стандартные custom post types и категории WordPress. Это полезно для будущей поддержки: данные проще импортировать и экспортировать через CSV, а не держать в закрытой структуре одной темы. Но это также означает, что старые поля нужно правильно сопоставить с новыми полями. Если координаты, адрес или дополнительные сведения лежали в старых custom fields, они не появятся в нужном месте без корректной карты.

Почему CSV-подход часто безопаснее слепого переноса

CSV даёт видимый промежуточный слой. Вы видите строки, столбцы, кодировку, пустые значения, дубли и старые идентификаторы. WP All Import и похожие инструменты позволяют сопоставлять колонки с полями WordPress, custom fields и таксономиями. Это особенно удобно, когда целевой сайт не полностью совпадает со старой AIT-структурой или когда нужно очистить данные до импорта.

Недостаток CSV-подхода - он требует внимания. Нужно выбрать уникальный идентификатор, проверить кодировку UTF-8, правильно разделить категории, не потерять изображения и не смешать языковые версии. Поэтому для простого перехода между поддерживаемыми AIT-структурами удобен AIT Directory Migrations, а для сложной переработки данных лучше комбинировать его с CSV-экспортом и ручной картой полей.

Что делать с медиафайлами

Изображения часто становятся отдельной проблемой. Некоторые инструменты переносят записи, но оставляют ссылки на старые файлы. Другие умеют скачать изображения при импорте, если в CSV есть URL. В любом случае проверка должна включать карточки с featured image и галереями. Если изображения не загрузились, не повторяйте всю миграцию сразу. Сначала выясните, где они хранятся: как attachment в медиатеке, как URL в поле, как галерея темы или как данные стороннего плагина.

Что делать с пользователями и пакетами

Старые продуктовые страницы упоминали развитие функций переноса пользователей и packages, но такие пункты нельзя считать гарантией для каждой сборки. Если у каталога есть владельцы объектов, платные размещения или подписки, тестируйте их как отдельный проект. Проверьте не только наличие пользователей, но и права: кто может редактировать объект, видит ли чужие Items, сохраняется ли связь с заказом или пакетом, не открылась ли лишняя админ-функция.

Если миграция прошла не так: симптомы, причины и безопасные исправления

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

Записи появились, но категории или города пустые

Симптом: Items есть в админ-панели, но архивы категорий или локаций пустые, а фильтры не находят записи. Возможная причина - таксономии не перенеслись, перенеслись после Items, получили другие идентификаторы или не были сопоставлены при CSV-импорте.

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

Карта не показывает объекты

Симптом: список объектов работает, но карта пустая или показывает точки в неверном месте. Возможная причина - не перенесены latitude и longitude, координаты попали в другие custom fields, адрес хранится в неподдерживаемом формате или целевой блок карты ждёт другой источник данных.

Откройте один объект с известными координатами и сравните поля со старой записью. Если используете WP All Import, проверьте карту полей и формат чисел. В некоторых CSV-файлах десятичный разделитель или кодировка могут мешать корректному чтению. Исправляйте сначала одну запись и только потом запускайте массовое обновление.

Отзывы перенеслись не к тем объектам

Симптом: на карточке объекта отображаются чужие отзывы или отзывы есть в админ-панели, но не видны на публичной странице. Возможная причина - перенос отзывов выполнен до проверки Items, старые идентификаторы не сопоставлены с новыми записями или целевая система использует другой механизм отображения отзывов.

Проверьте связь отзыва с конкретным post ID, затем сравните её со старым объектом. Если есть старый идентификатор, используйте его как мост. Не удаляйте отзывы массово, пока не сделаете экспорт текущего состояния. Если ошибка затронула много записей, безопаснее откатиться к копии стенда и повторить слой отзывов после исправления Items.

Дубли появились после повторного запуска

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

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

Админ-панель показывает ошибку или белый экран

Симптом: после активации или запуска миграции часть админ-панели недоступна. Возможная причина - конфликт старой темы, расширения, версии PHP, нехватка памяти или несовместимый компонент. Включите журнал ошибок WordPress на тестовом стенде, проверьте последние записи в логах и временно отключите неважные плагины, которые не участвуют в исходных AIT-данных.

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

Короткий маршрут диагностики

Симптом	Сначала проверить	Безопасное действие
Пустые архивы	Связи Items с категориями и локациями.	Повторить слой таксономий или импорт Items с правильной картой.
Пустая карта	Поля координат и формат чисел.	Исправить одну запись, затем массово обновить координаты.
Чужие отзывы	Связь review -> Item и старый идентификатор.	Откатить слой отзывов и перенести после проверки Items.
Дубли	Уникальный ключ импорта.	Откатить стенд или удалить дубли после экспорта текущего состояния.

Когда AIT Directory Migrations будет удачным выбором

AIT Directory Migrations стоит использовать, когда у вас есть старый AIT-каталог, понятная цель переноса и готовность провести тест на копии сайта. Его сильная сторона - работа с каталожными сущностями, которые трудно переносить вручную: Items, категории, локации и отзывы. Его слабая сторона - узкая область применения. Это не инструмент для любого WordPress-переезда и не гарантия автоматического SEO-сохранения.

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

Если вы готовы провести такую проверку, можно скачать AIT Directory Migrations и протестировать плагин на staging-копии. Не оценивайте его по первому экрану админ-панели: ценность инструмента проявляется только после сверки старых и новых данных.

Хороший итог миграции выглядит не как «кнопка нажата», а как проверяемая система: старый объект найден, его категория и локация сохранены, координаты работают, отзыв на месте, публичная страница открывается, а администратор понимает, что делать с оставшимися ручными правками.