De todas las actualizaciones introducidas en WordPress 4.9 , la biblioteca CodeMirror que se integra en Core podría tener las implicaciones de mayor alcance.
En primer lugar, es una biblioteca de JavaScript que se integra con el editor para proporcionar errores, resaltado de sintaxis y sugerencias contextuales para fragmentos de código dentro del panel de control de WordPress. Esencialmente, hace que sea mucho más seguro para los que no son programadores (¡y los programadores!) hurgar y aprender WordPress sin estropear las cosas ni pasar por una pantalla blanca en sus sitios web. (Tenemos un tutorial genial de los cambios aquí ).
Sin embargo, lo más importante es la nueva integración con la biblioteca CodeMirror y las API de WordPress para que los desarrolladores de complementos y temas puedan usarla.
Lo mejor de todo es que es una biblioteca comprobada que se usa en Internet. Desde Bitbucket y Github hasta Firefox y Chrome Developer Tools . Esta no es una solución a medias. Los colaboradores principales encontraron la mejor biblioteca. Luego creó los ganchos que WordPress necesitaba para usarlo. No de la otra manera.
Actualmente, hay dos formas de trabajar con editores dentro de sus complementos y temas. Puede utilizar cualquiera de estas dos funciones.
- wp_enqueue_code_editor()
- wp_enqueue_editor()
Estos funcionan de manera bastante similar entre sí, y puede leer sobre las diferencias en el Codex. Esencialmente, puede pasar un argumento codemirror para permitir que ese campo se convierta de una entrada de texto estándar al nuevo editor de código especial para WP llamando a un script especial code-editor.js .
La documentación del Codex lo pone así:
Por ejemplo, si edita CSS, habilitará el linting y si edita HTML, habilitará el cierre automático de etiquetas.
Y tampoco es solo para CSS y HTML. No no no.
Los editores de archivos ahora también cuentan con el mismo resaltado de sintaxis, autocompletado y verificación de errores impulsados por CodeMirror. Las extensiones de archivo permitidas en los editores de archivos que pueden editar se han ampliado para incluir formatos para los que CodeMirror tiene modos: conf, css, diff, patch, html, htm, http, js, json, jsx, less, md, php, phtml, php3, php4, php5, php7, phps, scss, sass, sh, bash, sql, svg, xml, yml, yaml, txt.
O en términos más sucintos: casi todo
Esa adición por sí sola abre muchas posibilidades nuevas para desarrolladores y diseñadores. Los desarrolladores y autores finalmente pueden expandir el tipo de control que pueden ofrecer a los usuarios. Es el mismo tipo de control que tienen el nuevo editor y personalizador.
Cavar más profundo, cavar más seguro
Un cambio realmente bueno es que los editores ahora pueden profundizar en el sistema de archivos. Con las protecciones de CodeMirror, los editores basados en tableros profundizan más allá del límite anterior de dos directorios. No significa mucho para muchos (¿la mayoría?) de los usuarios de WP. Pero esta es una libertad que los desarrolladores pueden aprovechar.
CodeMirror se abre a un entorno de codificación completo dentro del panel de control de WordPress. Ahora puedes Al poder profundizar en el sistema de archivos del sitio. Sin embargo, al hacerlo, se abre a un gran peligro. Los usuarios no solo podrán editar los archivos CSS y HTML (dentro de los límites protegidos del linter), sino que también tendrán acceso a los archivos PHP más delicados que hacen que toda la instalación funcione como la seda.
Y todos sabemos que lo último que queremos es que alguien que no sea codificador haga un lío con algo de PHP.
Entra en el arenero
Los desarrolladores también han cambiado la forma en que se guardan los archivos PHP cuando se usa un editor integrado. Esencialmente, esto es lo que obtienes cuando abres un archivo PHP ahora:
- Al abrir un archivo PHP, edita una nueva instancia separada de ese archivo. Su contenido se mantiene dentro de una variable mediante el uso de cookies .
- Si ha cambiado el archivo de tal manera que se producirá un error fatal y hará que el editor sea inaccesible, los cambios se deshacen y el archivo PHP original que deseaba editar permanece sin cambios.
- Si no hay un error fatal en este punto, se realizará otra verificación para ver si el sitio web en sí es inaccesible debido a un error fatal de PHP. Nuevamente, si hay un error, el archivo original se revierte y aparecerá un mensaje de error que le indicará qué sucedió y por qué.
- Finalmente, si no hay ningún error que impida que el sitio se ejecute en el lado del administrador o en el front-end, sus cambios se implementarán de inmediato.
Y como último mecanismo de seguridad, el editor ve una mala mojo de PHP. Si hay suficiente para mantener el PHP dentro de un bucle invertido que no se puede resolver, el nuevo editor de código es lo suficientemente inteligente como para detenerlo y enviar al usuario un mensaje de que probablemente sería mejor si hiciera esos cambios a través de FTP . .
Seamos honestos aquí también. Si no pueden realizar los cambios en los archivos PHP sin ese tipo de errores dentro del tablero, no van a realizar actualizaciones manuales de FTP. Que es otra característica de seguridad totalmente divorciada de WordPress integrada en 4.9.
Piensa en las posibilidades
La popularidad de los cursos de codificación en línea y los bootcamps hacen que esta inclusión sea perfecta para los complementos de aprendizaje electrónico. Con las bibliotecas React existentes en uso para complementos y temas como Gutenberg, Calypso y nuestro propio Divi , la edición de estilo IDE está aquí. (Por cierto, CodePen ya usa CodeMirror para esto).
Estar vinculado directamente al núcleo de WordPress también significa que incluso permitir pequeños ajustes y personalizaciones se volvió mucho más seguro. Por ejemplo, ahora puede otorgar a los usuarios acceso a un control más directo de CSS y diseño dentro de su complemento. Y puedes hacerlo sin miedo a que rompan algo por completo.
Al poder integrar esa personalización en el propio complemento, en lugar de simplemente documentar las clases y los ID que lo controlan, puede brindar un mejor soporte y UX para el producto. Incluso entonces, puede controlar el entorno en el que los usuarios pueden personalizar su interfaz de usuario y, por lo tanto, ofrecer la mejor experiencia para que nada más en su sitio pueda verse (teóricamente) afectado por los cambios que realizan.
Si bien técnicamente este tipo de opción era totalmente posible antes de la versión 4.9, no había muchas razones para hacerlo. Había pocas salvaguardas. Ahora, sin embargo, con un IDE incorporado (más o menos), obtienes (y puedes ofrecer) tanto control que el cielo es el límite.
¡Diviértanse, niños!
Entre la zona de pruebas en la que jugamos y las posibilidades y el potencial que 4.9 nos brindó con la integración de CodeMirror, realmente nunca ha habido un mejor momento en la historia de WordPress para que tanto los desarrolladores como los usuarios se sumerjan profundamente en el código. Es hora de aprender cómo funcionan realmente las cosas.
Después de todo, ¿qué es lo peor que podría pasar?
¿Cuáles son sus planes para integrar CodeMirror en sus propios complementos y temas? ¡Hablemos en los comentarios!
Imagen destacada del artículo por Sarawut St / shutterstock.com