🚀 ¡Lanzada la nueva versión 0.8 de Gato GraphQL!
¡La versión 0.8 de Gato GraphQL ya está disponible para descargar! 🎉
Esta es una release enorme, que se centra en tres áreas:
- Refactorizar el código base para habilitar extensiones
- Satisfacer aún más la especificación de GraphQL
- Completar el esquema GraphQL
Además, soporta el nuevo WordPress 5.8, y contiene muchos bug fixes y mejoras.
¡Ten en cuenta que esta release contiene breaking changes!
Abajo están las notas de la release. Enlaces rápidos:
- Soporte para WordPress 5.8
- Soporte mejorado para PHP 8.0
- Código base simplificado, usando container services en todas partes
- La caché se guarda bajo
wp-content - Se introdujo un endpoint GraphQL de "esquema fijo" para potenciar el editor de WordPress
- Mayor soporte de tipos de campo en el esquema
- Input coercion: aceptar un valor único cuando se espera una lista
- Se completó aún más el esquema de WordPress
- Añadidos campos admin "unrestricted" al esquema GraphQL
- Introducido el tipo escalar
AnyScalar - Settings en formato largo
- Breaking changes
- Próximo Roadmap
- ¿Encontraste problemas?
Soporte para WordPress 5.8
WordPress 5.8 deprecia varios filter hooks, incluyendo allowed_block_types y block_categories (usados por este plugin).
Los hooks afectados se han reemplazado:
allowed_block_types=>allowed_block_types_allblock_categories=>block_categories_all
Soporte mejorado para PHP 8.0
Esta release arregla algunos problemas al usar PHP 8.0.
Código base simplificado, usando container services en todas partes
El código base del servidor GraphQL ha sido refactorizado, para usar un service container para registrar todos los elementos del esquema (type resolvers, field resolvers, interface resolvers, custom scalar resolvers, y otros).
Este es un hito, que introduce un único enfoque para desarrollar el plugin y sus extensiones, simplificando enormemente su código y documentación.
Por fin se puede escribir documentación sobre cómo crear extensiones personalizadas para Gato GraphQL. El trabajo sobre ellas comenzará pronto, y se publicará en la sección de guías.
La caché se guarda bajo wp-content
El plugin cachea resultados a disco para optimizar el rendimiento.
Los ficheros cacheados se almacenaban previamente bajo una carpeta del sistema, fuera de la vista del usuario admin. A partir de ahora, se almacenan bajo wp-content/graphql-api/cache/.
Se introdujo un endpoint GraphQL de "esquema fijo" para potenciar el editor de WordPress
Ahora, hay 2 endpoints en el wp-admin:
GRAPHQL_API_ADMIN_CONFIGURABLESCHEMA_ENDPOINTGRAPHQL_API_ADMIN_FIXEDSCHEMA_ENDPOINT
Con GRAPHQL_API_ADMIN_CONFIGURABLESCHEMA_ENDPOINT, el esquema GraphQL se modifica según las preferencias del usuario, como estar bajo namespace o no, tener tipos/directivas habilitadas o no, y otros.
Con GRAPHQL_API_ADMIN_FIXEDSCHEMA_ENDPOINT, el esquema GraphQL no se modifica según las preferencias del usuario, exponiendo siempre todos los tipos, campos y directivas, incluyendo los campos admin "unrestricted".
El endpoint fijo permite a los bloques Gutenberg consultar todos los campos, independientemente de que estos estén habilitados o no por el usuario, y con acceso sin restricciones.
Mayor soporte de tipos de campo en el esquema
El soporte para listas como tipos de campo se ha expandido, soportando ahora las siguientes características:
- Listas con elementos non-null:
[String!] - Listas de listas:
[[String]] - Cualquier combinación de ellas:
[[String!]!]
Input coercion: aceptar un valor único cuando se espera una lista
Ahora podemos introducir un valor único en la consulta GraphQL donde se espera una lista, como se define en la spec de GraphQL.
Por ejemplo, estas consultas son ahora equivalentes:
query InputSingleValue {
posts(filter: { ids: 1 }) {
title
}
}
query InputListOfSingleItem {
posts(filter: { ids: [1] }) {
title
}
}Se completó aún más el esquema de WordPress
Se han añadido al esquema GraphQL entidades adicionales del modelo de datos de WordPress:
Veamos qué nuevos elementos se han añadido.
Categorías
Las categorías han sido mapeadas, vía el nuevo tipo PostCategory, y los nuevos campos:
Root.postCategories: [PostCategory]Root.postCategory: PostCategoryPost.categories: [PostCategory]
Por ejemplo, esta consulta recupera las categorías de las entradas:
{
posts {
id
title
categories {
id
name
url
}
}
}También se ha añadido un campo mutation, para asignar categorías a entradas:
MutationRoot.setCategoriesOnPost: Post
Y se ha añadido una entrada categories a los campos mutation para entradas:
MutationRoot.createPostMutationRoot.updatePostPost.update(cuando las nested mutations están habilitadas)
Meta
Ya pueden consultarse los valores meta de custom post, usuario, comentario y taxonomía, vía los nuevos campos:
Post.metaValue: AnyScalarPost.metaValues: [AnyScalar]User.metaValue: AnyScalarUser.metaValues: [AnyScalar]Comment.metaValue: AnyScalarComment.metaValues: [AnyScalar]PostCategory.metaValue: AnyScalarPostCategory.metaValues: [AnyScalar]PostTag.metaValue: AnyScalarPostTag.metaValues: [AnyScalar]
Por ejemplo, esta consulta recupera el meta last_name para los usuarios:
{
users {
id
lastName: metaValue(key: "last_name")
}
}Como los valores meta pueden ser cualquier cosa (string, integer, float, o boolean) se han mapeado vía el nuevo tipo escalar genérico AnyScalar.
Los valores meta pueden ser públicos o privados. Qué meta keys pueden consultarse debe configurarse explícitamente en la página de ajustes:
Por defecto, la lista de meta keys permitidas está vacía.
Menús
Los menús han sido mapeados, vía el nuevo tipo Menu, y el nuevo campo Root.menu.
{
menu(by: { id: 176 }) {
itemDataEntries
}
}Settings
Los settings del sitio (almacenados en la tabla wp_options) pueden consultarse vía el nuevo campo Root.option: AnyScalar.
Por ejemplo, esta consulta recupera el nombre del sitio:
{
siteName: optionValue(name: "blogname")
}Qué opciones pueden ser accedidas debe configurarse explícitamente en la página de ajustes:
Por defecto, solo pueden consultarse las siguientes opciones:
"home""blogname""blogdescription"
User posts
Los usuarios logueados pueden recuperar sus propias entradas, para cualquier estado (publish, pending, draft o trash), vía los nuevos campos:
Root.myPosts: [Post]Root.myPostCount: IntRoot.myPost: Post
Por ejemplo, ahora podemos ejecutar esta consulta:
# Log yourself in first
mutation LogIn {
loginUser(usernameOrEmail: "test", password: "pass") {
id
name
}
}
# Then retrieve your posts
query GetMyPosts {
myPosts {
id
title
url
status
author {
name
}
}
}Añadidos campos admin "unrestricted" al esquema GraphQL
El esquema GraphQL debe encontrar un equilibrio entre campos públicos y privados, para evitar exponer información privada en una API pública.
El nuevo módulo Schema for the Admin añade campos admin "unrestricted" al esquema GraphQL, que pueden exponer datos privados:
Root:
unrestrictedPostunrestrictedPostsunrestrictedPostCountunrestrictedCustomPostunrestrictedCustomPostsunrestrictedCustomPostCountunrestrictedGenericCustomPostunrestrictedGenericCustomPostsunrestrictedGenericCustomPostCountunrestrictedPageunrestrictedPagesunrestrictedPageCountunrestrictedUsersrolescapabilities
User:
unrestrictedPostsunrestrictedPostCountunrestrictedCustomPostsunrestrictedCustomPostCountrolescapabilities
PostCategory:
unrestrictedPostsunrestrictedPostCount
PostTag:
unrestrictedPostsunrestrictedPostCount
Por ejemplo, para acceder a datos de entrada, actualmente tenemos el campo posts, que expone solo datos públicos, obteniendo entradas publicadas.
A partir de ahora, también podemos acceder a datos de entrada vía el campo unrestrictedPosts, que expone datos públicos y privados, obteniendo entradas con cualquier estado ("publish", "draft", "pending", "trash").
{
unrestrictedPosts(status: [draft, pending]) {
id
title
status
author {
id
name
}
}
}Introducido el tipo escalar AnyScalar
El tipo escalar AnyScalar representa cualquiera de los escalares integrados (String, Int, Boolean, Float o ID).
Se usa en los campos recién introducidos option y metaValue(s), porque no sabemos de antemano el tipo de sus datos devueltos, y la unión de tipos escalares aún no está soportada por la spec de GraphQL.
Settings en formato largo
Las opciones en la página de Settings están divididas por pestañas. Desde v0.8 también es posible visualizarlas todas juntas en una única página larga.
Para habilitar este comportamiento, desmarca el elemento "Have all options in this Settings page be organized under tabs, one tab per module." en los Settings, y pulsa "Save Changes":
Entonces, todos los settings se mostrarán juntos en formato largo:
Breaking changes
La release v0.8 produce breaking changes con la versión anterior.
Configuration breaking changes
Los siguientes CPTs han tenido su bloque "Options" reconstruido:
- Schema Configurations
- Custom Endpoints
- Persisted Queries
En la anterior v0.7, un único bloque Options para estas entidades contenía muchos elementos de configuración. Desde v0.8, este bloque se ha desacoplado en varios bloques independientes, cada uno conteniendo su propia configuración.
Por ejemplo, en v0.7, (además de habilitar/deshabilitar el endpoint) el bloque Custom Endpoint Options permitía configurar los clientes GraphiQL e Interactive Schema:
Desde v0.8, esta configuración se añade a través de los bloques GraphiQL e Interactive Schema:
La configuración almacenada en los bloques Options para los 3 CPTs no se migra automáticamente al nuevo formato. Por tanto, antes de actualizar a v0.8, por favor anota tu configuración almacenada, y replícala después de actualizar a la nueva versión.
Sentimos las molestias.
Además, necesitarás hacer clic en el botón "Reset the template" mostrado en el editor de WordPress, para todas las entradas para los 3 CPTs.
Directivas no estándar eliminadas
Las directivas no estándar se han eliminado del plugin:
@default@removeIfNull@export
Módulos eliminados
Los siguientes módulos se han eliminado del plugin:
- Field Deprecation
- Configuration Cache
- Schema Cache
- Multiple Query Execution
- Proactive Feedback
- Schema Editing Access
- Embeddable fields
Próximo Roadmap
Ahora que v0.8 ha sido lanzado, podemos empezar a planear el camino por delante.
El plan actual es el siguiente:
Lanzar v0.9 en septiembre de 2021, incluyendo:
- Custom scalars
- Un esquema GraphQL actualizado, usando custom scalars cuando sea apropiado (ej:
Post.datedevolverá el tipoDateen lugar deString) - Mejoras adicionales para soportar extensiones
Y luego, lanzar v1.0 cerca de fin de año o principios de 2022, incluyendo:
- Una demo de un plugin de extensión
- Guías de documentación completas sobre crear extensiones
- Lanzamiento del plugin Gato GraphQL en
wp.org
Para recibir notificaciones sobre el estado actual, puedes suscribirte al newsletter.
¿Encontraste problemas?
Si tienes cualquier problema instalando o ejecutando v0.8, por favor crea un issue en el repo.