Alterne entre as guias Visual e HTML livremente

Portanto, essa pergunta foi levantada várias vezes sob diferentes sinalizadores, no entanto, gostaria de apresentar um thread unificado para uma solução definitiva para esse problema.

No WordPress, por padrão, ao alternar entre os editores HTML e Visual no TinyMCE, certas tags são removidas do conteúdo e outras funcionalidades estranhas ocorrem. Duas soluções conhecidas para escrever código HTML mais eficiente estão usando a remoção da função wp_auto_p usando filtros e instalando o TinyMCE Advanced e habilitando a opção "parar de remover tags p & br".

Infelizmente, isso funciona tão bem.

Veja, por exemplo, o seguinte exemplo:

<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>

Se eu digitar esse código no editor de HTML, com as duas opções listadas acima já ativadas, quando alternar entre os dois editores diferentes, nada acontecerá, o que é esperado. Infelizmente, ao salvar, o código é convertido automaticamente para isso:

<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>

Como você pode ver, todas as entidades dentro da tag pré são convertidas novamente em caracteres HTML reais. Então, se eu salvar esse mesmo post novamente, recebo algo como o seguinte:

<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>

Observe que o Wordpress realmente injeta tags br na publicação. Escusado será dizer que, quando este post foi atualizado algumas vezes, ao visualizá-lo no frontend, a tela não está nem perto da tela pretendida.

A única maneira de me livrar de toda a "funcionalidade de formatação" adicionada foi desabilitar o editor Visual através do meu perfil.

Esta é uma boa solução para mim, considerando que sou um desenvolvedor web profissional. Para meus clientes, esta solução está longe de ser elegante. Meus clientes estarão, na maioria das vezes, usando o editor visual. Muitos dos meus clientes não são muito conhecedores de tecnologia e, às vezes, precisam de mim para corrigir suas postagens quando o layout é interrompido. Isso me limita a usar o editor visual, pois não posso mudar para o editor HTML sem medo de quebrar o layout.

Principalmente (e acho que há uma grande comunidade que poderia se beneficiar dessa resposta), que etapas explícitas posso seguir para garantir o seguinte:

1. Uma postagem pode ser editada no editor Visual ou HTML.
2. O conteúdo de uma postagem não é modificado de forma alguma ao alternar entre as duas guias.
3. Ao salvar uma postagem do editor de HTML, nenhum conteúdo extra é adicionado.
4. Ao salvar uma postagem do editor HTML, nenhuma entidade é convertida.
5. BÔNUS: Ao salvar uma postagem do editor de HTML, qualquer código (HTML, por exemplo) contido em uma pré tag e ainda não convertido em entidades será automaticamente convertido em entidades.

Essencialmente, se pudermos criar o comportamento acima mencionado no TinyMCE através do uso de um plug-in de terceiros, poderemos suprimir todas as outras questões relacionadas à formatação falsa através do uso do TinyMCE. Eu sinto que muitas pessoas poderiam se beneficiar disso.

Parece lógico que existe uma certa funcionalidade que se esperaria de um editor WYSIWIG, e isso vai contra. De acordo com toda a lógica e razão, as funções de formatação incorporadas do Wordpress são bastante inúteis em sua configuração atual. Parece-me que, se eles quiserem usar essas opções de formatação, a melhor opção seria ativar um editor ou outro, não os dois.

E POR FAVOR: Não responda a este tópico com soluções alternativas e downloads para outros editores WYSIWIG que 'corrigem' o problema. Este é um problema subjacente (embora não seja realmente um bug) com o núcleo do Wordpress que precisa ser corrigido.

