Crea el archivo de distribución de tu plugin con wp-cli

¿Cómo se hace el plugin? Así que por favor, recibámosle con un grandísimo apalso. Que levante 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 que levante 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 Stranger Things veréis por qué, porque siempre pasan cosas raras y el gran malo de la película es Begna al que 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 release de WordPress 5.5 nos dejaba subir un zip y que ese zip reemplazara el plugin que estaba ya subido. Diréis, bueno, una cosa sencilla, pues costó 11 años, un ticket de 11 años, estuvo dando vueltas hasta que el 11 de agosto se publiqué. Ahí tenéis los enlaces de los tickets y de la conversación que tuvieron y llama mucho la atención que una cosa que ves tú 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 WordPress 5.5 lo tenéis. ¿Por qué hacerlo así? ¿Por qué ganar al malo? Bien, sobre todo tenemos un control de nuestras versiones de desarrollo. Vamos creando versiones, las vamos documentando y las 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 librerías de terceros. No sé si habéis tenido alguna librería de que se conecta a GitHub o algún repositorio, mira si hay una nueva versión, se descarga y lo actualiza. Esa librería, sorprendentemente, 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 las cabeceras 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 limpias las caché de objetos, lo que hace es que si tú estás cambiando por FTP en caliente el plugin, si tu servidor te ofrece una caché de objetos, posiblemente no verás el desarrollo actualizado. Y si entra en conflicto con otro plugin, puedes tener problemas. Con este proceso, no. Tú subes el zip, reemplazas y limpias caché. Los zip son mucho más limpios, porque no sé si habéis encontrado zip con carpetas con node de módulos, con la carpeta de Gihaz, con todo esto. Mucho más limpios y muy fáciles de compartir, de distribuir a nuestros clientes o directamente para subir. Y es un proceso que es rápido y es confiable. Es decir, que cuando ya la tienes estructurada y montada, ya puedes subir perfectamente. Bueno, muy bien David, me contaste estas cosas. Está muy bien. Pero, ¿cómo se hace? ¿Quién de aquí sabe qué es VPClip? ¿Hay algunos que no? Pues bueno, VPClip es la forma de trabajar con WordPress a través de la línea de comandos. Nos permite automatizar muchísimos procesos que, por ejemplo, actualizar los plugins de la propia instalación, incluso cambiar ajustes de la tabla de opción. Podemos automatizar totalmente la instalación de un WordPress a través de WPK. Os recomiendo que lo instaléis, lo podéis utilizar tanto en local como en producción. Y aparte tiene unos comandos, este comando que yo ofrezco que lo instaléis se llama thisArchive, que es el que permite poder hacer este archivo de distribución zip. Lo instalamos con WPackage Install WP.clix y una vez que se instala ya tenemos para poder utilizar el comando. Utilizamos el comando, tiene por varias partes, dice acá el comando, la parte del slug de nuestro plugin donde está y a donde queremos guardarlo. Esto yo lo suelo tener en un snippet, un testpander o cualquier cosa. Entonces le pongo el slug y siempre guardo toda la distribución de mis versiones en una carpeta. me crea un archivo plugin.isubversión, esta versión, ojo, que es la que nosotros ponemos 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. Pues 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 quieras subir a este sitio espejo, podrías 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 thisignor, que lo que hace es que ignora las carpetas que nosotros no queremos que estén en nuestro archivo de distribución, en el zip. El típico de sectores si tenemos un Macintosh, el típico.git si es un repositorio, el no de módulos que suele ocupar 60 MB o 70 MB. Entonces, todo este archivo, que estos son los que yo suelo poner en mis archivos, digamos que te los limpia por defecto. Y entonces te tienes que despreocupar. ¿Cuántas veces hemos hecho manualmente un zip y hemos tenido que limpiarlo antes, borrando cosas, luego copiando, y muchas veces incluso hasta borrando, volvían a aparecer archivos y en el zip que tú pasabas a producción te encontrabas archivos que no querías que estuvieran? Pues con This Ignore, 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 y no lo utilizamos para utilizarlo en el plugin. Eso también lo podemos ignorar para que no salga en nuestra versión. y luego hay que subir a producción todos sabemos ya que los viernes no se sube a producción se sube los lunes o los martes pues subiendo el lunes o martes, una vez que subimos ese archivo que hemos tenido, que hemos compilado que hemos hecho un zip que lo hemos probado en nuestro sitio espejo lo tenemos preparado, pues vamos a subirlo hay un proyecto dentro de WordPress del Core de que pueda hacer rollback, es decir, que podamos subir archivo y siquiera algún problema puede volver hacia atrás llegará pronto, pero mientras tanto tenemos el staging, es decir, probarlo en staging, que no se rompa nada, que todo funcione perfectamente y una vez comprobado subimos a producción. Una cosa a la que suelo 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 de release, yo utilizo GitHub. Bueno, nosotros utilizamos GitHub. Ahí te permite incluso subir un archivo. Entonces, aparte de que te crea el propio release, tú puedes subir el archivo de distribución que ya está listo para subir a cualquier otra página web. ¿Vale? Que ha tratado los Dignore y todo lo que habíamos visto. Y súper importante es documentar los cambios en el Realme. Cada vez que hacemos un cambio en nuestro desarrollo, línea al canto en el Realme, documentando, he cambiado, he arreglado, he mejorado, para que después de cara al cliente podamos justificar lo que hemos hecho. Hemos vencido al malo, por lo menos, se nos ha roto la página web. Yo soy David Pérez y animo a trabajar nuestro flujo de trabajo. Nosotros llevamos ya un tiempo trabajando con este flujo. Creamos nuestros zip, tenemos nuestra carpeta de proyectos, incluso para plugins comerciales. Y lo que hacemos es eso, es tener nuestros zip limpitos, listos para distribuir y para compartir. E incluso para vender. Nuestros plugins comerciales también lo hacemos con este proceso. Muchas gracias. y las diapositivas las tenéis aquí en davisperegar.com barra vcmadrid23.