Свободно переключайтесь между вкладками Visual и HTML

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

В 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>
&lt;script type=&quot;text/javascript&quot; src=&quot;/path/to/jquery.easycolumns.js&quot;&gt;&lt;/script&gt;
</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, не боясь нарушить макет.

Главным образом (и я думаю, что этот ответ мог бы принести пользу большому сообществу), какие конкретные шаги я могу предпринять, чтобы обеспечить следующее:

1. Сообщение может быть отредактировано из визуального или HTML-редактора.
2. Содержимое сообщения не изменяется никаким образом при переключении между двумя вкладками.
3. При сохранении сообщения из редактора HTML дополнительный контент не добавляется.
4. При сохранении сообщения из редактора HTML никакие объекты не преобразуются.
5. БОНУС: При сохранении сообщения из редактора 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". У кого-нибудь есть другие идеи?

Хорошо, я уже обновил этот вопрос на тонну, и он начинает перегружаться, поэтому я решил написать это как ответ, хотя и не полный.

Экстраполируя ответ @ bueltge, я на самом деле вернулся и нашел его предыдущий пост под вопросом. В этом посте был указан плагин, который я никогда раньше не видел: «Сохраненная разметка HTML Editor». Этот плагин давно не обновлялся, но я только что протестировал его с WP 3.6.1, и он полностью функционален. Этот плагин автоматически заботится о wpautop, предоставляет унифицированный формат для вставки тегов br и p в визуальном редакторе и сохраняет разметку при переключении между вкладками.

Для моих собственных целей я расширил этот плагин с моей собственной функциональностью: автоматическое преобразование любых тегов html внутри тегов <code> в соответствующие объекты при сохранении. Это означает, что вы можете написать стандартный HTML-код в тегах кода на текстовой вкладке, а затем сохранить его, и весь материал в предварительных тегах преобразуется в объекты для правильного отображения в интерфейсе сайта и визуальном редакторе. Это не самое элегантное решение, которое я нашел, но, похоже, оно работает. Добавьте эту строку в ваши functions.php после активации плагина:

function code_content_conversion_filter( $content ) {
        return preg_replace_callback( '|<code.*>(.*)</code|isU' , 'convert_entities', $content );
}

function convert_entities( $matches ) {
        return str_replace( $matches[1], htmlspecialchars($matches[1], ENT_QUOTES | ENT_HTML5, 'UTF-8', FALSE ), $matches[0] );
}

add_filter( 'content_save_pre', 'code_content_conversion_filter', 0);

Теперь просто введите любой допустимый HTML-код между тегами кода, и при сохранении, когда редактор снова откроется, все они будут преобразованы в сущности. Это позволяет вам писать код быстрее. Теперь единственное, что все еще остается проблемой, это то, что если у вас есть поле «pre» с вложенным тегом code и HTML в нем, и вы переходите на визуальную вкладку и пытаетесь вставить новую строку в код, тег br вставляется в ваш кодовый тег в HTML. Должна быть возможность отключить это в TinyMCE. В любом случае, до тех пор, пока вы редактируете свои предварительные поля на текстовой вкладке, вы можете свободно переключаться между вкладками, добавлять любой контент на любую вкладку, сохранять на любой вкладке и не беспокоиться о неправильном форматировании!

Это фактически решает все 5 пунктов моего начального вопроса. Точка 2 все еще немного ненадежна, но я считаю, что для большинства людей это решает проблему. Я планирую просеять этот плагин в какой-то момент и извлечь необходимые части, объединить его с моими находками и упаковать его для публичного скачивания. Моя цель здесь - создать простой плагин для установки одним кликом, который работает, как и ожидалось.

Надеюсь, это поможет всем!

Сначала я думаю, что эта проблема была решена начиная с версии WP 3.5; см. билет 19666 в трек . Но у tinyMCE есть ловушка, которая дает нам возможность изменить содержимое внутри редактора, и вы не должны анализировать выходные данные в веб-интерфейсе.

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

Добавьте этот источник через плагин и улучшите разметку. Функция проверяет наличие html-тега <preи, если существует, будет заменена на разметку.

add_filter( 'tiny_mce_before_init', 'fb_correction_content_tiny_mce' );

function fb_correction_content_tiny_mce( $init ) {

    $init['setup'] = "function(ed) {
        ed.onBeforeSetContent.add( function(ed, o) {

            if ( o.content.indexOf('<pre') != -1 ) {
                o.content = o.content.replace(
                    /<pre[^>]*>[\\s\\S]+?<\\/pre>/g,
                    function(a) {
                        return a.replace(/(\\r\\n|\\n)/g, '<br />');
                    }
                );
            }
        } );
    }";

    return $init;
}

У меня была проблема , похожий на OP, но для меня была проблема с сохранением <h1>в <div>. Вот что я хотел сохранить при переключении между вкладками Текст и Визуал:

Каждый раз, когда я переключал вкладки <h1>исчезали. Я много занимался поиском, и для Wordpress 4.7.3 я обнаружил, что там много устаревших исправлений. Было обновление мэра TinyMCE с версии 3 до 4. Решения для v.3 не работали для v.4. После дополнительного поиска в Google и прочтения оригинальной документации по TinyMCE версии 4 я нашел решение, особенно для моего случая:

1. Установите плагин расширенной конфигурации TinyMCE
2. установите для TinyMCE valid_childrenзначение+div[h1],h1[div]
3. Я настроил аддитонналы indent=true, forced_root_block=falseи schema=html5(когда я прочитал forced_root_blockописание, я понял это как wpautopзамену)

В результате я получаю это (и оно устойчиво к переключению вкладок)