Вопрос или проблема
Какой HTML лучше, до Гутенберга или после?
Я импортировал контент постов с старого и большого WP сайта в свежую установку и новую базу данных. Почти 1200 постов вместе с их метаданными и связанными медиафайлами. XML файл весит 15 МБ. Я использовал стандартный импорт/экспорт WordPress вместе с плагином для экспорта медиафайлов [изображений][1]. Исходный сайт использует tinymce advanced, чтобы поддерживать классический вид редактора для клиента.
Большая часть контента была перенесена, но в новой настройке HTML импорта изменился.
Вот как он выглядел на фронтенде. Слева оригинал, справа импорт.
Вот как изменился HTML. Слева оригинал. Справа после импорта.
На каком этапе процесса весь блок контента оказался обернут в <p>
, с добавлением <br>
и  
, а оригинальные переносы строк отсутствуют?
Очевидно, что что-то в Гутенберге меняет базовый HTML контента поста.
https://wordpress.org/support/topic/gutenberg-does-not-play-nicely-with-code-editor/
https://github.com/WordPress/gutenberg/issues/11211
https://core.trac.wordpress.org/ticket/45636?cversion=0&cnum_hist=1
Мне удалось исправить проблему с отступами абзацев на фронтенде с помощью этого CSS, любезно предоставленного Themeisle
br
{ content: "A" !important;
display: block !important;
margin-bottom: 1em !important;
}
Тем не менее, я хочу знать, как лучше двигаться вперед в отношении HTML. Это какая-то ошибка в Гутенберге или мне просто продолжить с исправлением CSS? Какой здесь правильный HTML? Если он неправильный, есть ли какое-то волшебство regex, которое бы это исправило?
обновление
В ответ на @tomjnowell, я выполнил экспорт без активных плагинов и импортировал его в свежую установку без активных плагинов. Вот результаты:
XML был импортирован на пустой сайт. Контент постов затем отображается в блоке “Классический” Гутенберга в режиме “редактировать как HTML”, с удаленными пробелами между абзацами и добавленными br и nbsp. BR не появляются в базе данных, но nbsp — да.
Вот еще одно сравнение, показывающее слева направо: XML, исходную базу данных и целевую базу данных. Также я заметил следующие различия между базами данных. Не уверен, важно ли это.
В исходной базе данных post_content имеет тип: MyISAM с сортировкой: latin1_swedish_ci
В целевой базе данных post_content имеет тип: InnoDB с сортировкой: utf8mb4_unicode_520_ci
Гутенберг — это редактор, это не активный процесс, который работает в фоновом режиме. Если вы не открыли пост в блочном редакторе, у него нет возможности изменять HTML
Подумайте об этом так, PDF — это PDF, это контент, данные. Если я создам его в одном приложении, а затем скопирую на машину с другим PDF-ридером, PDF останется прежним. Для того чтобы изменить его, мне нужно открыть PDF в редакторе и заново сохранить его.
То же самое относится и к Гутенбергу. Если вы не откроете пост в Гутенберге и не нажмете “сохранить/опубликовать”, у Гутенберга нет шансов внести изменения.
Попробуйте представить, что было бы нужно для Гутенберга, чтобы действительно это сделать. Ему нужно было бы обновить каждый отдельный пост в базе данных, отслеживать, что было и что не было изменено, и он не мог бы сделать это за один запрос, ему пришлось бы непрерывно опрашивать себя, пока работа не будет выполнена, создавая большую нагрузку на сервер.
Таким образом, Гутенберг не является причиной вашей проблемы. Он не может быть ей причиной, если вы не открыли все 1200 постов, а затем отредактировали и заново сохранили каждый из них.
Итак, что вы можете сделать?
Во-первых, выполните стандартный экспорт WP без каких-либо дополнительных плагинов, которые могли бы вмешиваться или мешать.
Во-вторых, проверьте разметку в wxr
и посмотрите, содержит ли она тот же контент или был изменен.
В-третьих, импортируйте данные и проверьте разметку в базе данных, а не в редакторе/фронтенде.
В-четвертых, выполните все вышеперечисленное с использованием стандартных тем по умолчанию и без плагинов.
Проще говоря, нет никаких доказательств того, что Гутенберг виновен (нет доказательств того, в чем состоит проблема, ее причина в настоящее время неизвестна), и Гутенберг не работает таким образом.
В качестве заключительной заметки, то, о чем вы говорите, — это не нормальный контент, и это не абзацы. Это блоки “классического абзаца” TinyMCE Advanced, и они могут работать не так. Например, возможно, что то, как выглядит контент и какой на самом деле HTML, — это не одно и то же.
Я бы предложил убедиться, что TinyMCE Advanced также установлен на целевом сайте. В противном случае вы должны обратиться за поддержкой TinyMCE Advanced в форум поддержки TinyMCE Advanced.
Ответ или решение
Судя по вашему описанию, проблема, с которой вы столкнулись, не является следствием работы редактора Gutenberg, поскольку для изменения HTML-контента в постах Gutenberg нужно, чтобы посты были открыты и переохранены в среде редактора.
Рассмотрим вашу ситуацию более подробно:
-
Импорт данных: При импорте постов с одного сайта на другой (особенно при использовании плугина TinyMCE Advanced на исходном сайте) важно убедиться, что сам процесс импорта происходит корректно и что используемые плагины не влияют на форматирование контента.
-
Проверка WXR: Вы можете проверить файл экспорта (WXR), чтобы увидеть, содержит ли он измененное содержимое. Для этого откройте XML-файл в текстовом редакторе и убедитесь, что HTML-код в нем соответствует тому, что вы ожидаете. Если изменения в HTML уже присутствуют в WXR-файле, значит, проблема кроется в процессе экспорта.
-
Сравнение баз данных: Как вы заметили, различия в типах таблиц и кодировках тоже могут привести к проблемам с сохранением разметки. Убедитесь, что кодировка базы данных и коллации позволяют корректно хранить HTML-текст.
-
Тестирование с отключенными плагинами: Хорошей практикой будет проверить процесс экспорта и импорта с отключенными плагинами, что вы уже сделали. Это поможет изолировать проблему и проверить, влияет ли TinyMCE Advanced на исходный HTML.
-
Проблемы с разметкой в TinyMCE Advanced: Существует вероятность, что разметка, которую создает TinyMCE Advanced, может отличаться от стандартной разметки WordPress. Поскольку вы заметили, что на целевом сайте нет установленного TinyMCE Advanced, это может быть причиной проблем с разметкой. Рекомендую установить этот плагин и проверить, устранят ли изменения в разметке возвращение к оригинальной версии плагина.
-
Использование CSS для исправления: Ваша CSS-правка, которая добавляет отступы между элементами, может помочь улучшить отображение контента на фронтенде, но если контент сам по себе неправильно разметчен, это может быть лишь временным решением.
-
Использование регулярных выражений для исправления HTML: Если вы хотите выполнить массовое исправление HTML, возможно, вам стоит воспользоваться регулярными выражениями в PHP для удаления лишних
<br>
, изменение
и корректировки структуры HTML. Но стоит помнить, что такие изменения должны проводится с осторожностью, чтобы не ухудшить разметку. -
Заключение: В целом, стоит исключить влияние Gutenberg на процесс, так как, как уже говорилось, данный редактор не может изменять содержимое постов без вашего вмешательства. Фокусируйтесь на анализе экспорта, настройках базы данных и других используемых плагинах, чтобы определить источник проблемы.
Если после всех проверок проблема все еще останется, рекомендую обратиться в службу поддержки TinyMCE Advanced или на форумах WordPress для получения более конкретной помощи и рекомендаций.