 Bueno, vamos a reiniciar las charlas rápidas e, en esta ocasión, tengo o prazer de presentar a Juan Cadíaz. Juan Cadíaz é desarrollador e programador, como ele dice, de lo que se ve. Trabaja abaixo o nome de J. de Pelopia e proviene e sigue trabajando activamente con Yula. É uno de sol... É o organizador de la mitad de Tarragona e Barcelona. Os asseguro que é mucho, pero mucho, mucho menos malote de lo que aparenta. É un cacho de pan e os dejo con súa presentación, evitando a Nyaz, Nyapas, asaservis. Un fuerte aplauso para él. Bueno, muchas gracias a todos por venir. Aprovecho para agradecer un pouco a la organización e a todos vosotros por asistir, porque sin vosotros, sin gente como voluntarios e organización que ceden súo tiempo para hacer estos eventos, esto non seria posible. Así que, un aplauso para ellos. Vale, pues voy a comenzar. Me salto mi presentación. Sólo comentar que colaboraron en el podcast de este hombre que hay por aquí, Dario Balbontín, en el que hablamos sobre desarrollo web e WordPress. E tenemos un programa, bueno, de hecho, lo hizo él, con David Aguilera e Antonio Villegas, que también son muy buenos con tema de desarrollo e hicieron un podcast comentando buenas prácticas e é muy interesante de ver. Vale, eu sempre comienzo con un disclaimer para explicar un pouco que nos creáis nada de lo que digo, porque, al final, todo está basado en mi experiencia. Entonces, se os puedo ayudar e aportar algo de lo que eu voy a compartir, genial, pero que non es una charla para sentar cátedra, ni lo que voy a decir es para escribir un libro, vale? O sea, cuestionármelo todo e, luego, lo podemos debatir, se queréis, que seguramente podas estar equivocados en algún punto. Sois responsable de lo que digo, pero no de lo que vosotros interpretéis. Non me podes responsabilizar de que códigos e recomendaciones fallen en vuestra web e, en caso de duda, consultar con vuestros programadores. Seguimos. Niás, niás pasas a service. ¿Cuántos de vosotros habís sere dado algum plugin, algum tema, algún proyecto e habís pensado, esto lo han desarrollado éstos? Vale, o sea, hai máis danificados de los que eu me pensaba. Vale, pues, un pouco lo que vamos a ver aquí son 10 pequeños consejos, 10 pequeños tips, como se dice ahora que está tan de moda, en el que veremos como intentar evitar un pouco entregar proyectos ou desarrollos que os podemos considerar en unha napa. Que, a veces, no nos queda outra tener que recurrir a ésto, pero, bueno, tener un pouco en cuenta, ya no sólo para que terceros puedan heredarlo, sino que, quando pasan un tiempo e nosotros volvamos a éstos projectos, nos acordemos de éstos senores. E ésta seria un pouco a cara que se nos quedaria quando recibimos éxos projectos e decimos, pero que han hecho aquí. Vale, rápidamente, cultura de software libre. A final estamos trabajando con WordPress, es software libre, GNU GPL, e muchas veces ocurre que ao cliente non se le entregan as cosas en las que nosotros estamos trabajando. En mi caso que tengo un perfil máis programador, pues se le entregaría el repositorio con el control de versiones, con todas as cosas que se le ha desarrollado ao cliente. Él non lo va consultar, él non lo va mirar, pero é interesante que lo tenga. Por si nosotros volvemos a ese proyecto, o por si entra un tercero que se le encuentra máis o menos apañado. Se hacemos diseños, se hacemos SEO, todo os entregables e todos os editables para que só o tenga ao cliente e no tenga que recurrir otra vez a nosotros, vale? Ao final, é se extender un pouco a filosofía e ao software libre a todo o que hagamos, que no tiene porque ser só codivo. Function ben sus plugins. É isto também é muy comum de mezclar funcionalidad con plantilla, con temas, con diseños, etcétera. Ao final, el fichero de functions está para todo aquello que sean funciones relativas ao tema. Puede ser que haya funciones que tengan que ver con temas de lógica, que haya programación como tal, pero é o sinerente ao tema. É decir, o dia que eu cambio de tema, uno tiene que pensar se é o tema que se va a utilizar realmente. É simplemente o que se ve. E toda a parte de os plugins é o que pertenece ao website. E o temos que tener claro, porque senón, nos problemas. Se metemos mucha funcionalidad nos functions, é un Cristo poder diferenciar o tema e o que parte relativa ao plugin. E todos os plugins, ou se nos mesmos, de dar a posibilidade o meter código em base de dados é fazer a pasta sin agua, como decía Benito. Seguimos. O codex de WordPress. Temos que consultar o codex de WordPress sempre que vayamos a desarrollar algo, porque temos a gran suerte de que, aunque sí que é verdade que o codex tiene una imagem un pouco antigua e é un pouco viajuno, para entendernos, nós mesmos están trabajando en una parte frontal, que realmente le dá outra vista ao codex que hai, que se llama developers.wordpress.org que está muy bien. Pero ao final, o codex é o que tem toda a información. Sempre que vayamos a desarrollar algo, sempre que necessitemos una función en concreto, é o má recomendable sacudir ao codex, porque realmente é o que vamos encontrar toda a información. E igual, a funcionalidade que nós teníamos pensado a desarrollar, já hay una parte que sea nativa de WordPress. Por lo tanto, é un pouco redundante introducir nuestra funcionalidade quando ya de forma nativa la tenemos. Por lo tanto, que sempre antes de hacer algo, consultemos ao codex. En cada diapositiva, hai unha serie de links que os podeis consultar e seguramente os sean de utilidad. WordPress Plugin Borlairplate. É unha web en la que nós introducimos o nome del plugin, el text domain, nos va pidiendo os outros o 4 campos e o que nos genera es toda una estructura de ficheros. Unha estructura de ficheros en la que tenemos unha serie de buenas prácticas e unha serie de estructura muy recomendada e que se utiliza e que además cumple con os WordPress Coding Standards e é muy interesante de poder utilizar. Tanto se já sabemos e já tenemos mucha experiencia haciendo plugins como se queremos empezar de cero. É a melhor maneira porque vamos ver como se trabaja relativamente bien con unha serie das coisas que hagamos e é muy interesante utilizarlo. Só con que nos lo miremos e se nos peguen un pouco as buenas prácticas que genera este recurso e já está bastante bien. Seguimos. Versiones de WordPress de desarrollo. É unha cosa que eu creo que mucha gente no hace o non conoce e é que hai dos plugins tanto para WordPress que se llama WordPress BetaTester como para WooComers que se llama WooComers BetaTester que nós os instalamos WordPress e o que nos haces que unha vez lo activamos se baja a última versión estable en la que se está trabajando en GitHub o donde sea e entonces vamos a tener las novas funcionalidades que van a traer as próximas versiones de WordPress por lo tanto que se nós estamos desarrollando un tema de un plugin já se va estar utilizando esas novas funcionalidades e o dia que se actualiza WordPress não vamos a tener que revisar nuestro plugin o nosso tema para que se adapte correctamente con ele Sino que activando esto ya nos vamos a segurar que nos hagan novas versiones todo funcione correctamente seguimos utilizar un framework que sea nuestro seguramente que todo nos pasará que trabajamos con clientes e hay muchas cosas que repetimos os textos legales de la RGPD cuándo utilizamos funciones para poder desactivar o activar cosas en el propio WordPress por que no apelotonarlo todo en un propio plugin nuestro e que sea nuestro framework e que lo vayamos utilizando en as diferentes webs que llevamos e o que vamos haciendo es que en cada cliente e en cada diferente proyecto vamos a encontrar cosas comunes e ese plugin cada vez va a ser mejor es decir va a crecer con nosotros e vamos a tener un plugin que va a contener muchas de las casuísticas que nos encontremos en diferentes clientes e nos aseguramos con menos esfuerzo entregar un trabajo mucho mejor hay una charla precisamente de Dario que habla sobre este tema que también es moi moi interesante documentación esto se hace poco e se tendría que documentar absolutamente todo lo ideal seria documentar tanto os encabezados e os cierres de las funciones, de os hooks, de lo que hagamos porque o día de mañana quando ese código está ahí, lo revisemos no vamos a saber muchas veces que hay se dejamos un pequeño comentario nos va a ayudar muchísimo para poder retocarlo e sobre todo e se nos le hemos horredado nosotros hay una frase muy típica que se dice que hay que programar sempre pensando que en el futuro va a haber un un psicópata que va a ver ese código e sabe non se donde nosotros vivimos entonces hay que dejarle las cosas muy bien hechas para que no tenga ganas de venir a matarnos cadenas de traducciones en este enlace se explica como poder utilizar cadenas de traducción e si tanto en plugins como en tema podemos utilizar esas cadenas de traducción para hacer que nuestros plugins e nosotros temas se podan utilizar en diferentes idiomas con eso abrimos la posibilidad de que terceros puedan contribuir aportando sub traducción e etc estructuras de datos e de layout al final ocurre mucho que nosotros creamos custom post types e tenemos un diferente necesidad a la hora de crear contenidos e al fin e al cabo se nos vamos un pouco a la programación má de toda a vida un custom post type no deja de ser un entidad de datos por lo tanto un entidad de datos e su propia estructura de datos e tiene que tener sus propios layouts porque al final, se estamos diferenciando ese tipo de contenido del resto lo ideal e o má lógico es que tenga su sentido como entidad tenga su sentido como estructura de datos e tenga su sentido como visual como layout e es la manera ya que estamos creando una nova entidad de datos e un nuevo tipo de datos de poder crecer en el futuro con eso que por eso lo estamos diferenciando de lo que son las entradas o las páginas para cobrar las dependencias muchas veces utilizamos librerías de terceros recursos de terceros e non se declaran en ningún sitio e al final hay que hacer un pouco inspeccionar a ver qué librería e qué cosas ha utilizado aquí entonces se nosotros intentamos documentar o comentar esas librerías o incluso esos plugins de terceros que nosotros estamos utilizando e que tenemos una dependencia directa con o que estamos haciendo está bien dejarlo anotado aquí dejo un recurso que es el TGM plugin activation que lo que nos haces que nos genera un código e declaramos las dependencias de outros plugins e quando nosotros activamos o nosso plugin o nosso CIM nos va a decir que instalemos estos plugins porque este plugin que está es un pouco redundante pero este plugin que estás intentando utilizar estás intentando activar tiene una dependencia directa con éstos e para acabar sempre cierro yo con una frase molona en este caso es de ellos e es que pongamos un poco de mimo en nuestro código para que quando outro se lo vea no diga la frase e después queremos ganar todo lo mismo muchas gracias tenéis la presentación ya colgada e así que se la querísse descargar tamén voy a estar unha hora en el happiness bar así que me queréis preguntar cualquier cosa sin problemas muchas gracias