 Vengo a presentaros a David Pérez. David Pérez es un apasionado por cómo los plugins evolucionan en nuestro mundo web de WordPress. Por eso, él hace plugins, está dentro del equipo de revisión de plugins de WordPress. En su día a día es director de la Agencia de Marketing y Desarrollo Web Close. Así que por favor, recibámole con un grandísimo aplauso. Levanta en la mano quién no ha roto una web subiendo su desarrollo en producción. Hay unos cuantos, hay algunos que no han levantado. Y quien levanta en la mano quién le gustaría mejorar el proceso. Hoy vamos a dar en diez minutillos un proceso en el que vamos a subir nuestro desarrollo a través de control de versiones y subiendo la producción, creando más garantías de nuestro desarrollo que no va a romper la web en producción. Al final, lo que queremos es garantizar nuestro desarrollo, no rompe y, aparte, mejora nuestro flujo de trabajo. Le he puesto la temática de Steenersing, veréis por qué, porque siempre pasan cosas raras y el gran malo de la película es Begnas, hay que salvarlo. Y vamos a ver un poquito el proceso porque yo trabajo y desde hace ya un tiempo me ha cambiado totalmente la forma de trabajar y es de mi agencia en general. Desde cuándo podemos hacerlo? Podemos hacerlo desde el 11 de agosto de 2020, en el que en una relí de Warp 5.5 nos dejaba subir un zip y que ese zip reemplazara el plan que estaba ya subido. Direis, bueno, una cosa sencilla, costó 11 años, un ticket de 11 años estuvo dando vueltas hasta que el 11 de agosto se publique. Ahí tenéis los enlaces de los tickets y de la conversación que tuvieron y llama mucho la atención que es una cosa que vea esto sencilla, toda la complicación que dio y cuánto duró. Y antes se hacía con dos plugins y el que quería hacer este flujo de trabajo tenía que instalar ese plugin y luego hacer este flujo. Ahora ya no, a partir de Warp 5.5 lo tenéis. ¿Por qué hacerlo así? ¿Por qué ganan al malo? Bien, sobre todo tenemos un control de nuestras versiones de desarrollo. Vamos creando versiones, la vamos documentando y la vamos subiendo. Lo ideal es tener una web espejo o staging en el que nosotros subamos ese desarrollo, probemos que todo funciona bien y automáticamente después subirlo a producción, automáticamente o con ciertas revisiones antes. Lo bueno de este proceso es que no dependemos de libras de terceros, no sé si habéis tenido alguna librería de que se conecta a GitHub o algún repositorio, mide así una nueva versión, se descarga y lo actualiza. Esa librería, suprendentemente, te crea un lag en el admin y nosotros desde hace tiempo ya lo quitamos porque nos creaba, si tenemos varios plugins nuestros propios nos creaba un lag, o sea, un lapso en esa conexión que no era necesaria porque es un control que tú tienes de un plugin que tú puedes subir cuando tú quieres. Permite subir y comparar la versión actual respecto a la que tenemos. Entonces puedes ver, incluso si tú en el propio desarrollo en la cabecera del plugin has puesto, si soporta la versión de WordPress, si soporta el PHP, pues todo eso lo puedes comprobar justo cuando estás subiendo, antes incluso de terminar de reemplazar el desarrollo. Normalmente limpia las caches de objetos, lo que hace es que si tú estás cambiando por FTP en caliente el plugin, si tu servidor te ofrece una cacha de objetos posiblemente no verás el desarrollo actualizado y si entra al conflicto con otros plugins puedes hacerles problemas. Con este proceso no, tú subes CIS, reemplazas y limpias caches. Los CIS son mucho más limpios porque no sé si habéis encontrado CIS con carpetas con no de módules, con la carpeta de guijas, con todo esto. Mucho más limpio y muy fácil de compartir y de distribuir a nuestros clientes o directamente para subir. Y es un proceso que es rápido y es confiable. Es decir, cuando ya la tienes estructurado y montado ya puedes subir perfectamente. Muy bien, David, me contestas estas cosas, está muy bien. Pero cómo se hace, ¿vale? ¿Quién de aquí sabe qué es WP Click? ¿Hay algún niño que no? WP Click es la forma de trabajar con WordPress de la línea de comando. Nos permite automatizar muchísimos procesos que, por ejemplo, actualizar los plugins de la propia instalación, incluso cambiar ajustes de la tabla de Optium. Podemos automatizar totalmente la instalación de WordPress atrás de WP Click. Os recomiendo que lo instaléis. Lo podéis utilizar tanto en local como en producción y, aparte, tiene unos comandos. Hay este comando que yo ofrezco que lo instaláis. Es el que permite poder hacer este archivo de distribución zip. Lo instalamos con WP Click y, una vez que se instala, ya tenemos para poder utilizar el comando. Utilizamos el comando, tiene varias partes. El comando, la parte de el slew de nuestro plugin donde está y a dónde queremos guardarlo. Lo suelo tener un nip, un tespander o cualquier cosa. Entonces, le pongo el slew y siempre guardo toda la distribución de mis versiones en una carpeta. Me crea un archivo plugin punto y su versión. Esta versión, ojo, que es la que nosotros ponemos en la cabecera del PHP del plugin. Entonces, es muy importante llevar la versión y, aparte, otra cosa muy importante es tenerlo documentado. Que al final, si estamos trabajando para clientes, tenemos que justificar los nuevos desarrollos y ahí lo vamos viendo. Con esa versión, ya sabéis, la gestión de versiones, la menor, la mayor, vamos viendo un poco y vamos creando nuestras nuevas versiones. Hablando de versiones, una cosa interesante también es utilizar beta 1, beta 2. Hay veces que la versión que tú tienes la quiera subir a este sitio espejo podría hacer una versión beta para subirlo, revisarlo y ya cuando la tienes definitiva, compila otra vez y creas tu versión definitiva. Y aquí la magia de todo esto y cuando salimos corriendo es porque hay un archivo que se añade a nuestro root del plan que se llama Disignore, que es lo que hace es que ignoran las carpetas que nosotros no queremos que estén en nuestro archivo de distribución, en el CIP. El típico de sectores, si tenemos un Macintosh, el típico punto git sea un repositorio, el no de módulo es, que suele ocupar 60 megas, 70 megas. Entonces, todo este archivo, que yo solo pone en mi archivo, digamos que te lo limpia por defecto y entonces te tienes que despreocupar. ¿Cuántas veces hemos hecho manualmente un CIP y hemos tenido que limpiarlo antes, borrando cosas, luego copiando y muchas veces incluso hasta borrando, volvían a aparecer archivos y decir que tú pasabas a producirte contra los archivos que no querías que estuvieran? La solución definitiva. Y también muchas veces tenemos carpetas de desarrollo que nosotros utilizamos, cualquier cosa, el Composer, por ejemplo, o incluso el Vendor. Hay veces que el Vendor lo utilizamos en desarrollo, no lo utilizamos para utilizarlo en el planning, pues eso también lo podemos unir para que no salga en nuestra versión. Y luego hay que subir a producción. Todos sabemos ya que los bienes no se suben a producción. Se suben los lunes o los martes. Pues subiendo lunes o martes, una vez que subimos, ese archivo que hemos tenido, que hemos compilado, que hemos hecho un CIP, que lo vamos a probar en nuestros sitios, espejos, lo que hemos preparado, pues vamos a subirlo. Hay un proyecto dentro de World Predelcore de que pueda hacer rollback, es decir, que podamos subir archivos y si quiera algún problema, puede volver hacia atrás. Llegará pronto, pero mientras tanto tenemos el Staging, se rompa nada, que todo funcione perfectamente y, una vez comprobados, subimos a producción. Una cosa que solo aconsejar es crear nuestro propio release en el propio repositorio. Creas tu release y ahí ponemos la parte que habíamos dicho de documentar las versiones para tenerlo documentado esa versión. Y aparte, release, yo utilizo Guijab. Bueno, nosotros utilizamos Guijab. Incluso subí un archivo. Aparte de que te creas el propio release, tú puedes subir el archivo de distribución que ya está listo para subir a cualquier otra página web. Que ha tratado, pues, los Dignore y todo lo que habíamos visto. Y súper importante, documentar los cambios en el réanme. Cada vez que hacemos un cambio en nuestro desarrollo, línea al canto en el réanme de ir documentando pues cambiado, arreglado y mejorado de cara al cliente o de cara al cliente podamos justificar lo que hemos hecho. Hemos vencido al malo, por lo menos no se nos ha roto la página web. Yo soy Daís Pérez y eso, animo a trabajar nuestro flujo de trabajo. Nosotros ya hemos un tiempo trabajando con este flujo. Creamos nuestro zip, tenemos nuestra carpeta de proyectos incluso para plugin comerciales y lo que hacemos es tener nuestro zip limpito, listo para distribuir para compartir y incluso para vender. Nuestros plugins comerciales también lo hacemos con este proceso. Muchas gracias y las días positivas las tenés aquí en davisperregar.com barra WC Madrid 23.