Cambia entre las pestañas Visual y HTML libremente

Entonces, esta pregunta se ha planteado muchas veces bajo diferentes banderas, sin embargo, me gustaría presentar un hilo unificado para una solución definitiva a este problema.

En WordPress, de manera predeterminada, al alternar entre los editores HTML y Visual en TinyMCE, ciertas etiquetas se eliminan del contenido y se produce otra funcionalidad extraña. Dos soluciones conocidas para escribir código HTML más eficiente son eliminar la función wp_auto_p mediante filtros e instalar TinyMCE Advanced y habilitar la opción "detener la eliminación de etiquetas p & br".

Esto solo funciona muy bien, desafortunadamente.

Tomemos, por ejemplo, el siguiente ejemplo:

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

Si escribo este código en el editor HTML, con las dos opciones enumeradas anteriormente ya habilitadas, entonces cuando cambio entre los dos editores diferentes, no sucede nada, lo que se espera. Desafortunadamente, al guardar, el código se convierte automáticamente a esto:

<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 puede ver, todas las entidades dentro de la etiqueta previa se convierten nuevamente en caracteres HTML reales. Luego, si guardo esta misma publicación nuevamente, obtengo algo como lo siguiente:

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

Tenga en cuenta que Wordpress realmente inyectará etiquetas br en la publicación. No hace falta decir que cuando esta publicación se ha actualizado varias veces, cuando se ve en la interfaz, la pantalla no se acerca a la pantalla deseada.

La única forma en que me he librado de todas las "funciones de formato" agregadas ha sido deshabilitar el editor Visual a través de mi perfil.

Esta es una buena solución para mí, considerando que soy un desarrollador web profesional. Para mis clientes, esta solución está lejos de ser elegante. Mis clientes, en su mayor parte, utilizarán el editor visual. Muchos de mis clientes no son muy expertos en tecnología y, a veces, necesitan que arregle sus publicaciones cuando se rompe el diseño. Esto me limita a usar el editor visual, ya que no puedo cambiar al editor HTML sin temor a romper el diseño.

Principalmente (y creo que hay una gran comunidad que podría beneficiarse de esta respuesta), qué pasos explícitos puedo seguir para garantizar lo siguiente:

1. Se puede editar una publicación desde el editor Visual o HTML.
2. El contenido de una publicación no se modifica de ninguna manera cuando se cambia entre las dos pestañas.
3. Al guardar una publicación desde el editor HTML, no se agrega contenido adicional.
4. Al guardar una publicación desde el editor HTML, no se convierten entidades.
5. BONIFICACIÓN: Al guardar una publicación desde el editor HTML, cualquier código (HTML, por ejemplo) que esté envuelto dentro de una etiqueta previa y que no se haya convertido en entidades, se convertirá automáticamente en entidades.

Esencialmente, si podemos crear el comportamiento antes mencionado en TinyMCE a través del uso de un complemento de terceros, podemos resolver todas las demás preguntas relacionadas con el formato falso mediante el uso de TinyMCE. Siento que muchas personas podrían beneficiarse de esto.

Simplemente parece lógico que haya una cierta funcionalidad que uno esperaría de un editor WYSIWIG, y esto va en contra de eso. De acuerdo con toda lógica y razón, las funciones de formato incorporadas de Wordpress son bastante inútiles con su configuración actual. Me parece que si quieren usar estas opciones de formato, su mejor opción sería habilitar un editor u otro, no ambos.

Y POR FAVOR: no conteste este hilo con soluciones y descargas para otros editores WYSIWIG que 'solucionen' el problema. Este es un problema subyacente (aunque no es realmente un error) con el núcleo de Wordpress que debe corregirse.

