Перейти к содержимому
Все статьи
Обзоры

EmDash 1.0: что проверить перед переносом сайта с WordPress

·27 октября 2026 г.· 6 мин чтения
Переезжаете на другой хостинг?Перенос сайта на другой хостинг

Перед переносом WordPress на EmDash 1.0 проверьте три отдельных результата: сохранность материалов, замену функций расширений и работу редакции. Импорт записей не означает перенос темы и всех плагинов. Решение о переходе стоит принимать после ограниченного пилота на характерных материалах своего сайта, а не по обещанию современного технологического стека.

Что объявлено в версии 1.0

28 сентября 2026 года Cloudflare анонсировал EmDash 1.0 — CMS на Astro и новый реестр плагинов. README проекта описывает TypeScript, импорт из WordPress и варианты размещения. Это заявленные возможности продукта, а не наш результат переноса существующего сайта.

Статус ядра и всей экосистемы различается: README называет основные пакеты стабильными, а собственные плагины и инструменты для них оставляет в 0.x. Поэтому слово «стабильный» в анонсе нельзя автоматически распространить на каждую зависимость будущего проекта.

Сначала разложите действующий сайт по функциям

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

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

Часть учебного редакционного сайтаЧто требуется сохранитьКак проверить в пилотеЧто ещё не подтверждено импортом
Статья с рубриками и связямиТекст, принадлежность и ссылки на связанные материалыСверить исходную запись и результат по смыслуПравильная отрисовка всех типов содержимого
Материал с таблицей и примечаниемСтруктура, порядок и доступность чтенияОткрыть результат на разных экранахСовместимость произвольных блоков старого редактора
Иллюстрации и подписиНужные файлы, подписи и связь с материаломПроверить разрешённые учебные медиа и их отображениеАвтоматический перенос всех внешних файлов
Путь редактора к публикацииРоли, черновик и согласованный выпускПройти обычный рабочий маршрутЭквивалентность полномочий по совпадению названий ролей
Форма внешнего сервисаОжидаемое действие и понятный результатПроверить тестовую отправку без настоящих получателейРабота WordPress-плагина в новой CMS
Публичные адресаДоступность прежних важных материаловСверить карту адресов и выбранные переходыСохранение поиска от одного факта импорта

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

Материалы и оформление требуют разных решений

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

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

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

Что означает другая модель плагинов

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

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

Рабочий день редактора после переноса

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

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

Размещение и сопровождение не исчезают

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

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

  1. Составьте перечень используемых материалов и функций расширений.
  2. Выберите характерные учебные случаи и правила сопоставления.
  3. Проверьте импорт данных отдельно от оформления и поведения.
  4. Примите роли и обычный маршрут редактора.
  5. Сверьте адреса, медиа и внешние подключения.
  6. Определите версии зависимостей, среду и резервирование.
  7. Согласуйте переключение и сохранение новых правок при возврате.

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

Вопросы и ответы

EmDash CMS автоматически заменяет WordPress со всеми плагинами?

Нет оснований обещать это только по наличию импорта. Сопоставьте материалы, оформление и каждую используемую функцию расширений на своём пилоте.

EmDash обязательно размещать на Cloudflare?

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

Что проверить в GitHub EmDash перед переносом?

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

Нужна помощь с проектом?

Обсудим задачу и предложим решение — от сайта до SaaS и защиты.

Связаться