 Con Fambi, esta persona que nos engañe es un joven, gran programador, ¿vale? Tiene experiencia con PHP, con Javasti, Java, T-Chart. Y, bueno, empezó cuando se terminó de formarse con programando con... ¡Uy, me escucho yo! Programándolo para... ...entiendas online y demás, y luego, pues, ahora... ...estás de compimino aquí también en Málaga. También programando páginas web con Wordpress o muchas más cosillas. Esta salida que voy a ver... ...una vez, digamos, pasa en Navitas, pero que el financia sigue retrasando... ...dijimos, mira, presentála y si sale... ...está adelante. Y, bueno, nada, es un beazo curro que se ha metido, para explicar cómo va a funcionar. ¿Alguna? Bueno, soy Juanmi, es mi primera vez. Trataré un poquito con cariño. Y voy a hablar de View y Wordpress, ¿vale? Vamos a empezar explicando qué es View. ¿Víos un frango... ¿alguien ha trabajado con View? ¿Alguna vez? Bueno, dos o tres, uno poquito. Pues básicamente, View es un frango de JavaScript progresivo. Que se usa para generar proyectos de corto o largo alcance. Se usa de manera incremental, usando librerías para agregar funcionalidades que vayamos necesitando... ...en función de desarrollo. Voy a explicar más o menos algunas características de View, que son las plantillas que están basadas en HTML, por lo que son bastante simples, reactibilidad que los modelos están basados en objetos de JavaScript, que ya se han modificado, editan las plantillas. Los componentes, que básicamente es dividir fracciones del código para hacerlo mucho más simple y reutilizable, y reutilizan más el código. Y las transiciones. Las transiciones, al editar, insertar o modificar o eliminar elementos del DOM, se realizan transiciones o animaciones. Porque View y no otros framework. Básicamente, por lo que hemos explicado antes, la simpresidad es bastante simple, su curva de aprendizaje es muy corta, y es fácil y intuitivo entender. Usabilidad. La aplicación se puede dividir de la manera que queramos, mientras estamos utilizando el sistema de componentes y el rendimiento. Es uno de los framework mejor valorado, ya que es bastante ligero y bastante rápido, con un alto rendimiento. Y ahora la pregunta es muy importante. ¿Por qué View y WordPress? Básicamente, esto, os voy a contar un poco mi vida, y es que la empresa que estoy, existía una página y ya existen, existía ya una página, que era una tienda online basada en Laravel y con un blog en WordPress. Y se realizaba un redireccionamiento directamente a WordPress. Pero se quiso hacer una refactorización de todo el sitio web. Así que se basaron en nukes. Pero claro, entonces existían dos opciones. Rehacer todo el blog otra vez, actualizando todo el template y todas las funcionalidades o poder reutilizarlo todo lo que podamos aprovechando el SEO que ya teníamos. Así que lo que hicimos, fue realizar modificaciones en WordPress para que sea atacado desde la API y poder utilizarlo en una aplicación externa hecha con nukes. ¿Por qué View? Porque nukes y no View. Básicamente, porque cuando empezamos a realizar este proyecto, View tenía un problema con SEO, que no se hizo friendly. Así que utilizamos nukes, y lo que hicimos es que se utilizara el SEO. Revisamos algunas series de modificaciones, uso de plugin que explicaramos más tarde y veramos también algo de código que tuvimos que implementando para que funcionase correctamente los requisitos que queríamos en la API. Los plugins utilizados es Gutenberg, que seguramente lo conoceréis ya, ¿no? ¿Todo el mundo ha trabajado con Gutenberg? ¿Hay alguien que no? Yo que todo el mundo. Yoas, que básicamente lo utilizamos para poder beber del SEO que teníamos ya hecho a base custofil para realizar unas pequeñas modificaciones en los posts, por requerimientos de mercado etc. y CodeSniper. Básicamente, CodeSniper lo habéis utilizado alguno. CodeSniper, básicamente es un plugin que permite realizar modificaciones en el código pero sin tocar lo que viene siendo archivo del propio WordPress. Realiza código PHP o JavaScript y lo ejecutas en función de vallas criendo. Es bastante útil porque si la alías lo podés activar directamente en la base de datos o te da opción de volver atrás. Básicamente se usa para no liarla o pues si a mí me gusta bastante porque se puede descargar y exportar a otros proyectos. La creación de los campos personalizados. Como explicaba antes, tuve que hacer una serie de modificaciones en los posts para poder utilizarlo según las condiciones que teníamos. Una de ellas era post relacionado que básicamente es un listado que puede relacionar posts con otros posts. Pero sí, siempre tienen que estar públicos sino no podría relacionarlo. El lenguaje del propio post para filtrar que voy a realizar después en la API y en mercado. Básicamente se divide en diferentes mercados y tenía que realizar unos filtros. Ahora voy a hablar de la generación de rutas que tuvimos que realizar para poder consumir la API según los requisitos que nos habíamos planteado. El listado del post que básicamente obtenemos un listado de todos los posts en función del mercado y el idioma y se están activos un post único que se relaciona según es lo que mandamos o tenemos el idioma del post. Los metaparámetros, que es lo que explicaba antes que ya lo teníamos y teníamos que reutilizarlo, que básicamente con el slug del propio post recogíamos todos los metaparámetros y la lista previa. La lista previa hay un problema con Gutenberg que es que no podía modificar para acceder a una vista previa en una página externa. Ese es uno de los problemas que no encontramos solución, pero más o menos pudimos encontrar algo parecido. Aquí tenemos una muestra de código que es para mostrar todos los posts que básicamente obtenemos todos los parámetros que le pasamos mediante una petición de view que le pasamos todos los parámetros que necesitamos. ¿Cuáles son? Pues tenemos el lenguaje y el mercado el que queremos trabajar. Realizamos la query y sacamos todos los parámetros que estamos mostrando ahí y aquí está la creación de la propia llamada del endpoint. Para obtener un post únicamente mediante un slug esto básicamente le pasamos en slug y lo consultamos, ya no traemos en cuenta el idioma y el mercado porque realizamos un filtro previo y obtenemos el post en función del slug. Realizamos una query y obtenemos el slug y los posts relacionados, que son parámetros que pertenecen a la vasta avance cutoffing. Lo sacamos, recorremos un bucle para sacar los posts, el post en sí y otros bucles para sacar directamente los posts relacionados. Y aquí está otra vez la llamada del endpoint y ahora voy a hablar de la obtención de los metaparámetros. Básicamente para esto estoy utilizando el YoAzSeo que ya me da los propios parámetros que necesitamos en un principio. Os tenemos la Keyword, el título y la meta de inscripción. La cosa es que el YoAz, a lo sé que sea de pagos, no te permite poner más de una Keyword. Esto se puede solucionar si aprovechamos un poquito el YoAz y las funciones que tenemos. Como estoy mostrando aquí, yo pongo punto y coma o coma para poder meter más de una Keyword directamente y no usar el YoAz de pagos. Un poquito pirata pero algo para salir del paso venía bien, la verdad. ¿No hagas esto en casa? Vale, aquí ya estoy... Perdón, que me he saltado. Esta es una función que la tengo externa a la de sacar lo que viene siendo los metaparámetros por sí solos. Lo tengo separado para poder reutilizarlo en varios sitios si era necesario. Yo tengo la función separada con el POS y los metaparámetros porque NUGS, el rendizado de NUGS, se realiza de forma diferente. Para obtener los metaparámetros realizo una petición previa antes que se renderice el NUGS para que la anña de Google pueda encontrar metaparámetros. Por eso la tengo en funciones separadas, una llamada de lápida y la otra. Pero esta función la tengo así que voy a ponerla en más sitios para llamarla de forma independiente. Para poder reutilizar un poquito el código. Vale, en función del Sluke que le estoy mandando obtengo los metaparámetros de ese POS en concreto. En caso de que no exista, por ejemplo, la meta de descripción, cogera por defecto la de las dos primeras líneas que me parece que era de propio POS. Aquí tengo la llamada otra vez y el código. Mostrarla previendo un POS. Como he comentado antes, Gutenberg tenía un pequeño problema que básicamente era que no puedes modificar en sí el enlace de la previo. Estuve intentando, estuve documentando bastante y todavía no había encontrado nadie respuesta y no había desarrollado esa función todavía. Por lo que ahora más adelante mostraré una función que más o menos puede solucionar ese problema. Aquí obtenemos le damos al botón de Preview como siempre hemos hecho y obtenemos una idea, la idea del POS. Sacamos la última modificación de ese POS y sacamos todo el contenido de ese POS para obtener en sí la Preview y lo que hacemos en la siguiente información que está aquí básicamente es obtenemos el link que se genera al guardar el POS y lo redireccionamos a nuestro propio sitio con la idea del POS. Esto ya redireccionaría y con la petición anterior ya nos daría toda la información que necesitamos para mostrar una Preview. Bueno, yo me he más rápido de la cuenta, pero... Perdón. Bueno, mi conclusión. Esta es una de las formas de trabajo que hay con View y WordPress. Hay diferentes formas. Una de ellas es compilar lo que viene siendo la aplicación en View y poder utilizarlo en un sort code pasando el parámetro. A mí no me gustaba mucho esa opción pero aparte existen dos más. Y otra que es más o menos similar a esta pero básicamente generando un template que sea llamada la API utilizando View y PHP. Básicamente genera un template con un index, un function, header y footer. Lo podrás generar todo en base a View y el index lo único que contiene es la inclusión del archivo de la app. Y básicamente index el ID del app y ya puede utilizarlo directamente. Para mí yo creo que una de las formas de trabajo mejor es utilizar de manera dentro y de manera externa para consumirlo sin problemas. Y... ¿Qué que ya hay un problema? Ya he terminado. Ha sido breve pero intenso. ¿El qué? ¿Por qué? Porque quería refactorizar toda la página. Pasamos a... ¿Por qué? Porque la página en principio no tenía éxito y se decía que era por la estética. Y ya que vamos a cambiar la estética vamos a cambiar todo el lenguaje. Y al cambiar todo el lenguaje dice no, ¿por qué no cambiamos directamente a View? Empezamos informando de trabajas con View y empezamos a realizar microservicios para que se han consumido desde View. Pero claro, no tuvieron en cuenta el blog que ya lo teníamos ahí y lo que querían hacer era seguir con una redirección. ¿Qué pasa? Ya tenemos un problema ahí muy serio porque estamos cargando una aplicación View y después estamos haciendo una redirección a otro sitio aunque sea en el mismo sitio pero es un WordPress, claro, eso reventiza un montón los usuarios porque tenés que ganar templates, ese es diferente, etcétera. Por eso lo que decidimos es customizar el WordPress competiciones de la API ya sea la preview y todo para que solamente generen contenido utilizando el WordPress que es lo que más feminizado estaba y usando Gutenberg que antes estuvimos hablando de diferentes editores de Dragon Drop y decimos Gutenberg porque era bastante limpio bastante plano y no había problema para integrarlo. El único problema es que no hemos encontrado el preview. ¿Alguna pregunta llamada? Sí, claro. ¿Cómo le... los bloques como identificar? ¿Cómo identificar? ¿Cómo hacer filtrado? ¿Cómo hacer filtrado de bloques? ¿Y qué es el sentido? Ah, con un HTML plano y bastante simple no genera un código extra como en el caso que estuve contemplando de Visual Composer. Básicamente cada componente de view se identifica por un comentario en el propio HTML. ¿Alguna cosilla más? No, terminamos.