Edição : Tudo bem, eu tenho trabalhado nisso e estou pensando que a engenharia reversa será a melhor maneira de resolver esse problema. Então, por enquanto, desabilitei o wpautop (que, por questões de clareza, é uma função que se conecta ao filtro "the_content" para adicionar tags p e br antes que o texto seja exibido , não quando o texto é salvo. Acho que existe alguma confusão sobre como essa função funciona, o wpautop não é responsável pelas alterações que você vê acontecendo quando você alterna entre as guias do editor, algo completamente diferente.

De qualquer forma, desativei o wpautop, como é uma boa prática quando você usa o editor de HTML. A partir desse ponto, desabilitei o editor visual para começar primeiro com os erros de entidade html presentes ao salvar uma postagem. Graças à ajuda de um C. Bavota, encontrei um trecho para converter qualquer tag no editor HTML em suas entidades equivalentes antes de exibi-las no front-end do site (crédito: http://bavotasan.com/2012/convert -pre-tag-content-to-html-entidades-no-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 ); 

Isso efetivamente elimina problemas com o Wordpress ao converter todas as entidades em tags ao salvar, contornando-as. Agora, você pode usar o editor HTML e escrever o código padrão entre as tags "pre" sem fazer a conversão da entidade. Isso cuida de todos os problemas com a conversão de entidades no Wordpress e garante que tudo seja exibido corretamente no front-end. Agora, precisamos descobrir o que fazer para modificar o comportamento experimentado ao clicar para frente e para trás entre as guias. No momento, parece que, ao passar da guia HTML para a guia visual, o conteúdo da guia HTML é interpretado por javascript ou algo assim, para tentar fornecer uma atualização ao vivo da aparência do conteúdo. Isso faz com que as tags (que são exibidas em formato de não entidade na guia HTML) sejam processadas em vez de exibidas. Então, ao voltar para a guia HTML, parece que o TinyMCE passa os dados atuais. Isso significa que, quando você volta, perde sua estrutura HTML. Precisamos descobrir uma maneira de dizer ao TinyMCE para converter tudo nas tags anteriores em entidades equivalentes antes de carregá-lo na janela (essencialmente a versão de back-end do que fizemos no front-end, mas com tinymce e javascript em vez de php e hooks), para que seja exibido em vez de processado. Sugestões? s entidades equivalentes antes de carregá-lo na janela (essencialmente a versão de back-end do que fizemos no front-end, mas com tinymce e javascript em vez de php e hooks), para que seja exibido em vez de processado. Sugestões? s entidades equivalentes antes de carregá-lo na janela (essencialmente a versão de back-end do que fizemos no front-end, mas com tinymce e javascript em vez de php e hooks), para que seja exibido em vez de processado. Sugestões?

EDIT 2 :

Depois de mais algumas pesquisas, converter as entidades na tag pré quando elas são exibidas funciona bem para o conteúdo dentro da tag pré, mas digamos que eu tenha um post de blog com uma linha como esta:

"Em seguida, precisamos adicionar esta linha ao nosso arquivo HTML: <p> Olá, mundo! </p>"

Observando esta linha, você pode dizer que o código deve ser exibido no site e não analisado; no entanto, quando a postagem é salva, essas entidades são decodificadas no próximo carregamento de edição da postagem e, a cada salvamento subsequente, elas são salvas. como tags html brutas, o que faz com que sejam analisadas no front-end. A única solução em que posso pensar até agora seria escrever um código semelhante para a tag "code" que estou usando para o pre e, em seguida, apenas enrolar pequenos liners na tag "code" e grandes pedaços no tag "pre". Alguém tem outras idéias?

Tudo bem, então eu já atualizei bastante essa pergunta e está começando a ficar sobrecarregada, então imaginei que escreveria isso como uma resposta, mesmo que não seja completa.

Extrapolando da resposta de @ bueltge, voltei a encontrar o post anterior em questão. Nesse post, havia um plugin listado que eu nunca tinha visto antes: "Preserved HTML Editor Markup". Este plugin não foi atualizado há algum tempo, mas eu apenas o testei com o WP 3.6.1 e é totalmente funcional. Este plugin cuida automaticamente do wpautop, fornece um formato unificado para inserir tags br e p no editor visual e preserva sua marcação ao alternar entre as guias.

Para meus próprios propósitos, expandi esse plug-in com minha própria funcionalidade: conversão automática de qualquer tag html dentro das tags "<code>" para suas respectivas entidades ao salvar. Isso significa que você pode escrever código HTML padrão em tags de código na guia de texto e salvá-lo, e todo o material das tags pré será convertido em entidades para exibição adequada no front end do site e no editor visual. Não é a solução mais elegante que encontrei ainda, mas parece funcionar. Adicione esta linha ao seu functions.php depois de ativar o plugin:

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);

Agora, basta digitar qualquer HTML válido entre as tags de código e, quando você salvar, quando o editor aparecer, todos serão convertidos em entidades. Isso permite que você escreva o código mais rapidamente. Agora, a única coisa que ainda é um problema é que, se você tiver um campo "pré" com uma tag de código aninhada e HTML, vá para a guia visual e tente inserir uma nova linha no código, uma tag br é injetado na sua tag de código no HTML. Tem que haver uma opção para desativar isso no TinyMCE. Independentemente disso, desde que você edite seus campos pré a partir da guia de texto, fique à vontade para alternar livremente entre as guias, adicionar qualquer conteúdo em qualquer guia, salvar em qualquer guia e não precisar se preocupar com a formatação desarrumada!

Isso realmente resolve todos os 5 pontos da minha pergunta inicial. O ponto 2 ainda é um pouco esquisito, mas acredito que, para a maioria das pessoas, isso resolve o problema. Eu pretendo peneirar esse plug-in em algum momento e extrair as partes necessárias, combiná-lo com minhas descobertas e reembalá-lo para download público. Meu objetivo aqui é criar um plug-in de instalação simples, que funcione conforme o esperado.

Espero que isso ajude a todos!

No começo, acho que esse problema foi resolvido desde o WP versão 3.5; ver bilhete 19666 em trac . Mas o tinyMCE tem um gancho por lá, nos dá a chance de alterar o conteúdo dentro do editor e você não deve analisar a saída no frontend.

Um pequeno script de origem. Não testei isso com uma versão atual do WP, era uma solução mais antiga para um cliente.

Adicione esta fonte via plugin e aprimore a marcação. A verificação da função para a tag html <pree, se existir, será substituída pela marcação.

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;
}

Eu tive um problema semelhante ao OP, mas para mim havia um problema em manter-me <h1>em funcionamento <div>. Era isso que eu queria manter ao alternar entre as guias Texto e Visual:

Toda vez que eu troquei de guia <h1>desapareceu. Pesquisei bastante e, para o Wordpress 4.7.3, descobri que existem muitas correções desatualizadas. Houve uma grande atualização do TinyMCE da versão 3 para a 4. As soluções para v.3 não funcionaram para a v.4. Depois de pesquisar e ler a documentação original do TinyMCE versão 4, criei a solução especialmente para o meu caso:

1. Instale o plugin de configuração avançada do TinyMCE
2. defina a valid_childrenconfiguração TinyMCE para+div[h1],h1[div]
3. I additonnaly configurado indent=true, forced_root_block=falsee schema=html5(quando li forced_root_blockDescrição entendia-lo como um wpautopsubstituto)

Como resultado, recebo isso (e é resistente à alternância de guias)