 Buenas tardes, buenos días, buenas noches, ni ya no sé de dónde vivo, ni de dónde estoy. Tengo el placer de presentar a Juanjo, Hernández, yo lo llamo JJ. Tuve el placer de conocerle en la World Cup 2023 como voluntario, lo tenía pegadico aquí todo el rato, pobrecico mío, pasó muchos nervios, lo pasó muy bien. Y, bueno, pues, tu charla salió seleccionada y, lógicamente, era yo que tenía que presentarte sí o sí, porque nos llevamos muy bien. Hemos hecho buena química, de hecho su mujer está un poco enfada conmigo. Os dejo con Juanjo, con JJ, que también parte, por cierto, de la organización, no de la World Cup, pero sí de las Meetups, y nos ha hecho un calve de vez en cuando. Así que, un fuerte aplauso. Gracias. Buenas tardes a todos. Muchas gracias por haber elegido esta charla. Lo vamos a hablar sobre el API de WordPress, que es lo que nos ofrece el API de WordPress, y cómo podemos hacer un WordPress desacoplado. Quería empezar con esta presentación, indicando cuando empezó el WordPress, el API de WordPress. El API de WordPress empezó con la versión 4.4, en diciembre del 2015, y en el WordPress la 4.7, en la versión de 4.7 de 2016. Se coronó ya con lo que conocemos ahora, con los términos, taxonomías, páginas, post. Y los nombres que hay de Clifford, trompetista, y Vawgan, que fue una vocalista, son artistas de jazz. No sé si lo sabíais, a mí me pareció muy curioso cuando me enteré, pero WordPress utiliza, en todas sus versiones, artistas famosos del mundo de jazz. Y esto, a raíz de todo, es porque tenemos una cultura colaborativa, una naturaleza innovadora, y en constante evolución. Y yo creo que eso es lo que representa WordPress, y por eso estamos todos aquí. Y esto es una Workup, y al final, esto es lo que nos une a nosotros como plataforma. Hoy vamos a hablar sobre el API de WordPress, que es el API de WordPress, que usos le podemos dar al API de WordPress, y por qué podríamos hacer un WordPress desacoplado, si podríamos hacerlo o no podríamos hacerlo. ¿Os gusta el menú de día de hoy? ¿Empezamos? ¿Qué es la resa API de WordPress? La API de WordPress imaginamos que es un túnel, un puente entre nuestro WordPress y cualquier otra aplicación. ¿Qué decimos con esto? Que podemos llamar a la API de WordPress, directamente, para obtener esa información. Podemos editar, podemos añadir o obtener contenido de todo el WordPress. Con lo cual, en el parámetro actual digital, donde las webs se representan de una manera, podemos cambiarlas y podemos obtener esos datos a través de una aplicación móvil, o cualquier otra un read, o cualquier otra aplicación externa que sea un frontend, y dejar el WordPress con un framework. WordPress podríamos dejar solamente, por ejemplo, los usuarios, podríamos crear un custom post type, dedicado a cursos, por ejemplo, y dejarlo en un sitio distinto, y de esta forma poderlo llamar con una serie de métodos. Y estos métodos que tenemos aquí, que son los mismos que para cualquier API, tenemos el método get, que podríamos obtendremos toda la información que nosotros queremos. Tenemos el método put, que sería para actualizar. Tendríamos el método post, que sería para añadir contenido. El delete, yo creo que no hace falta casi ni decirlo. Pondríamos el idea de un medio, de una página, de un post, y vos haríamos eso. Y el pad es entre medio del put y el post. Lo que haría sería actualizar, en concreto, un contenido, un tipo de contenido. Si nosotros tenemos un post y queremos actualizar solamente el título, podríamos utilizar el método pad. Vale, y aquí, bueno, hemos estado hablando de la resapi. Esto de V2Curses, pues sería la forma que nosotros llamaríamos a nuestra API de WordPress. Delante vendría nuestro dominio, y podríamos coger de los cursos, si fueron custom post type, o los usuarios, o los posts, directamente al WordPress. Pero dentro de la API de WordPress, ahí es una llamada por URL, pero podemos utilizar también GraphQL, que GraphQL es un lenguaje de consulta, que es distintamente y no está dentro de WordPress. Es otra forma de llamar a API, y es un lenguaje. Es un lenguaje que lo que se creó a través de Facebook, en el 2012, unos ingeniosos, porque veían que la latencia de la resapi, de un API normal, pues era muy lenta, y montaron el GraphQL para poderlo hacer. Y es un lenguaje de consulta que se crea, y se monta para hacer las consultas. Vale, ¿qué tipos de autentificación y seguridad podemos tener a la hora de poder utilizar nuestra API? Bueno, pues tendríamos la básica, podríamos hacerlo por tokens también, tendríamos la API key, la cookie y por certificado. Y ahora vamos a ver, para que no suenen todas, hay que ser una diapositiva de cada una de ellas. Entonces la básica sería la que conocemos todos, HTTPS, un nombre usuario y una contraseña, y de esta forma podríamos conectarnos a la API de WordPress. Tokens de acceso o A2, esto ya es, ya no está dentro de WordPress, ya necesitaríamos un plugin para poderlo instalar, y tendríamos el registro de aplicación, la solicitud, la confesión y la emisión. API key, pues utilizaríamos una key para poder llamar a nuestro WordPress, y esta key pues seguiría enviando en todas nuestras consultas. Y la cookie, la cookie sería cuando nosotros nos autentificamos en el navegador, y ya tenemos una cookie, y utilizaríamos solamente esto, cuando queremos utilizar la API key, pues a través de nuestro propio tema o a través de un plugin, entonces solamente valdría si estamos bloqueados en ese navegador. Y aquí vamos a ver una serie de prácticas y consejos. Vale, primero, la autentificación. Pues tendríamos que autentificarnos con uno de estos métodos, con más seguridad, mejor, al igual que con la protección, deberíamos usar siempre certificados, siempre HTTPS, conexiones seguras, etcétera. Y la restricción, pues siempre vamos a usar del nivel menor al mayor. O sea, nos vamos a dejar un usuario que pueda administrador para solamente editar un contenido. Entonces, crearíamos un rol específico para eso. Y luego la validación. Vamos a ver un poquito más la validación, pero la validación sería comprender un poco para maitrizar los datos, para poderlos traer. Si es un email, pues le pondríamos alguna consulta de e-mail para poderlo validar. Y así que no nos pudieran gestar código malicioso. Vale, vamos a ver, guau. A la hora de crear esta charla, vi que, claro, no podríamos aquí mostrar mucho código y entonces he dejado una serie de, digamos, de puntos que los vamos a ver ahora. Y quería comentaros que cuando me dijeron que fuera voluntario en, o sea, ponente en la WorkCamp, pues creé un blog en el que voy a meter toda la información que he obtenido al hacer esta charla. El blog se llama juanjo.qxyz y entonces a lo largo de la semana que viene meteré toda esta información. Y mi primer objeto de este año era poder hacer una ponencia. Ya lo he conseguido. Y mi segundo objeto era convertir ese blog juanjo.qxyz en un WordPress desacoplado a través del grigato. Entonces, vamos a ver un poquito lo que son las optimizaciones de consultas para mejorar el consumo del API. Vale, WLP query. Cuando me enteré de esta función que se podía transmitir a través del API, me cambió la vida. ¿Por qué? Porque podemos crear un custom post type, podemos tener un custom post type de cursos, y podemos directamente enlazarlo para que se consuma a través de la API, con lo cual ya no tendríamos solamente posts o tendríamos páginas, sino también que podríamos hacerlo desde WordPress. De esta forma, podemos limitar el acceso tanto por usuarios y podríamos limitar el acceso con la paginación. Y directamente se consumiría con una única ruta. Cuando creamos un custom post type deberíamos utilizar siempre su WinRES a true, sino ese custom post type no estaría abierto a ser consultado por la API. WLP prepare es una instrucción que se utiliza mucho en WordPress para poder sanitizar todo lo que es la consulta del SQL y que nos puede entrar código malicioso. Y luego los sanitize, que es lo que hemos comentado antes de e-mail o e-entero, o cualquier otra de las funciones actualidades que tenemos para poder evitar la inyección de código a WordPress. Y aquí empezamos ya con el WordPress acoplado, modelo vista controlador, pues es como lo veo yo. Tendríamos tres capas. Tendríamos el modelo WordPress, que sería donde tendríamos todo WordPress, podría ser solamente una gestión de usuarios o podría ser un portal de noticias. Luego tendríamos el controlador, que sería la API o GraphQL el que quisiéramos y la vista. Y esto se llama Jamstack, o sea, esto es una arquitectura que se usa para todos los CMS, tanto para Drupal como para WordPress. Y WordPress no podría ser menos y también lo puede hacer. ¿Qué beneficios tiene el WordPress acoplado? Bueno, pues en principio la flexibilidad, porque tiene interface de usuario que pueden ser interactivas y atractivas. Podemos meter cualquier uso que queramos, por ejemplo, un React o un View o cualquier tecnología emergente de las que estamos ahora viendo. Y el rendimiento, porque solamente cargaríamos los datos necesarios. Nosotros apuntaríamos al WordPress y le diríamos, eh, pues traeme los datos de los últimos posts. Y entonces solamente me mandaría los cinco últimos posts o un post en concreto. Y de esta forma sería mucho más rápido, porque no cargaría todo el WordPress entero. Seguridad, reduce los ataques, porque nosotros podríamos tener los, incluso, en distintos servidores y a través de una IP que podría estar oculta, pues no haría falta ni que, simplemente, llevando a través de una IP, pues ya podríamos tener ahí el WordPress y estaría oculto. Y escalabilidad, pues es lo mismo que la flexibilidad que nos da esa escalabilidad en el tráfico que pueda haber elevado. Y ahora, WordPress desacoplado. ¿Por qué, qué os parece todo esto del WordPress desacoplado? WordPress es conocido por su facilidad de uso e instalación en blogs públicos, en e-commerce, en portales de noticias. Pero yo creo que WordPress puede utilizarse con un framework, es lo que hemos dicho antes, y se puede hacer desacoplado. ¿Vosotros qué opináis? ¿Podríamos crear un WordPress desacoplado? ¿Tenéis alguna idea, por ejemplo? Si quisiéramos hacer un blog, sería útil tener un WordPress desacoplado, ¿no? Sí, dependiendo del consumo que tenga. Tener en cuenta que un WordPress desacoplado, una de las noventajas que tiene es que vamos a tener que estar manteniendo dos cosas. Van a tener que mantener un WordPress con sus plugins, con sus actualizaciones. Y vamos a tener que tener montado un Riad. Si no sabemos Riad o cualquier otra plataforma, vamos a tener ahí el doble de trabajo. Pero, por ejemplo, si vendiéramos páginas web adoc al cliente final, podríamos tener un multisite en WordPress. Y de esta forma, solamente modificaríamos un WordPress y tendríamos el Riad que podríamos reutilizarlo para todos nuestros clientes, por ejemplo. Eso sería una de las opciones. Si os ocurre alguna otra más o algo que podéis implementar, ¿no? No sé cómo voy de tiempo, ¿sí? Bien. ¿Cuánto queda? 30 minutos. Vamos. Vale. Pues esto es lo que hay. No sé si tenéis alguna pregunta y así podemos hacer esto un poco más a menos. No sé si alguno, sí. Mira, espera que va con mi compil. No, que digo que estaba pensando que como con React, con utilizando el REST API, se podría utilizar quizás una versión de un sitio web en el teléfono, algo que fuese más rápido en un subdominio o algo. Aunque no sé yo si la práctica anteriormente, cuando salieron las páginas web en teléfono, se solía hacer una página específica para teléfono. Y luego otra para desktop. Eso no sé si es una práctica ahora actual. No, ahora no, ahora de hecho existe el frizz mobile, ¿no? O sea, primero programamos el móvil y eso lo convertimos ya en escritorio. Eso se creaba antes porque tenías que hacer dos diseños distintos. Tenías que crear un diseño para móvil y otro diseño para escritorio. Ahora ya no es necesario. Si que había antes el dominio que ponías un subdominio antes, móvil y entonces dabas una página para móviles y otra para tal. Pero por qué se hacía eso? Porque el consumo era distinto en escritorio. Sabías que ibas a tener una latencia, una wifi o una calidad de red mucho mejor que el 2G o el 3G que hubieran aquel entonces. Entonces por eso se derivaban. Lo que se propone aquí con el WordPress se ha coplado es tener un WordPress en un sitio y que luego tengas cualquier otra fuente de datos. La fuente de datos sería WordPress pero en la redrupción la podrías poner en cualquier otro sitio. Por ejemplo, se podía crear una aplicación nativa en Android o iOS y apuntar a ese WordPress y decir, oye, mandame los usuarios o recibir los cursos o cualquier otro custom post type que tengas en el WordPress. Hay alguna situación en la que tú siempre recomendarías utilizar el API. Vale, yo no les recomendaría en ninguna circunstancia, nada nunca. Me explico. Y ahora te explico porque dependiendo de la necesidad, o sea, no te digo, claro, de qué presupuesto estamos valorando, ¿no? Es que yo quiero hacer una página de 600 euros. Pues no te diga ni para el WordPress. Si tienes un departamento, por ejemplo, que se dedica al frontend y otro al backend, entonces sí que es ideal porque estás evolucionando mucho más de prisa, el backend puede crecer más y hacer las páginas mucho más rápidas y efectivas porque tienes a una persona que sabe de lo que está haciendo en frontend y está especializada en eso. Hay algún plugin, y estoy ya para darte un poco de tiempo, sabíamos que teníamos que dar para darte. Vamos, te invito a una cerveza luego. Muy bien. Hay algún plugin que facilite unir WordPress con React. Sí, hay varios. Yo he estado probando, pero no lo he terminado el todo porque soy novato en React. Pero hay un plugin que se llama Gatsby que trabaja junto con GraphQL y te monta directamente todo ese entorno. Luego también he visto varios plugins que lo que hace es convertir un poco todo a React. Y luego he visto también portales de React que lo que hacen es llamar directamente a WordPress. Todas estos de aquí los llevo probando junto con mi blog para que se puedan ver un poco qué opciones hay y qué problemas he tenido. Viviré esa experiencia y la demostraré para que veáis cuántas veces me da cruces con el React. Muchas gracias. A ti por todo y te doy una cerveza. No hay falta que corras, hay que hay tiempo. Sí, siguiendo un poco lo que ha dicho el, realmente no hace falta tener desacoplado. Tú puedes tener una web normal y luego tener la opción de con React Native a hacer una aplicación de nativas. Puedes hacer las dos cosas y decir, sí. A ver, no sé si he entendido tu pregunta. Sí. Yo tengo una web normal ahora mismo. Sí, un golpe. Y ahora me dice el cliente, quiero aplicaciones nativas. Sí. Puedo coger. Puedes montar un React en cualquier caso. Con React Native, tengo la parte de la web. ¿Que sigue igual? Claro, tú llamarías al WordPress para obtener la información. Eso es. Sí, sí. A través de la API de WordPress o a través de GraphQL. Podrías hacerlo sin ningún problema. Buenas. Hola. Una pregunta, se podría tener, a mi lado que me surges, si yo podría tener un WordPress en un servidor implementar y hacer una comunicación API hacia otro servidor donde esté el dominio principal al que se le quiere atacar con un React, no generar algún tipo de tardanza en pasar los datos. O sea, cuando tu ataca, cuando el usuario acceda a la página que está en React, no tardará luego en recibir esos datos o tendrías que tirar de caché. Vale. A ver, cuando tú apuntas directamente, eso es instantáneo, o sea, te descupe un JSON. O sea, tú haces una llamada con el... Vamos a encontrar esta. Vale. Tú harías una llamada, espera, que tengo hasta bolí. Tú llamarías a tu WordPress o a juanjo.xyz y llamarías a esto y le dirías que es lo que quieres obtener. Aquí obtendrías todos, para que está limitado a 100. Pero tú le podrías decir limit 10 o limit tal. Y esto te devuelve un JSON, pero ya está. Y de ese JSON es el que cogerías con el React. No habría ningún proceso de... Aparte, le podrías poner algún tipo de caché o lo que sea. Pero la ventaja que estás obteniendo es que, cuando tú haces un WordPress desacoplado, tú tenías el React, tú estás metiendo solamente el HTML y ya estás renderizado. Lo que tú obtienes de tu WordPress es solamente eso los datos. Todo lo demás ya está en tu aplicación, que es un HTML, tal cual. Luego, ahí, incluso, he visto que hay formas de que, puedes mostrar una parte de contenido y esperar a que luego se cargue toda la otra parte de los contenidos que tú necesites y poder ir navegando. Pero con React podrías... Bueno, saca. Con React, tú llamas directamente a... Está en los datos del JSON, pero si no se que hubiese algún problema en el servidor donde traen los datos del WordPress, en teoría, te tiene que ser más o menos rápido con React. Claro. O sea, bueno, si hay un problema con el otro, o sea, con el WordPress, no tendrías... No, si hay un problema, pues ya no tendrías datos, claro. Sí, no voy acá. Pero así, o sea, es rápido. O sea, yo lo he probado, bueno, de hecho, mira, nosotros para un cliente, lo que hicimos es que teníamos un .NET, bueno, eso es un Delphi, pero vamos a decirle .NET para que quede un poquito más bonito. Y lo que decía era que nos mandaba cursos. Entonces, eso lo teníamos en un multisite en WordPress, ¿vale? Entonces, nosotros creamos una cadena para añadir, editar y borrar cursos. Entonces, Delphi, cuando me picaban el curso, le decían, oye, al WordPress, este es lo que quiero que añadas. Y entonces, nosotros, con custom post type, tendríamos todo lo que es esa estructura del curso. Tendríamos con Advanced Customs Files, tendríamos, pues, el título del curso, tendríamos ahora las fechas, el horario, los participantes y directamente se guardaba. Incluso teníamos otro ID, porque cada vez que tú editabas un curso, el ID podría variar, porque venía Delphi, entonces, a través de ese es el único, el ID que teníamos de cabecera para poder añadir o editarlo o incluso borrarlo y no usar el ID del WordPress. Incluso las imágenes las metíamos con base 64 para no guardarlas en medios y de esta forma no tener la misma imagen varias veces. O sea, al final puedes hacer muchas cosas chulas con esto, pero es muy rápido, con él y eso. Vale, gracias. ¿Está convencido? Bueno, podemos hacerlo juntos, si quieres. Hola, decías que se puede hacer un WordPress Multisite sin tirar, digamos, del WordPress Multisign nativo de WordPress. En ese caso, el enroutado de RLs tendrías que hacerla a través de WordPress o se podría hacer con un servicio externo? A ver, si tú haces un WordPress Multisite, tú tienes que hacer en el Multisite, tendrías todas las... O sea, vamos a partir de la idea de que un Multisite es un WordPress que se escala encima, creas como una especie de administrador superior de todos los WordPress y tú puedes instalar ahí los plugins y puedes decidir en qué sitios, en qué hijos quieres que estén activos, ¿vale? Me interesa, sobre todo, la arquitectura de RLs de Caralseo, es decir, esa parte, las URLs externas, las visibles para el usuario. Es un dominio cada uno, cada Multisite, cada hijo tiene una URL distinta. Claro, yo lo que quiero es tener en un mismo sitio WordPress con varios subdominios gestionarlo desde un mismo dashboard, por así decir. ¿Eso se podría hacer? Eso, yo creo que no se podría hacer con un Multisite. ¿Tendrías que instalar algún plugin? Por eso te pregunto, hacerlo con lo que tú comentas porque creo que con la forma nativa no se puede. Claro, es que de forma nativa no puedes tener un WordPress Multisite. Tendrías que instalar un plugin para poderlo hacer. Sí, sí, digo que como con el plugin de WordPress Multisite no se puede, si con las soluciones que comentas se podría hacer un bypass y... Sí, bueno, a mí se me ocurre, por decir una cosa ahora en dos segundos, a mí se me ocurre que tú tendrías esos subdominios creados en RLs o creados en cualquier otra aplicación que quisieras y que llamará a un único WordPress. Ese WordPress sería el que te mostraría toda la información. Bien, lo podrías diferenciar o porcards un whose type o por categorías. Te querías por ejemplo post y pondrías esta es la categoría para este sitio. esta es la categoría para el otro sitio y tú llamarías y harías las consultas parametrizadas a través de esa categoría tu acimón, bien. Claro, y esa solución que dices de React? Hay alguna que no sea de React que sea... Yo creo que digo React porque es lo que es más, lo que es más lo que mo la de decir pero está en 하게As Hay muchas más. No quiero un framework de estos tipo de ángulos. Cualquier cosa que puedas llamar a un API o bien a la resapi de WordPress, o bien con GraphQL, podrías hacerlo. Muchas gracias. A ti. Alguna otra pregunta. Ya no hice ropeza, ¿eh? Bueno, es Juanjo. Estamos hablando de esto hace tiempo, aunque no sé si me lo llegas a resolver y quizá hay gente que tenga la misma duda. Cuando un gestor de contenido está editando el contenido y tiene la opción de previsualizarlo, sabe cómo va a quedar en el frontal. Al final, al cabo, quizá con contenido estructurado sea más fácil hacer una idea fidedica del resultado final. Me alegro de que me da esta pregunta, porque se me había olvidado decirlo. Aquí tenemos un problema que yo creo que vamos a tener en todos los sitios o todas las veces que hablemos de WordPress. WordPress tiene la capacidad de previsualizar el contenido. Es muy incómodo que tú estés trabajando y le des al botón de previsualizar y lo veas. Pero ¿qué pasa que cuando estamos mandando a través de un API o recibiendo esos datos? Ya le estamos dejando a un usuario, que Filipa con los usuarios, a un lienzo en blanco para que lo cargue directamente en un lado. Entonces, ¿cuál es mi opción a eso? Yo creo que todo tiene que venir integrado, entonces tendríamos un diseño de UX donde se va a generar cómo queremos que aparezca esa web y luego lo plasmamos y creamos un film en WordPress. Entonces, si por ejemplo nosotros vemos que va a tener un slider y tiene tres tipos de slider. Uno con imagen de fondo, otro con imagen a la derecha y otro sin imagen. Nosotros le vamos a decir al usuario o el usuario va a poder indicar qué tipo de slider quiere, qué título quiere, qué texto quiere. Pero no le vamos a dejar un lienzo en blanco para que haga cualquier cosa y que luego descojone o destroce cualquier cosa mejor. O sea, mi opinión es que todo esté parametrizado y que el usuario no tenga que hacer más que solamente escribir el campo. Por ejemplo, un curso. Pues un curso, yo le voy a dejar que ponga el título, pero no le voy a dejar un text área para que me senta donde vamos, para que meta la información del curso, sino que yo le crearía un campo de lugar, un campo de categoría o un campo de tipo de curso o el horario o la fecha, pero para que él fuera ir añadiendo de esta forma todos los cursos estarían igual. Y como están todos igual, estarían los podría consumir posteriormente en una API o en cualquier otro sitio. Es mi forma o mi toco de hacer las cosas. Hola, Juanjo. En primer lugar, muchísimas gracias por la ponencia. Una pregunta muy pequeñita, pero me gustaría saber tu opinión. ¿Consideras que el futuro de WordPress es headless? A ver, sí y no. Porque yo con eso... Y claro, es que... Que razona tu respuesta, por favor. Sí, sí. Y ahí voy. Claro, WordPress está altamente conocido por crear blogs públicos y comers o portales de noticias. Entonces, dependiendo de la finalidad o de lo que queramos, no es que sea un futuro. WordPress sigue avanzando y sigue avanzando, por ejemplo, con Gutenberg o con la gestión de bloques. Entonces habrá que ver si es necesario crear un WordPress que se ha cobrado o no. El futuro, pues no lo sé. PHP, lo que estábamos hablando antes, que PHP igual inmediata un cambio o una vuelta de tuerca. Pero todos los CMS se basan por ahora en PHP, aunque se están volviendo muchos con RIA, con otras tecnologías. Entonces yo voy a intentar hacer mi blog, lo voy a desacoplar. Y cuando ya te digo, oye, mira, llevo dos semanas ya y he conseguido esto o no he conseguido nada. Por ahora he empezado, pero no sé. No es que yo creo que haya un futuro... Uybo. Ya me he echado. No creo que haya un futuro, o sea, creo que esto es un aporte que se puede hacer en un sitio web y no es que sea definitivo, pero está chulo. Yo creo que, dependiendo de la necesidad del cliente o del proyecto, se puede dar o no se puede hacer. Es una opción. No sé si te he contestado bien. ¿Alguna pregunta más por aquí? Sí, ¿no? Sí. Espera, espera, espera. Hola. Se puede hacer lo mismo con la API que haciendo, cargando haciendo un requiere del vp.loat. Sabes que a veces para, si queremos sacar datos externos, hacemos un vp.loat, lo incluimos y ya podemos programar sacando datos de... ¿Cuál es la diferencia entre eso y la API? La API es un protocolo que tú te conectas directamente al WordPress de forma externa de lo que tú estás diciendo es enlocal. O sea, es en el mismo WordPress tú coges y creas una función para poder estar en el mismo WordPress. Pero yo lo que te propongo es que tú tengas el WordPress aquí y el realidad o cualquier otra palabra de la forma en otro sitio o en otro servidor. Pues no sabría decirte, si quieres lo comentamos luego podríamos escribir un mensaje y yo miro a ver la diferencia porque que yo sepa solamente eso es enlocal, vale, dentro de funciones. ¿No? Tendrías que crear un plugin. Claro, pero es que la funcionalidad de la API es que esté fuera del otro servidor, fuera de ese servidor. O sea, yo me puedo conectar a cualquier servidor, vale, con la API de WordPress, o sea, desde... ¿Vale? Y lo que tú propones es que esté en el mismo servidor, ¿sabes? Ya miraré a ver si se puede comentar desde otro. Lo miraremos juntos, vale. Gracias. Pero aquí hay otro pregunta por ahí. Bueno, no era buena, Juanjo. Era simplemente por continuar lo que está preguntando el compañero por si puedo aportar algo en este aspecto. Yo entiendo que con la API lo que estamos trabajando es con datos, siempre datos, mientras que al hacer un include o un require del WP Load, lo que estamos haciendo es trabajar con el propio WordPress a nivel de desarrollo. O sea, es decir, yo cuando lo he usado es para cargar la cabecera del WordPress en una página externa, en una página externa, por ejemplo, en un admin, para cargar las propias librerías del WordPress, para cargar sobre todas las funciones, funciones que yo me he creado, funciones custom que me he creado en el propio WordPress. Pero en este caso, evidentemente la pregunta tiene mucho sentido, si bien es cierto que lo que se puede hacer con la API, en muchos casos, se puede hacer de esa manera, evidentemente. Pero puede que se pueda hacer de fuera del servidor, no lo tengo muy claro, ni le veo mucho sentido porque estás cargando un archivo PHP, no sé, es que no creo ni que se pueda, seguro que habrá alguna manera, pero no tendría sentido. Siempre la gran diferencia es que de esa manera, sí que tienes que estar entre el servidor, sí o sí, como ha dicho Juanjo, mientras que la API, la gracia es que tú tengas, bueno, no, pero que tú tengas un servidor con el WordPress como admin y luego tengas una página externa o múltiples páginas externas, también como ha comentado el compañero, para crear diferentes fronts. Pero sobre todo la diferencia es que para mí básica es que con la API lo que estamos haciendo es trabajar con los datos, y con lo que tú dices, si bien se puede trabajar con datos, lo que vamos a hacer es trabajar con las propias funciones del WordPress. Entonces, en realidad, la pregunta es, ¿se puede hacer? Sí, claro que se puede hacer, pero son sistemas diferentes, no tiene nada que ver uno con otro. Gracias, Víctor. Gracias, Juanjo. A ti sí que te pago una sorpresa. Bueno, no hay más preguntas. Bueno, Juanjo, al final llegamos en tiempo. Sí, sí, gracias a todos. Vale, gracias a todos. Un regalito de parte de la organización.