 Bueno, ¿se me escucha bien? ¿se me escucha? ¿sí? Bueno, buenas tardes a todos, qué tal? En primer lugar, muchísimas gracias por aguantar hasta esta tarde, ya sé que ha sido un día bastante intenso, grandes ponencias, grandes ponentes, muy buenos momentos, muy buena comida y según me han dicho, después de mi ponencia hay otros 10 kilos de chicharrones más para poder ir tranquilamente contentos para casa. Bueno, en primer lugar me presento, mi nombre es Carlos Rodríguez Brito, soy desarrollador de Plamins y soporte para GIT, gracias a Working Chiclana me he dado cuenta que soy además de uno de los primeros desarrolladores que está con GIT en España, soy de los que estuvo en el transcurso de un año y medio para formarse y estar hoy aquí y gracias a ello poder dar esta ponencia de buenas prácticas y también gracias a esta ponencia me he dado cuenta, que no me ha pasado nunca, que cuando Sara me conteste con monitos y cerditos es que hay un problema. Por ahora no me ha pasado, entonces Sara, ya lo tendré en cuenta para la próxima vez. Bueno, comienzo evidentemente hablando de WordPress, ¿no? Como bien saben, WordPress es un sistema gestor de contenido muy popular, ahora mismo decía la primera ponencia, ¿quién estaba aquí desde esta mañana? A ver, bueno, bastante, bastante. Decía que era el 35% de las páginas web en el mundo, están hechas con WordPress. Muy bien, la ventaja es que WordPress es muy fácil de usar, muy cómodo, tiene una curva de aprendizaje bastante corta y en cualquier en poco tiempo tenemos tu web montada y estás, por decirlo así, con presencia en internet. ¿Qué pasa? Que muchas veces WordPress ya de base no te incluye todas las funcionalidades que tú querrías. Por ejemplo, WordPress de base no tiene, no tiene una tienda online, no puedes hacer una tienda online solo con WordPress, no podrías hacer una red social solamente con WordPress, una web de reservas, una membresía, etcétera. Hay muchos proyectos que de base con WordPress no se podría hacer. Para hacerlo, necesitaríamos extender WordPress, ¿vale? Extender la funcionalidad de WordPress de base. ¿Cómo podríamos extenderlo? ¿De qué manera podemos extender nuestro sitio con WordPress? Hay varias maneras, en este caso, por ejemplo, podría ser con plugins, ¿no? Directamente cogemos un plugin del propio repositorio y con ese plugin podemos extender la funcionalidad base de WordPress, en este caso. Otra opción también podría ser con códigos personalizados. Tú necesitas una funcionalidad específica, puedes coger, programarte tu propio código personalizado y obtener un resultado. De esa manera estamos dándole funcionalidad, estamos transformando, por decirlo así, WordPress para lograr nuestro objetivo. ¿Vale? Ejemplos de plugins, por decirlo así, que se podría utilizar para extender proyectos con WordPress. Comunes, formulares de contacto, como puede ser contact for 7, son plugins que encontramos en el repositorio de WordPress, ¿vale? Son plugins gratuitos. Uno, por ejemplo, para tiendas online, que podría ser WooCommerce o también filtros de spam, por decirlo así, podría ser KeySmet. ¿Vale? Posibilidades de extender los proyectos con WordPress. Podríamos hacer de tres maderas. Podríamos modificar directamente el código del core, modificar directamente los temas o modificar directamente los plugins. Y aquí me paro un momento para preguntarle, ¿creen ustedes que esto es una buena práctica? No, no. Efectivamente, esto no es una buena práctica. ¿Vale? Y la palabra clave es el directamente. ¿Por qué? ¿Qué pasa si directamente modificamos el código del core de WordPress, modificamos los temas o modificamos los plugins? ¿Vale? El ecosistema WordPress a la hora de actualizarse funciona de la siguiente manera. WordPress actualiza tanto el core como los temas como los plugins borrando todo el contenido y reemplazándolo por la nueva versión. Es por decirlo así, que yo quito lo que tengo ahora, lo borro todo completo y meto lo nuevo. ¿Vale? Esto por tanto sería una mala práctica. También podría haber otra opción, que es la opción de no actualizar. Podríamos vivir sin actualizar, pero evidentemente es algo que yo no recomiendo, y que creo yo que nadie debería de recomendar. Siempre sería recomendable actualizar. ¿Vale? ¿Qué pasaría? ¿Qué consecuencia tenemos cuando actualizamos? Perdemos todos los cambios. Por ejemplo, imagínense que ustedes tienen un membership site, quieren por decirlo así gestionar contenido privado solamente a determinados roles y deciden aplicar esa funcionalidad directamente en el core de WordPress. ¿Qué pasaría si actualizáramos el core de WordPress? ¿Perderemos esa funcionalidad? Y automáticamente todo el mundo que visitaría la página web podría ver todo nuestro contenido. Entonces sería para nuestro modelo de negocio algo bastante peligroso o hacerlo muy mal. ¿Vale? Después de haberle metido un poco de miedo con esto o dejarles un poco en claro, un poco en tranquilidad, les vengo a hablar de realmente lo que viene a la propuesta de estallarla, que son buenas prácticas para extender proyectos con WordPress. Evidentemente, la primera buena práctica a la hora, por ejemplo, de modificar el core sería estructurarlo de dos maneras. Si queremos diferenciarlo en funcionalidades de WordPress, deberíamos utilizar plugins. ¿Vale? Debemos estructurarlo en si queremos modificar el core de WordPress, utilizar plugins para modificar la funcionalidad de WordPress. Si quisiéramos modificar aspectos de diseño de WordPress, lo mejor es utilizar temas. ¿De acuerdo? Aparte de la modificación de temas que podríamos hacer, la recomendación para de buena práctica sería la de utilizar un tema hijo. ¿Conocen lo que es un tema hijo? ¿Quién conoce lo que es un tema hijo? ¿Vale? Veo mano sin levantar. Evidentemente, lo que no lo conozcan, se pueden leer esta parte, se tratan de temas que heredan las funcionalidades del tema padre y que además podemos extenderlas o modificarlas. Y es muy fácil obtener un tema hijo. Simplemente, aquí les muestro lo que sería una estructura básica de un tema hijo. Esencial es tener, que no se ve muy bien aquí, es un fichero llamado style.css. ¿Vale? Solo con esto y con una cabecera referenciando al tema padre tendríamos ya lo que sería un tema hijo. Ya podríamos directamente extender todas las funcionalidades de aquí, del tema hijo, para poder, sin tener la consecuencia de perderlo, si actualizamos el tema padre. Porque como les he dicho antes, si actualizamos el tema padre perderíamos todos los cambios. En este caso, teniendo un tema hijo, nos libramos de ese problema, ya que un tema hijo nos actualiza. ¿Vale? Ya que es creado por nosotros. Otra parte, a la hora de... Bueno, aquí les muestro como sería después de tener el fichero style.css, lo que sería el tema hijo. ¿Vale? Teníamos aquí lo que es el tema padre y aquí sería lo que es el tema hijo. ¿Qué pasaría a la hora de modificar los plugins de WordPress? Este concepto de plugin hijo no existe. Para poder extender, por decirlo así, los plugins de WordPress, deberíamos utilizarlos que se conoce como plugin de funcionalidades. ¿Vale? Podríamos hacerlo de varias maneras, utilizando hooks, que sería hooks que tienen el propio código de WordPress, del propio plugin de WordPress, o el propio plugin que esté diseñado para modificar su comportamiento. Podríamos modificarlo con nuestro plugin de funcionalidades para que en la salida de una acción que es en RSE plugin, podríamos nosotros modificarla y hacer lo que nosotros queramos para conseguir nuestro objetivo. Otra manera sería creando código propio que permite extender ese plugin. Evidentemente también sería con hooks. Un ejemplo podría ser modificar o añadir una funcionalidad a un nuevo tipo de producto en Google Comer, por ejemplo. De los productos que tenemos podríamos nosotros crear un plugin que añadiera un tipo de producto nuevo. ¿Te acuerdo? Aparte de eso, también podríamos utilizar dos tipos de plugins según las necesidades que nosotros queramos. Yo lo he querido dividir en dos, que sería lo que nosotros conocemos como plugins generales, que son los plugins que son funcionalidades dependientes de otros plugins o del propio tema. Y otro lo que se conoce como MU plugins, MU plugins más US plugins que serían funcionalidades críticas de la web. Son funcionalidades que sí o sí, mi web necesitaría para poder funcionar. Mi proyecto, mi proyecto de negocio necesitaría para poder funcionar. Eso yo las metería en lo que sería un MU plugins. Aquí les muestro lo que serían las diferencias entre un plugin genérico y un MU plugin. ¿De acuerdo? Un plugin genérico se encuentran por defecto en la ruta WP content barra plugins. Pueden activarse y desactivarse directamente por los administradores de WordPress. Se han activado o desactivado un plugin, justamente en la parte de activación y desactivación. Clicamos ahí y activaríamos el plugin. Y otra opción de los plugins genéricos es que se pueden actualizar a una nueva versión. La diferencia con los más US plugins o los MU plugins es que se encuentran por defecto en esta ruta WP content MU plugins. Normalmente esta ruta no suele existir a las instalaciones por defecto de WordPress, pero la podríamos crear nosotros. WP content crearemos una carpeta de MU plugins y al propio WordPress detecta que todo lo que vaya ahí dentro lo consideraría un MU plugin. Son activados automáticamente, que es la ventaja que tendría con respecto a los plugins genéricos, son plugins que directamente se activaría una vez entre a funcionar lo que es WordPress y no se pueden desactivar manualmente. La única manera de desactivar un MU plugin es borrándolo directamente desde la carpeta WP content para MU plugins. Y por supuesto no es posible actualizarlos a una nueva versión. Yo normalmente en el soporte o en mis proyectos personales he podido utilizar un MU plugin por ejemplo para no permitir a un desarrollador, a una persona, a un amistrador por decirlo así que desactive WuCommerce. Yo he creado un pequeño plugin con un pequeño fragmento que lo que hace es impedir que cualquier persona pueda desactivar WuCommerce. ¿Qué me permite con eso? Que yo no corre el riesgo de que un cliente mío sin querer desactive WuCommerce y pierda la funcionalidad principal que lo que sería la venta de productos en su sitio. Con eso lo podría hacer con ello. Y bueno para terminar recapitulando un poco de las buenas prácticas que podríamos utilizar pues por supuesto en el core de WuCommerce utilizar plugins para extender funcionalidades de WuCommerce y utilizar temas para modificar el aspecto de WuCommerce. Dentro de los temas de WuCommerce modificar los temas de WuCommerce utilizando temasisgo y dentro de los plugins de WuCommerce por supuesto extender los plugins utilizando un nuevo plugin de funcionalidades.