EDITAR : Bien, he estado trabajando en esto y creo que la ingeniería inversa será la mejor manera de resolver este problema. Así que por ahora, he deshabilitado wpautop (que para mayor claridad es una función que se engancha en el filtro "the_content" para agregar etiquetas p y br antes de que se muestre el texto , no cuando se guarda el texto. Creo que existe cierta confusión en cuanto a cómo funciona esta función. wpautop no es responsable de los cambios que ve que ocurren cuando cambia entre pestañas del editor. Eso es algo completamente diferente.

De todos modos, he desactivado wpautop, como es una buena práctica cuando usas el editor HTML. A partir de ese momento, deshabilité el editor visual para comenzar primero con los errores de entidad html que están presentes al guardar una publicación. Gracias a la ayuda de un C. Bavota, encontré un fragmento para convertir cualquier etiqueta en el editor HTML a sus entidades equivalentes antes de mostrarlas en la parte frontal del sitio (crédito: http://bavotasan.com/2012/convert -pre-tag-contenidos-a-html-entidades-en-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 ); 

Esto elimina eficazmente los problemas con Wordpress al convertir todas las entidades en etiquetas al guardar al eludirlo. Ahora, puede usar el editor HTML y escribir código estándar entre etiquetas "pre" sin realizar la conversión de la entidad usted mismo. Esto se ocupa de todos los problemas con la conversión de entidades en Wordpress y se asegura de que todo se muestre correctamente en el front-end. Ahora, necesitamos descubrir en qué conectarnos para modificar el comportamiento experimentado al hacer clic entre las pestañas. En este momento, parece que al pasar del HTML a la pestaña visual, el contenido de la pestaña HTML se interpreta mediante JavaScript o algo así para intentar proporcionar una actualización en vivo de cómo debería verse el contenido. Esto hace que las etiquetas (que se muestran en forma de no entidad en la pestaña HTML) se procesen en lugar de mostrarse. Luego, al volver a la pestaña HTML, parecería que TinyMCE pasa los datos actuales. Esto significa que cuando regresas, pierdes tu estructura HTML. Necesitamos encontrar una manera de decirle a TinyMCE que convierta todo en etiquetas previas a sus entidades equivalentes antes de cargarlo en la ventana (esencialmente la versión de fondo de lo que hicimos en el frontend pero con tinymce y javascript en lugar de php y hooks), para que se muestre en lugar de procesarse. Sugerencias? s entidades equivalentes antes de cargarlo en la ventana (esencialmente la versión de back-end de lo que hicimos en la interfaz pero con tinymce y javascript en lugar de php y hooks), para que se muestre en lugar de procesarse. Sugerencias? s entidades equivalentes antes de cargarlo en la ventana (esencialmente la versión de back-end de lo que hicimos en la interfaz pero con tinymce y javascript en lugar de php y hooks), para que se muestre en lugar de procesarse. Sugerencias?

EDITAR 2 :

Después de un poco más de investigación, la conversión de las entidades en la etiqueta previa cuando se muestran funciona bien para el contenido dentro de la etiqueta previa, pero digamos que tengo una publicación de blog con una línea como esta:

"A continuación, debemos agregar esta línea a nuestro archivo HTML: <p> ¡Hola, mundo! </p>"

Al observar esta línea, puede decir que se supone que el código se muestra en el sitio y no se analiza, sin embargo, cuando se guarda la publicación, estas entidades se decodifican en la siguiente carga de edición de publicación, y en cada guardado posterior se guardan como etiquetas html sin procesar, lo que hace que se analicen en el front-end. La única solución que se me ocurre hasta ahora sería escribir un código similar para la etiqueta "código" que estoy usando para el pre, y luego simplemente envolver pequeños revestimientos en la etiqueta "código", y trozos grandes en el etiqueta "pre". ¿Alguien más tiene otras ideas?

Muy bien, ya he actualizado esta pregunta un montón y está comenzando a sobrecargarse, así que pensé que escribiría esto como respuesta a pesar de que no es completa.

Extrapolando la respuesta de @ bueltge, en realidad volví y encontré su publicación anterior en cuestión. En esa publicación, había un complemento listado que nunca había visto antes: "Marcado del editor HTML preservado". Este complemento no se ha actualizado en mucho tiempo, pero lo probé con WP 3.6.1 y es completamente funcional. Este complemento se encarga automáticamente de wpautop, proporciona un formato unificado para insertar etiquetas br y p dentro del editor visual y conserva su marcado al cambiar entre pestañas.

Para mis propios fines, amplié este complemento con mi propia funcionalidad: conversión automática de cualquier etiqueta html dentro de las etiquetas "<code>" a sus respectivas entidades al guardar. Esto significa que puede escribir código HTML estándar en etiquetas de código dentro de la pestaña de texto, y luego guardarlo, y todas las cosas en las etiquetas previas se convertirán en entidades para una visualización adecuada en la parte frontal del sitio y el editor visual. No es la solución más elegante que he encontrado todavía, pero parece funcionar. Agregue esta línea a functions.php después de activar el complemento:

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

Ahora, simplemente escriba cualquier HTML válido entre las etiquetas de código, y cuando guarde, cuando el editor vuelva a aparecer, todos se convertirán en entidades. Esto le permite escribir código más rápido. Ahora, lo único que sigue siendo un problema es que si tiene un campo "pre" con una etiqueta de código anidada y HTML, y va a la pestaña visual e intenta insertar una nueva línea en el código, una etiqueta br se inyecta en su etiqueta de código en el HTML. Tiene que haber una opción para deshabilitar esto en TinyMCE. En cualquier caso, siempre que edite sus campos previos desde la pestaña de texto, puede cambiar libremente entre las pestañas, agregar cualquier contenido debajo de cualquier pestaña, guardar desde cualquiera de las pestañas y no tener que preocuparse por el formato desordenado.

Esto realmente resuelve los 5 puntos de mi pregunta inicial. El punto 2 todavía es un poco inestable, pero creo que para los propósitos de la mayoría de las personas, esto se ocupa del problema. Planeo examinar este complemento en algún momento y extraer las partes necesarias, combinarlo con mis hallazgos y volver a empaquetarlo para su descarga pública. Mi objetivo aquí es crear un complemento de instalación simple con un solo clic que funcione como se esperaba.

Espero que esto ayude a todos!

Al principio, creo que este problema se resolvió desde la versión 3.5 de WP; ver boleto 19666 en trac . Pero tinyMCE tiene un gancho que nos da la oportunidad de cambiar el contenido dentro del editor y no debe analizar la salida en la interfaz.

Un pequeño script fuente. No tengo prueba de esto con una versión actual de WP, era una solución más antigua para un cliente.

Agregue esta fuente a través del complemento y mejore el marcado. La función verifica la etiqueta html <prey, si existe, se reemplazará por marcado.

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

He tenido un problema similar al OP, pero para mí no fue un problema con el mantenimiento <h1>en <div>. Esto es lo que quería mantener al cambiar entre las pestañas Visual y Texto:

Cada vez que cambiaba de pestaña <h1>desaparecía. Hice mucha búsqueda, y para Wordpress 4.7.3 descubrí que hay muchas correcciones desactualizadas. Hubo una importante actualización de TinyMCE de la versión 3 a 4. Las soluciones para la v.3 no funcionaron para la v.4. Después de buscar en Google y leer la documentación original de TinyMCE versión 4, se me ocurrió la solución, especialmente para mi caso:

1. Instalar el complemento de configuración avanzada de TinyMCE
2. establezca la valid_childrenconfiguración de TinyMCE en+div[h1],h1[div]
3. Además indent=true, configuré forced_root_block=falsey schema=html5(cuando leí la forced_root_blockdescripción la entendí como un wpautopsustituto)

Como resultado obtengo esto (y es resistente al cambio de pestañas)