 Darío Balbontín, no Botín, que antes se me ha ido al punto Santanderiño, que tengo familia ahí, familia de Santander. Bueno, pues nada, vamos a ver algo muy interesante, Darío es muy experto en temas de Wordpress, sobre todo como llevar mucho a las páginas web, que reclaman, eh, lleva más de 50 páginas web de alto nivel, no de un blog de cuatro visitas, sino algunas páginas muy importantes. Entonces, vamos a ver qué es un framework. Un framework es algo que, como antes preguntábamos, alguien que realiza varias instalaciones. Hay un momento en la vida de cualquier instalador de Wordpress o instalador o programador que dice, o incluso implementador que dice, yo estoy, me siento como que estoy haciendo lo mismo muchas veces, no habría alguna forma de automatizarlo o hacerlo mejor. Ahora hablamos, por ejemplo, de los Blueprints, pero hay un nivel un poco más allá que te va a permitir tener tu propio framework, es decir, bueno, ahora no os lo contará, Darío, pero que te va a ahorrar mucho trabajo para no volver a empezar desde cero en el momento de hacer cada nueva instalación para cada nuevo cliente. Señores, aplauso para Darío Balbontín. Bueno, pues se me oye bien, ¿no? Gracias por escogerme. Seguro que Fernando está haciendo una ponencia que hay que quitarse el sombrero, pero bueno, habéis elegido estar aquí, vais a sufrir, es lo que habéis decidido voluntariamente. Yo vengo a explicarlo del tema framework. Y alguno que me haya visto por ahí, a lo mejor piensa que es la típica ponencia donde explico que es un tema tal y cual. No, voy a explicaros cómo agilizar vuestro flujo de trabajo o cómo yo con mis clientes lo optimizo y qué herramientas utilizo para ello. No os va a servir todo, alguno no le servirá nada, pero vais a aprender algunas cosillas que implementaréis casi seguro. Espero que tengan herramientas útiles. Perdón por el tamaño de fuente. La diapositiva ya está colocada, la podéis ir viendo en tiempo real, slides.dariovejo.com, barra WC en Mayúscula, Barcelona con la B Mayúscula 2018. Al final está en el enlace también, así que nos preocupéis. Y cualquier cosa, me mandáis un tweet, un correo, lo que necesitéis y hablamos. Ya me ha presentado Joan, así que para que voy a hacer un mucho hincapié, básicamente soy diseñador de desarrollador en actualidad blog, donde gestionamos webs de alto rendimiento, de alto tráfico. Actualmente tenemos casi 50 blogs temáticos, para que os hagáis una idea, pues están en torno a los 10.000 artículos cada blog, aproximadamente. Entonces claro, si la web carga lenta, tienes un problema de consumo de servidor espectacular. Si se te congela un script, estás perdiendo tráfico, que son los que te dan dinero, etcétera, etcétera. Además de eso, algún podcast por ocio, porque me apetece con juanca, donde hablamos de cosas de WordPress, de diseño, de desarrollo, de experiencia de usuario, etcétera, etcétera. Os invito a que lo escuchéis, por lo menos uno de los episodios. Y también estoy empezando a hacer un pequeño club privado, con accesos restringido, donde va a haber debates, va a haber tutoriales, va a haber cosas de los que forman parte de él. Esto todavía está en desarrollo, pero bueno, me apetecía ponerlo. Ya el apps en su día fue un streaming de diseño de desarrollo web, donde yo hacía cosas en directo, sin cortes, sin problemas. Si fallaba algo, se buscaba la solución en directo, y eran dos horas de puro trabajo, donde la gente veía cómo se trabaja en estas cosas. Bueno, lo primero es definir un framework. Ya todos sabréis más o menos lo que es un framework, pero si tiramos de Wikipedia, viene a ser eso. Un framework es un conjunto de herramientas, de conceptos, plásticas, etcétera, que nos sirven como referencia para afrontar un problema concreto. Hay frameworks de desarrollo, frameworks de diseño, hay frameworks de muchos tipos. Y con WordPress no es menos. Podemos hacer que WordPress sea nuestro framework de trabajo, incluso dentro de WordPress, tener un plugin que sea nuestro framework de desarrollo, o un tema que sea nuestro framework. La red de blogs es el ejemplo que me toca. Nuestro tema es un framework, porque lo usamos en todas las web y tiene las funcionalidades que necesitan todos los sites que gestionamos, porque son todos muy parecidos. Entonces, nos vamos a quedar con tres claves. Es un entorno de trabajo, es un conjunto de prácticas, me voy a dar mucho la vuelta porque no veo el portátil, y tampoco me he aprendido de memoria para que. Repito, es un entorno de trabajo, un conjunto de prácticas que resuelven un problema o problemas de índoles similar. Quedaros con esas tres cosas. Algunas consideraciones previas que hay que tener en cuenta cuando hablamos de esto, porque esto tiene una magnitud bastante importante. Debes satisfacer tus necesidades como desarrollador o como diseñador. Las tuyas, no las des de a la o. Otra cosa es que queráis compartirlo en GitHub con más gente, entonces tiene que ser un poco más genérico, pero es otra historia. Esto es para vosotros. Hay que evitar incluir funcionalidades, porque entiendo que en mi caso de la red de blogs todos los blogs son iguales y puedo incluir todas las funciones que quiera, porque afectan a todos los sites, pero si trabajáis con pimes o con gente, con proyectos más normales, si incluís unas funcionalidades, por ejemplo un sistema de reservas o un sistema de venta, no va a cumplir con todos los proyectos. Entonces esas funcionalidades apartarlas de este tema, de este framework. Y hay que intentar hacer el mayor número de buenas prácticas. Eso ya es un enlace a una ponencia que di en Santander en 2015, creo que fue no nadie a las de buenas prácticas, por ahí no me acuerdo. Donde hablo de buenas prácticas en el desarrollo web y tal, qué cosas hay que hacer, para evitar problemas y eso. El resumen sería encolado de scripts y estilos, no jarcodear cosas a piñón y poquito más, ¿vale? El primer paso, extraerlo como uno. Seguro que todos tenéis más de un cliente, ¿verdad? Bueno, no hace falta. Y seguro que todas las webs tienen un teléfono, un email, de contacto, una dirección, a lo mejor, ¿verdad? Ya empecéis a ver cosas comunes, a que sí. Bien, si lo introducís en todos los proyectos, ¿por qué no creáis una herramienta que os permita introducirlo más rápido? Por ejemplo, vamos a extraer lo común no solo a nivel de datos del usuario y demás, sino de diseño, de funcionalidades, ya he dicho que no hay que incluir funcionalidades, pero hay muchas cosas que repetimos y son funcionalidades. Y con los sociales de compartir, formular y contacto, etcétera, etcétera, etcétera. Y sobre todo la información, que es lo que más vamos a repetir una vez, RGPD. Ese texto es el demonio, o sea, y quién no lo ha copiado y pego más de diez veces. Bueno, porque no tienes más de diez clientes, pero ¿por qué no automatizamos ese texto? Por ejemplo, pues esas son las cosas que os voy a enseñar hoy, que en el momento que os instaleis vuestro WordPress con vuestro tema framework, automáticamente os genere toda esta información y os quita esto de ese trabajo de encima. A nivel de diseño, podemos automatizar, aunque penséis que no, muchas páginas de web son misma estructura, mismos layouts, misma coherencia, todas tienen el mismo look and feel, gader arriba, algo por el medio y un footer, o prácticamente todas. Cambian pequeños valores, pero en base a eso podemos definir cuatro layouts, por si no se lee, blog, web corporativas, portfolios, tiendas online, hay más ejemplos. Pero vosotros conocéis a vuestro cliente, si vosotros estáis actualmente haciendo webs de restaurantes, sabéis que todas las web van a ser 90% iguales. Entonces podemos definir estos tipos de layouts y con unos selectores que voy a explicar después cómo, desde el inicio decir, esta web, el archive de las categorías va a ser tipo gris y no tenéis que diseñar ese layout porque ya está hecho, simplemente marcando que es gris, el sistema automáticamente ya muestra un gris. A nivel de diseño o de interfaz, ¿cómo vamos a mostrar los artículos? Por ejemplo en el blog, rollo lista, así típico blog, con el extracto, con contenido, uno encima de otro, o tipo gris, tipo rejilla o como lo diga es en español. Eso también se puede automatizar y lo podemos segregar tanto como queramos, es decir, podemos definir que la home sea tipo gris, que los archive de categorías sean tipo lista y que los archives de tags sea tipo gris también, o incluso un tercer tipo que puede ser lista mínima, donde solo salgan los enlaces. Más elementos que podemos automatizar, número de elementos por página, eso lo hace con WordPress en la configuración, con lo cual el tamaño del extracto, ¿sabéis que se puede modificar el tamaño del extracto, verdad? Podéis meter un campo en esa página que os voy a enseñar ahora de cómo configurar vuestro tema, podéis meter un campo que sea el tamaño del extracto. Por diseño a lo mejor no nos interesa que tenga más de 100 caraceres o de 150 o queremos que tenga 500 y entonces seguimos usando la misma función pero está configurada internamente y es transparente para nosotros, no tenemos que volver a reprogramar esa función cada vez que lanzamos un proyecto nuevo. Lo mismo pasa con mostrar o ocultar, hay sitios donde no nos interesa mostrar las fechas porque los artículos son una vez cada tres meses y si entra alguien ve que ahí está como abandonado, entonces con quitar las fechas, un botón o un selector ocultame las fechas, ya está, es un if, ¿vale? ¿Veis viendo un poco por donde voy? Lo vais a entender en cuanto enseño una de las capturas que traigo, pero quiero que vayáis viendo ejemplos de qué se puede automatizar. Comentarios lo mismo, no todos los blogs o sitios tienen cabida para los comentarios, si es una web corporativa no mejor no nos interesa que venga el típico hater a decir que nuestro restaurante es una mierda y ni siquiera ha estado en él, ¿no? pero simplemente es la competencia que viene a tocar la narices por ejemplo o cosas por el estilo. A nivel de funcionalidad es lo que decía, iconos sociales, formularios de contacto, post types de información, el equipo, servicios, etcétera. ¿Cuántos hacéis la página de servicios? Que sea una página estática y le metéis ahí los servicios y venga, ahí, ahora, no levantéis la mano que os da vergüenza, ya sé cómo va el tema. Hay muchos que lo hacéis, aunque digáis que no, yo lo he hecho también, no pasa nada y entonces viene el cliente y te dice, hay que añadir un servicio y dice, meca, bueno, como jover, cáncela la cita de las tres porque tengo aquí para rato. Si hacemos un post type de servicios, cada artículo es un servicio con su imagen, con lo que necesitemos y entonces en el archive de ese post type se regenera automáticamente y no tenemos que andar preocupándonos de que hay que añadir uno aquí y encima el otro y el enlace y no sé qué. Este tipo de cosillas lo podemos tener ya predefinido porque el 80% de las webs está muy de modo a poner el equipo, por ejemplo, quienes forman parte del equipo o los servicios que ofrece. Entonces esos son post types que podemos tener ya predefinidos y entonces lo único que tenemos que hacer en nuestro pequeño página de configuración del tema framework es decir, ¿esto lo voy a utilizar o esto no? Información, lo que a todos nos gusta, datos fiscales del cliente porque a lo mejor hay que mostrarlo en los textos legales o lo que sea, la información de la GDPR, el zurullo este que nos manda, que es obligatorio y que hay que hacer pues estas horas una vez o con pastas con un asesor te manda los textos y sabes que ese texto es universal para toda la gente y luego el cliente tendrá que ir a registrar sus fiches o lo que tenga que hacer pero el texto es el mismo, solo cambia la información. Entonces, ¿por qué no preparar ese texto donde la información del nombre es un sort code que nos lo va a recoger del backend y entonces tenemos un campo para modificar ese nombre o el cif o la dirección o el teléfono? De forma mucho más fácil, mucho más rápida. Sobre todo para nosotros porque el cliente eso no lo va a modificar casi nunca pero nosotros no tenemos que andar, copia el contenido, crea una página, añade luego tal y cual. Eso puede hacer el tema en el momento que lo instalamos. Usuarios de redes sociales, ¿cuántos tenéis en vuestra web? Lo desígueme en Twitter, Facebook y tal, y metéis en los usuarios. ¿Por qué no tener esto ya automatizado? Y ahora ya vamos un poco, porque tampoco he dicho nada del otro mundo, ¿no? Todos lo hacemos, quiero decir, tareas repetitivas, hemos hecho todos y todos terminamos cansados de hacerlas. Vamos a construir este framework, ¿vale? El pilar de este framework va a ser una página de configuración y no estoy hablando del customizer. No sirve, podemos hacerlo en el customizer, pero a nadie le gusta trabajar en una pestañita así con un preview que no nos aporta nada de 300 píxeles o 500, ¿vale? Vamos a hacer una página en condiciones que sea visualmente agradable y donde recojamos toda la información que necesitemos y configuremos todo lo que queremos configurar de nuestro site. Estoy hablando de crear un tema framework que cada proyecto nuevo que nos entre, vamos a instalar un WordPress, vamos a meter este tema de framework, vamos a crear un child para ciertas modificaciones de estética que tengamos que hacer, pero el framework se va a gestionar todo o la gran mayoría de lo que hacemos, ¿vale? Ya os digo, cuando yo os enseñe el pantallazo, queda todo claro. Es importante preparar los defaults, lo que decía del rollo layout grid, layout tal, todo eso tiene que estar ya definido en el framework. Y vamos a automatizar todo lo posible, que eso es el último paso que os voy a explicar, lo entendréis todo. Pagina de configuración, permite preconfigurar toda la información que vamos a abarajar en nuestro site. Lo que decía, ¿vale? Todo lo que hemos hablado. Puede ser un desarrollo complejo, lleva muchas horas, por supuesto, pero no tanto con ACF. Conocéis Advanced Custom Fields, ACF, ¿vale? Permite crear este tipo de páginas de configuración. Después el backend, lo que es el script que gestione esas opciones, lo podemos hacerlo, lo tenemos que hacer nosotros, pero lo que es la interfaz de esa página de configuración nos lo facilita mucho ACF. Y como es para nosotros, tendremos licencia de desarrollador, espero, ¿vale? No me sé, es tan cutres de cogerla de personal y usarlo 100.000 veces, que el Advanced Custom tiene que comer. Entonces, como tenemos la licencia de desarrollador, la podemos usar las veces que queramos en cada site, podemos utilizarla. Y esto no está pensado para un proyecto, porque no estaría pagado, o sea, tú al cliente le haces esto solo para él y el cliente no le compensa a él o no te compensa a ti, ¿vale? No hay punto medio. Entonces es para futuro, es decir, trabajo con muchos clientes de diferentes tipologías, pero que tienen bastantes cosas en común, entonces voy a automatizar todo lo que es genérico. Y aquí está la página de una de ellas que os voy a enseñar de la red de blogs. No sé si se lee bien, me imagino que no. Pero básicamente recordad que en la red de blogs todos los diseños, el diseño es siempre el mismo, lo único que cambian son los colores, en algún blog concreto la tipografía. Por ejemplo, tenemos una opción, que es los artículos destacados en la home, un seled, si lo marco, aparecen, si no, no aparecen. Un blog que está medio abandonado, pues tampoco te interesa que tenga artículos destacados, porque va a ser siempre el mismo. Información propia, un código de comscore. Por ejemplo, el fit de la RSS, configuraciones que usamos en algún tipo de script, que si no tendríamos que estar metiendo en el código una y otra, y otra vez. De esta manera, si entra un blog nuevo o lo que sea, compramos un site, añadimos un blog nuevo o lo que sea, con instalar el tema y configurar esta página, ya está todo configurado. A la derecha veis dos selectores, no se ve el, porque sale el negro, lo es algo que tengo que corregir, pero salen los dos colores, el principal y el secundario del blog. Generalmente son uno más oscuro que el otro, para que tenga un poco de concordacia al diseño, pero a veces son contrarios, por ejemplo en el de Android, era verde y azul, por los temas del color de Android. Entonces es un poco, esta sería la página, ¿vale? Esto es de la red de blogs, un minuto solo. ¿Qué te has equivocado? Vuelvo al sitio. Entonces entiendo que esto a vosotros, pues tampoco se aporta nada, porque no todas las webs son iguales, no hacéis todas las webs iguales. Si enseño un ejemplo que me ha compartido Juanca, el que tenéis por ahí, el de los status que le llamo yo, es más real, es más para clientes más habituales que el caso de la red de blogs, y os va a gustar más porque visualmente es otra historia. No se lee, pero arriba tiene una serie de pestañas donde se configuran datos personalizados, la RGP de redes sociales, footer, funciones propias de WordPress, funciones de plugin, funciones de GoogleCommerce, y una página de documentación, esto ya tiene otro color, ¿verdad? En cada pestaña tenemos una configuración. Aquí por ejemplo, datos personalizados, información fiscal, el horario comercial, dirección, teléfono, URL del dominio comercial, si lo hubiera, el dominio como tal, enlace al fórmula de contacto porque se preconfigura por ahí. Vais viendo cómo va el tema un poco. Si os enseño otra página de esto, la página de RGPD, tenemos el nombre del titular, el identificador fiscal, el e-mail, el domicilio, la renuncia de responsabilidad, lógicamente porque Juanca no quiere que le mande a la cárcel porque el cliente lo haga mal, pero el cliente tiene toda esta información disponible. Lo puedo modificar cuando quiera, incluso Juanca lo modifica súper rápido gracias a esta página de configuración. La página que más me ha gustado de lo que me mandó Juanca, porque el mío era como esto un poco más cutre, más feo, tenía muchos años ya, es esta página de documentación. En esta página, Juanca lo que mete es toda la información de desarrollo que tiene el proyecto, post types, custom fields, cómo funciona, las funcionalidades que ha añadido, modificaciones que ha hecho todo, absolutamente todo. En este proyecto que le demos, solo hay dos cosas. Post type creo que es tipología de producto, que es un cost type y las preguntas frecuentes, que es un cost type. De esta forma, si mañana el cliente decide prescindir de mí por lo que sea, el desarrollador que entre tiene toda la información de lo que tiene hecho ese proyecto con toda la documentación. En este fichero se gestionan estos post types, en este otro se hace esto, en este otro se hace esto. La documentación es muy importante, sobre todo para heredar proyectos. Para entregarlos, pero cuando heredas y no hay documentación es un dolor. Y una página más que os quería enseñar es la de funciones de WordPress. Lo único que veis es un montón de selectores, sí o no. Y esto hace activa o desactiva funciones nativas de WordPress, como por ejemplo la reducción de calidad de imágenes, etcétera, etcétera, etcétera. Os leo algunas para que entendáis, me tengo que acercar porque no se ve mucho. Bloquear la función autocompletar para el core, temas y plugins. Autobotator, perdón. Evitar pérdida de cambio de calidad de imágenes. Párrafos automáticos por defecto desactivados en el extracto. Párrafos automáticos por defecto desactivados en el contenido. Lo veis, son funciones de WordPress que no en todos los proyectos se utilizan. Entonces ahí, rápidamente, incluso mete las funciones suyas propias. De manera que pasa mañana se rompe el site en una actualización por lo que sea y con venir aquí desactivar todo, vamos descartando cosas. Es como los plugins. Cuando se rompe el site, lo primero que hacemos es desactivar plugins a ver cuál es el problemático. Pues esto es un poco igual. ¿Os ha gustado eso? ¿Cuántos lo veis útil? ¿Cuántos lo vais a implementar? Ahí bajan manos a tope. Como decía, el siguiente paso, ya tenemos la página de configuración donde decidimos todo esto. Juanca no tiene ninguna que define layout, pero podemos crear una pestañita más que sea layout. Y entonces seleccionamos que en la home muestre el artículo completo, por ejemplo, o que muestre un gris o que muestre tres artículos. Podemos poner todos estos campos para automatizar el proceso. En este caso, como es un tema framework, no interesa afinar, no interesa definir las plantillas más concretas, sino ir a lo genérico. Nos interesa modificar el single, definir el single, el page, el category, el tag, pero no nos interesa definir el page-contag, el page-about, ¿me explico? Eso lo vamos a hacer en el proyecto. Como digo, generalizar en el framework y afinar el tiro en el proyecto. Cuando hablo de afinar el tiro en el proyecto, hablo de crear un childen y ahí añadir o modificar lo que queramos. Define las opciones de diseño con diferentes template parts. Esto es un fallo que suele cometer la gente, que es si un template, por ejemplo, category PHP, tiene tres opciones, que son gris, blog y minimal. Me hago en el contenido un if, si está seleccionado esto, si esto, si esto, si esto. Y tienes un pedazo código así. Te haces tres template parts, sabéis lo que son los template parts, son trozos de código que funcionan similar al include de PHP, pero con el estilo de WordPress, con todo el backend de WordPress y demás. De esa manera, lo que hacemos es tener tres ficheros diferentes y en caso de que en un proyecto queramos afinar uno de esos diseños, añadir un campo, lo que sea, comodificar y ser template part en el childen lo tenemos hecho. ¿Vale? Os voy a explicar por qué el childen y todo eso. Después lo vais a entender. Y ahora llega el momento del paso final, que es automatizar lo genérico. Aquí vamos a crear páginas base, como la de contacto. ¿Cuánto sabéis crear una página de contacto que sea diferente al formular de contacto, la información y el mapa? Y no todas llevan el mapa. Con lo cual, porque no predefinimos ya que cuando activamos nuestro tema nos cree una página que se llama contacto, cuyo eslaje es contacto o contacto y que tenga este contenido. Luego ya veremos cómo maquetamos eso en el childen, pero ya tenemos la página creada con esa información. Incluso puede ser un contact form. ¿Vale? La clave de todo esto es el after switch de... es un hook de WordPress que se dispara cuando activamos el tema. ¿Vale? En el momento que activamos el tema se invoca este hook. Entonces a ese hook nosotros le enganchamos una función que va a hacer nuestros insert posts, va a hacer nuestra preconfiguración, va a definir todo lo que necesitamos. Después vamos a ver qué en esa página de opciones configuramos lo que nos falta y, o volar, tenemos un proyecto que nos hemos ahorrado para poder crear la página de contacto, crear los avisos legales y un montón de cosas más. ¿Va entendiendo esa idea? ¿No? Va gustando. Y además tenemos un... bueno, se llama plugin activator, no es un plugin, es una librería PHP que nos permite generar dependencias. Es decir, cuando activamos el tema habréis visto los temas premios sobre todo que tienen dependencias arriba. Un aviso de este tema funciona con contacto for 7, revolución sliders, blah, blah, blah, blah y metemos ahí todo lo que queramos, los podemos poner incluso obligatorios. Si yo, este framework es paving y yo siempre trabajo con contacto for 7, le pongo obligatorio y en el momento que active el tema me dice tienes que instalar contacto for 7, le pego al botoncito y ya está instalado. No tengo que ir al repositorio o a plugins, añadir, buscar contacto for 7, instalar, activar, ¿vale? Lo puedo automatizar de esa forma. Algunos truquillos y cosas que tenéis que tener en cuenta porque lo vais a usar muchísimo, que esté listo para traduciones. Creo que eres de perruyo, pero hay que decirlo. Nunca sabéis cuando va a llegar un cliente que necesita la web en dos idiomas o que nada, la necesita solo en inglés y si no está listo para traduciones, todas las cadenas no se pueden traducir, vais a tener un problema porque tenéis que ir al código y dejar codear la nueva palabra o lo que sea. Prevenir usos futuros. Vosotros conocéis a vuestros clientes y sabéis más o menos para dónde pueden ir o hacia dónde pueden ir. Si tenéis la posibilidad de que os toca hacer algún WooCommerce, preparar los templates mínimos de WooCommerce en vuestro framework y ya lo tenéis hecho. Tampoco hay que hacerlo desde el inicio, ¿eh? Esto es muchos años de experiencia, mucho tiempo de experiencia e ir añadiendole cosas a ese framework que os facilite todo. Y sobre todo ir actualizando, pues si antes usabais Flux, ahora se usaba Flux, después se usara Gris, etcétera, etcétera, ¿vale? Ir actualizando todo el tema que tiene por detrás. Lo que se va a servir es una herramienta súper útil. Y lo bueno de todo esto es que lo podéis actualizar con un clic. Os lo voy a explicar ahora, ¿vale? Como me sobraba tiempo cuando lo he preparado, ahora me quedan 5 minutos así, ¿no? Un poquito menos. Bueno, me sobraba tiempo y entonces he puesto las preguntas que me vais a hacer seguro. La primera es esa. Y Divi, Elementor o lo que queráis. No hay ningún problema, podéis usarlo. Si estáis cómodos con ello, en vez de un tema framework, sería un plug-in framework. El problema que vais a tener es en añadir esas funcionalidades de layout y tal y cual, pero también os puede servir. Podéis generar automáticamente, instalar vuestro Divi, etcétera, etcétera y que al activar el plug-in, en vez de after switch, then after plug-in, after switch, plug-in, creo que es. Le engancheis ahí el insert post y todo lo que necesitáis y no es tan potente como esto, pero también os sirvió, ¿vale? Como digo, tiene que optimizar vuestro flujo de trabajo si trabajáis con Divi, pues bienvenidos. No es mejor un plug-in. Esta es la pregunta de siempre. ¿Qué preferís mantener un software o dos? Esto es para vosotros. Si queréis un plug-in, un plug-in, pues lo separáis. En este caso no tiene mucho sentido porque vuestro tema va a depender de ese plug-in. Con lo cual tienen que ir de la mano siempre, entonces lo puedes integrar sin ningún problema. Por lo menos yo prefiero mantener un software que dos. ¿Qué ventajas tiene, pues? Ya os he dicho, todo el tiempo inicial de configuraciones, definir layout, tal y igual, y no sé qué, ya está todo hecho. No es lo mismo entrar a un proyecto y modificar el ancho entre columnas que tener que definir todo el layout con todas las cajas y todo el tema. Y un poquito más, nos gusta tanto este tema que vamos a hacer un childem siempre. ¿Y esto por qué? Porque vamos a actualizar todos los sites de nuestros clientes con un click. Imaginad que olvidáis poner un en el buscador, el playsolder, que sea traducible y ponéis buscar ahí, jarto de agua. Y os dais cuenta, yo no hago multidioma y dices, actualizas tu framework, lo despliegas a tu github y con github deter a todos los clientes les sale la actualización de ese tema. Con lo cual los mantenimientos se ve un poco la utilidad, de todo le veis la utilidad para vosotros. Ya os dije que nos va a servir todo, pero muchas cosas a lo mejor sí. Y ya está. Así que si tenéis alguna pregunta, en tiempo has visto. Si tenéis preguntas, creo que hay tiempo para preguntas, ¿no? Por ahí. De todas formas, andaré por aquí y me gusta hablar bastante. Y nos suena. Hola, Darío. Muy buena la presentación. Gracias. Escuchando lo que has explicado recién, creo que tú los que nos recomiendas, lo que hacemos desarrollo o esto es, generar nuestro tema, esto es como generar nuestro tema, con nuestras opciones y tener nuestro bolsito en blanco, que tanto lo podríamos aplicar como lo estabas explicando ayer, como para una paradería, para un proyecto grande, pero tener nuestras propias sistemas para ir automatizando para nosotros, que sea más fácil. Exactamente. ¿Se me ha cortado el micro? No. Por ejemplo, si tú trabajas con Boostrap o con SaaS o con Postes, es lo que sea, tú te puedes preparar este entorno con todos los ficheros, con el Google File, con todo lo que necesitas, con todo lo que trabajas habitualmente, y es tu forma de trabajar. Quiere decir, este tema framework, plugin, framework, llámano como quieras, puede ser un plugin, lo que pasa es que al tener tanta dependencia el propio tema de SORCODE si tal y cual, a ver, tanta dependencia tampoco es que sea un SORCODE, es un SORCODE, pero es optimizar tu flujo de trabajo. Es decir, si tú en desplegar un proyecto, tardas desde cero con tu framework, es un tema que le metes cuatro cambios y tal y cual, tardas cuatro horas con esto que te automatiza creación de páginas y tal y cual y cual, y tardas dos. Sí, era Craigweight, el título. Pocos minutos, bueno. Y tienes una base sólida porque tú la conoces, la has hecho tú a tu medida y cada vez que tú ves una carencia o una necesidad, lo modificas, lo añades, lo mejoras. Y llega al momento en un año, dos o siete, que tengas un framework que digas, cliente nuevo, web de restaurante, click, click, click, click, boom, ya está la web echa. ¿Qué creas el childe? Le pegas cuatro cambios al diseño, espaciadores, cabecera, tal y tal. Y ya está la web echa. ¿Recomiendas en un tema o esto pasaron un plugin? Un plugin para poder activarlo. Es que depende. Quiero decir, todos habréis trabajado con un tema premium que os gustaba y le habéis hecho un childe, alguno igual no le ha hecho el childe, y cuando salió una actualización. Pero habitualmente, es la forma de trabajo. Quiero decir, un tema que me encaja con el proyecto, le hago un childe, le hago las modificaciones que necesito y ya tengo el proyecto. Esto al final es lo mismo. El tema de meter un plugin o no, pues es que al final va a ser un plugin que gestiona muchas cosas internas del propio tema. ¿Qué le hay a otro escojo para las categorías? ¿Qué le hay a otro escojo para tal? ¿Qué tamaño tiene el extracto? Es que es aplicativo a ese proyecto concreto. Entonces, tampoco tiene sentido, porque si el día mañana te pide un rediseño, tú no vas a cambiar ese framework. Lo que vas a hacer es cargarte el childe con lo nuevo, con las modificaciones que quieren. Y el tema es el mismo. La estructura es la misma, todo es igual. Esa es un poco la idea. Y es lo bueno que te viene un cliente, que ya es cliente porque ha pagado en su día un proyecto web completo, que es una pasta y te viene para un rediseño y si tú te sientes más cómodo dándole a matar al childe y creándome un nuevo, el cliente ni se va a enterar, porque es un rediseño. Realmente es el childe. Y esto es lo que digo. Con un click actualizas todos los clientes, 20, 30, 40, 50 clientes los que tengas, porque todos tienen el mismo framework. Y si tiene un fallo de seguridad, un screen mal hecho, lo que sea, a todos los clientes les manda la mejora. Y el cliente ni se va a enterar. Puede tener o no alojar el mantenimiento contigo. Le va a salir el botón de actualizar igual que un tema normal. Tiene actualización pendiente, le da ok, actualiza, y ya está. Es súper transparente y súper potente. Y ya la parte final de AfterSwitch.D y todo esto para la ranca inicial es una pasada. Es una pasada. Si lo haces bien, claro. Pero bueno, si cambio de tema y no existe esta página, me la creas. No es tan complicado. Como digo, lleva mucho tiempo, pero yo creo que vale la pena. Alguien más, alguna pregunta por ahí? Que no es de vergüenza. Un pequeño tema técnico, aprovecho que te tengo aquí para la creación de estos themes y después seguramente un chal theme a continuación framework. Eres más partidario en estas páginas estilo a contactar las de RGPD, todas estas que existen crear una plantilla para página y que luego auto asignarla o que sea el cliente que lo asigne en atributos de página o crear un archivo de plantilla ya con el nombre, el slag, que sea pues contactar o RGPD. Yo cuando lo gestionaba, lo que hacía era crear en el propio web insert post le puedes definir qué template que eres que utilice, con lo cual te puedes tener un template que sea sin site bar, sin nada, que solo salga el texto y ya está y tú le dices en el after switch then créame un post que lleva esta plantilla con este contenido y entonces ya la tienes predefinida porque al final texto legal no le va a haber casi nadie y te da igual que tengas site bar que no. Entonces crea ser específico para eso. Como digo, depende del proyecto que estés gestionando si tú a tus clientes le pones en el texto legal una foto que iba bien chula y tal pues oye, tendrás que añadir eso también pero básicamente al final es cada uno como trabaje y el perfil de cliente que tengas. Yo entiendo que si tienes un cliente que es más delicado en según qué cosas o más puntilloso, esto no te va a servir para otros clientes. Entonces hay que adaptarse a la forma de trabajar de cada uno que fringos usas o que herramientas utilizas y segundo a tu perfil de cliente. Yo no conozco vuestros perfiles de cliente. Yo conozco el mío y os he explicado lo que hacía yo. Si os sirve y lo podéis adaptar pues estupendo y si no pues oye si conocéis en alguna forma mejor pues también me interceptáis por ahí, me hacéis un placaje y hablamos y ya estaría, no hay pega. Quiero decir, al final lo que se trata es optimizar tu propio flujo de trabajo y quitarnos horas además que son aburridas. A los diseñadores o de las redes no les gusta rellenar una página de información legal y comprobar si están todas las comas. Es que eso a veces vale más la pena pagar 5 dólares en fíber o algo tal y que te lo rellenen otros. Dice, venga entonces si te evitas esas tareas que son bonótonas, que son aburridas, que son teríosas como instalar plugins, si es que siempre son los mismos. Yo termine hasta las narices cuando dice esto del After Sweet Ten termine hasta las narices de ir a plugins a añadir contra Force 7, instalar pensé que instalar. UBP Super Caché instalar, joder. Terminas gastas en tonterías. Entonces si le creas las dependencias, automáticamente te sale que lo puedes instalar de edad y es mucho más aunque sólo sea el visitar plugins añadir nuevo y introducir el nombre en el formulario, porque ya estás ahorrando algo. Y todo esto es eso, optimizar lo que podáis el fofo de trabajo. Alguna preguntilla más? Muy bien, pues venga, fuerte aplauso, muchas gracias. Gracias.