tinymce – Cambiar entre la pestaña Visual y HTML libremente

Pregunta:

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 forma predeterminada, al alternar entre los editores HTML y Visual en TinyMCE, ciertas etiquetas se eliminan del contenido y se producen otras funciones extrañas. Dos soluciones alternativas conocidas para escribir código HTML más eficiente son eliminar la función wp_auto_p mediante filtros, instalar TinyMCE Advanced y habilitar la opción "dejar de eliminar etiquetas p & br".

Esto solo funciona tan 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, cuando cambio entre los dos editores diferentes, no sucede nada, lo cual es de esperar. 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 vuelven a convertir 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 inyectará etiquetas br en la publicación. No hace falta decir que, cuando esta publicación se ha actualizado varias veces, al verla en la interfaz, la pantalla no está ni cerca de la pantalla deseada.

La única forma en que parece que me he deshecho de toda la "funcionalidad de formato" agregada 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 conocedores de la 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 asegurar lo siguiente:

  1. Una publicación se puede editar desde el editor visual o HTML.
  2. El contenido de una publicación no se modifica de ninguna manera al cambiar 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 convierte ninguna entidad.
  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 mencionado anteriormente en TinyMCE mediante el 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 mucha gente podría beneficiarse de esto.

Parece lógico que exista una cierta funcionalidad que uno esperaría de un editor WYSIWIG, y esto va en contra. De acuerdo con toda la lógica y la razón, las funciones de formato integradas 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 responda a este hilo con soluciones provisionales 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 : Muy bien, he estado trabajando en esto y creo que la ingeniería inversa será la mejor manera de resolver este problema. Entonces, por ahora, he deshabilitado wpautop (que solo para mayor claridad es una función que se conecta al 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 opera esta función, wpautop no es responsable de los cambios que ves que ocurren cuando cambias entre las pestañas del editor. Eso es algo completamente diferente.

De todos modos, he desactivado wpautop, ya que es una buena práctica cuando se usa el editor HTML. A partir de ese momento, desactivé 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 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-etiqueta-contenido-a-entidades-html-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 efectivamente los problemas con WordPress al convertir todas las entidades en etiquetas al guardarlas eludiéndolas. Ahora, puede usar el editor HTML y escribir código estándar entre las etiquetas "pre" sin realizar la conversión de la entidad usted mismo. Esto se encarga de todos los problemas con la conversión de entidades en WordPress y se asegura de que todo se muestre correctamente en la interfaz. Ahora, tenemos que averiguar en qué conectarnos para modificar el comportamiento experimentado al hacer clic hacia adelante y hacia atrás entre pestañas. En este momento, parecería que al pasar de HTML a la pestaña visual, el contenido de la pestaña HTML es interpretado por javascript o algo 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 sin 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 regresa, pierde su 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 backend 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?

EDITAR 2 :

Después de investigar un poco más, convertir 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 mirar 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 la publicación, y en cada guardado posterior se guardan como etiquetas html sin procesar, lo que hace que se analicen en la interfaz. La única solución en la que puedo pensar 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ñas líneas en la etiqueta "código" y grandes trozos en la etiqueta "pre". ¿Alguien más tiene otras ideas?

Respuesta:

Muy bien, ya he actualizado mucho esta pregunta y está empezando a sobrecargarse, así que pensé que escribiría esto como una respuesta aunque no sea completa.

Extrapolando la respuesta de @ bueltge, volví y encontré su publicación anterior en cuestión. En esa publicación, había un complemento en la lista que nunca había visto antes: "Marcado del editor HTML preservado". Este complemento no se ha actualizado en un tiempo, pero lo acabo de probar 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 propósitos, 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 hasta ahora, pero parece funcionar. Agregue esta línea a su 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. Independientemente, siempre que edite sus campos previos desde la pestaña de texto, puede cambiar libremente entre las pestañas, agregar cualquier contenido en cualquier pestaña, guardar desde cualquiera de las pestañas y no tener que preocuparse por el formato desordenado.

En realidad, esto resuelve los 5 puntos de mi pregunta inicial. El punto 2 todavía es un poco inestable, pero creo que para la mayoría de los propósitos de la gente, esto soluciona el 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 clic que funcione como se esperaba.

¡Espero que esto ayude a todos!

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım