Так что этот вопрос неоднократно поднимался под разными флагами, однако я хотел бы представить единую ветку для окончательного решения этой проблемы.
В WordPress по умолчанию при переключении между редакторами HTML и Visual в TinyMCE некоторые теги удаляются из содержимого, и возникает другая странная функциональность. Два известных обходных пути для написания более эффективного HTML-кода - это удаление функции wp_auto_p с использованием фильтров, установка TinyMCE Advanced и включение опции «прекратить удаление тегов p & br».
К сожалению, это работает так хорошо.
Взять, к примеру, следующий пример:
<h2>How does it work?</h2>
<p>In order to use jQuery Easy Columns, you must install it as you would any other jQuery plugin. First, download the zip file using the button above. After downloading the file, extract it to a location of your choice, and move the extracted folder to your server using your favorite FTP client. After moving the plugin to your server (and of course calling the jQuery source into your document), call it in on your site using the following snippet of code:</p>
<pre>
<script type="text/javascript" src="/path/to/jquery.easycolumns.js"></script>
</pre>Если я набираю этот код в редакторе HTML с уже включенными обоими перечисленными выше параметрами, то при переключении между двумя различными редакторами ничего не происходит, что ожидается. К сожалению, при сохранении код автоматически преобразуется в это:
<h2>How does it work?</h2>
<p>In order to use jQuery Easy Columns, you must install it as you would any other jQuery plugin. First, download the zip file using the button above. After downloading the file, extract it to a location of your choice, and move the extracted folder to your server using your favorite FTP client. After moving the plugin to your server (and of course calling the jQuery source into your document), call it in on your site using the following snippet of code:</p>
<pre>
<script type="text/javascript" src="/path/to/jquery.easycolumns.js"></script>
</pre>Как видите, все сущности внутри предварительного тега преобразуются обратно в реальные символы HTML. Затем, если я сохраню этот же пост снова, я получу что-то вроде следующего:
<h2>How does it work?</h2>
<p>In order to use jQuery Easy Columns, you must install it as you would any other jQuery plugin. First, download the zip file using the button above. After downloading the file, extract it to a location of your choice, and move the extracted folder to your server using your favorite FTP client. After moving the plugin to your server (and of course calling the jQuery source into your document), call it in on your site using the following snippet of code:</p>
<pre><br />
<script type="text/javascript" src="/path/to/jquery.easycolumns.js"></script><br />
</pre>Обратите внимание, что Wordpress на самом деле будет вставлять теги br в пост. Само собой разумеется, что когда этот пост несколько раз обновлялся, при просмотре его на веб-интерфейсе дисплей находился совсем рядом с предполагаемым дисплеем.
Единственный способ избавиться от всех добавленных «функций форматирования» - отключить визуальный редактор через мой профиль.
Это хорошее решение для меня, учитывая, что я профессиональный веб-разработчик. Для моих клиентов это решение далеко не элегантно. Мои клиенты, по большей части, будут использовать визуальный редактор. Многие из моих клиентов не очень разбираются в технологиях, и иногда мне нужно исправлять их посты, когда макет нарушается. Это ограничивает меня в использовании визуального редактора, так как я не могу перейти на редактор HTML, не боясь нарушить макет.
Главным образом (и я думаю, что этот ответ мог бы принести пользу большому сообществу), какие конкретные шаги я могу предпринять, чтобы обеспечить следующее:
- Сообщение может быть отредактировано из визуального или HTML-редактора.
- Содержимое сообщения не изменяется никаким образом при переключении между двумя вкладками.
- При сохранении сообщения из редактора HTML дополнительный контент не добавляется.
- При сохранении сообщения из редактора HTML никакие объекты не преобразуются.
- БОНУС: При сохранении сообщения из редактора HTML любой код (например, HTML), который заключен в предварительный тег и еще не преобразован в объекты, будет автоматически преобразован в объекты.
По сути, если мы сможем создать вышеупомянутое поведение в TinyMCE с помощью стороннего плагина, мы сможем подавить все остальные вопросы, касающиеся ложного форматирования, с помощью TinyMCE. Я чувствую, что многие люди могут извлечь из этого пользу.
Просто кажется логичным, что есть определенная функциональность, которую можно ожидать от редактора WYSIWIG, и это идет вразрез с этим. Согласно всей логике и разуму, встроенные в Wordpress функции форматирования довольно бесполезны при их текущей настройке. Мне кажется, что если они хотят использовать эти параметры форматирования, лучше всего включить один или другой редактор, а не оба.
И ПОЖАЛУЙСТА: не отвечайте на эту тему с обходными путями и загрузками для других редакторов WYSIWIG, которые 'решают' проблему. Это основная проблема (хотя на самом деле это не ошибка) с ядром Wordpress, которую необходимо исправить.
РЕДАКТИРОВАТЬ : Хорошо, я работал над этим, и я думаю, что реверс-инжиниринг будет лучшим способом решить эту проблему. Так что сейчас я отключил wpautop (просто для ясности это функция, которая подключается к фильтру "the_content", чтобы добавлять теги p и br перед отображением текста , а не при сохранении текста. Я думаю, что существует некоторая путаница о том, как работает эта функция. wpautop не несет ответственности за изменения, которые вы видите, когда вы переключаетесь между вкладками редактора. Это нечто совершенно другое.
В любом случае, я отключил wpautop, что является хорошей практикой, когда вы используете редактор HTML. С этого момента я отключил визуальный редактор для запуска сначала с ошибками сущности html, которые присутствуют при сохранении поста. Благодаря помощи одного из C. Bavota я нашел фрагмент для преобразования любых тегов в редакторе HTML в их эквивалентные объекты перед отображением их на переднем крае сайта (кредит: http://bavotasan.com/2012/convert -pre-tag-contents-to-html-entity-in-wordpress / ).
#add_filter( 'the_content', 'pre_content_filter', 0 );
/**
* Converts pre tag contents to HTML entities
*
* This function is attached to the 'the_content' filter hook.
*
* @author c.bavota
*/
function pre_content_filter( $content ) {
return preg_replace_callback( '|<pre.*>(.*)</pre|isU' , 'convert_pre_entities', $content );
}
function convert_pre_entities( $matches ) {
return str_replace( $matches[1], htmlentities($matches[1] ), $matches[0] );
}
add_filter( 'the_content', 'pre_content_filter', 10, 2 ); Это эффективно устраняет проблемы с преобразованием всех сущностей в Wordpress при сохранении, обходя его. Теперь вы можете использовать редактор HTML и писать стандартный код между тегами «pre», не выполняя преобразование сущностей самостоятельно. Это решает все проблемы с преобразованием сущностей в Wordpress и гарантирует, что все отображается правильно на внешнем интерфейсе. Теперь нам нужно выяснить, что нужно сделать, чтобы изменить поведение, возникающее при переходе между вкладками. Прямо сейчас может показаться, что при переходе от HTML к визуальной вкладке содержимое вкладки HTML интерпретируется с помощью javascript или чего-то подобного, чтобы попытаться предоставить живое обновление того, как контент должен выглядеть. Это приводит к тому, что теги (которые отображаются не в форме объекта на вкладке HTML) обрабатываются, а не отображаются. Затем, при переключении обратно на вкладку HTML может показаться, что TinyMCE передает текущие данные. Это означает, что когда вы переключаетесь обратно, вы теряете свою HTML-структуру. Нам нужно найти способ сказать TinyMCE преобразовать все в предварительных тегах в его эквивалентные объекты перед загрузкой в окно (по сути, это внутренняя версия того, что мы делали на внешнем интерфейсе, но с использованием tinymce и javascript вместо php и hooks), так что он отображается вместо обработанного. Предложения? s эквивалентные сущности перед загрузкой в окно (по сути, это бэкэнд-версия того, что мы сделали на веб-интерфейсе, но с использованием tinymce и javascript вместо php и hooks), так что он отображается вместо обработанного. Предложения? s эквивалентные сущности перед загрузкой в окно (по сути, это бэкэнд-версия того, что мы сделали на веб-интерфейсе, но с использованием tinymce и javascript вместо php и hooks), так что он отображается вместо обработанного. Предложения?
РЕДАКТИРОВАТЬ 2 :
После еще нескольких исследований преобразование сущностей в предварительном теге, когда они отображаются, работает нормально для содержимого внутри предварительного тега, но, скажем, у меня есть запись в блоге со строкой, подобной этой:
«Далее нам нужно добавить эту строку в наш HTML-файл: <p> Hello, World! </ P>»
Глядя на эту строку, вы можете сказать, что код должен отображаться на сайте, а не анализироваться, однако при сохранении публикации эти сущности декодируются при следующей загрузке редактирования записи и при каждом последующем сохранении сохраняются. как необработанные HTML-теги, которые заставляют их анализироваться на внешнем интерфейсе. Единственное решение, которое я могу придумать, заключается в том, чтобы написать похожий код для тега «code», который я использую для pre, а затем просто обернуть маленькие однострочники в тег «code» и большие куски в тег "pre". У кого-нибудь есть другие идеи?
