🚀 Lancement de la nouvelle version 0.8 de Gato GraphQL !

La version 0.8 de Gato GraphQL est désormais disponible en téléchargement ! 🎉

Il s'agit d'une version majeure, qui se concentre sur trois domaines :

1. Refactorisation de la base de code pour activer les extensions
2. Meilleure conformité à la spécification GraphQL
3. Complétion du schéma GraphQL

De plus, elle supporte le nouveau WordPress 5.8, et contient de nombreuses corrections de bugs et améliorations.

Veuillez noter que cette version contient des changements non rétrocompatibles !

Voici les notes de version. Liens rapides :

• Support pour WordPress 5.8
• Support amélioré pour PHP 8.0
• Base de code simplifiée, utilisant des container services partout
• Le cache est enregistré sous wp-content
• Un endpoint GraphQL à "schéma fixe" a été introduit pour alimenter l'éditeur WordPress
• Support supplémentaire des types de champs dans le schéma
• Input coercion : accepter une valeur unique lorsqu'une liste est attendue
• Schéma WordPress davantage complété
  • Catégories
  • Meta
  • Menus
  • Settings
  • User posts
• Ajout de champs admin "unrestricted" au schéma GraphQL
• Introduction du type scalaire AnyScalar
• Settings en format long
• Changements non rétrocompatibles
  • Changements non rétrocompatibles de configuration
  • Directives non standard supprimées
  • Modules supprimés
• Feuille de route à venir
• Vous avez rencontré des problèmes ?

​

Support pour WordPress 5.8

WordPress 5.8 déprécie plusieurs filter hooks, notamment allowed_block_types et block_categories (utilisés par ce plugin).

Les hooks concernés ont été remplacés :

1. allowed_block_types => allowed_block_types_all
2. block_categories => block_categories_all

​

Support amélioré pour PHP 8.0

Cette version corrige quelques problèmes lors de l'utilisation de PHP 8.0.

​

Base de code simplifiée, utilisant des container services partout

La base de code du serveur GraphQL a été refactorisée pour utiliser un service container pour enregistrer tous les éléments du schéma (type resolvers, field resolvers, interface resolvers, custom scalar resolvers, et autres).

Il s'agit d'une étape majeure, qui introduit une approche unique pour développer le plugin et ses extensions, simplifiant grandement leur code et leur documentation.

La documentation sur la création d'extensions personnalisées pour Gato GraphQL peut enfin être rédigée. Le travail à ce sujet démarrera prochainement et sera publié dans la section guides.

​

Le cache est enregistré sous wp-content

Le plugin met en cache les résultats sur disque pour optimiser les performances.

Les fichiers mis en cache étaient précédemment stockés dans un dossier système, hors de portée de l'administrateur. Désormais, ils sont stockés sous wp-content/graphql-api/cache/.

​

Un endpoint GraphQL à "schéma fixe" a été introduit pour alimenter l'éditeur WordPress

Maintenant, il y a 2 endpoints dans le wp-admin :

1. GRAPHQL_API_ADMIN_CONFIGURABLESCHEMA_ENDPOINT
2. GRAPHQL_API_ADMIN_FIXEDSCHEMA_ENDPOINT

Avec GRAPHQL_API_ADMIN_CONFIGURABLESCHEMA_ENDPOINT, le schéma GraphQL est modifié par les préférences de l'utilisateur, comme être sous namespace ou non, avoir des types/directives activés ou non, et autres.

Avec GRAPHQL_API_ADMIN_FIXEDSCHEMA_ENDPOINT, le schéma GraphQL n'est pas modifié par les préférences de l'utilisateur, exposant toujours tous les types, champs et directives, y compris les champs admin "unrestricted".

L'endpoint fixe permet aux blocs Gutenberg d'interroger tous les champs, indépendamment du fait qu'ils soient activés ou non par l'utilisateur, et avec un accès sans restriction.

​

Support supplémentaire des types de champs dans le schéma

Le support des listes en tant que types de champs a été étendu, prenant désormais en charge les fonctionnalités suivantes :

• Listes avec des éléments non nuls : [String!]
• Listes de listes : [[String]]
• Toute combinaison : [[String!]!]

​

Input coercion : accepter une valeur unique lorsqu'une liste est attendue

Nous pouvons maintenant saisir une seule valeur dans la requête GraphQL là où une liste est attendue, comme défini dans la spécification GraphQL.

Par exemple, ces requêtes sont maintenant équivalentes :

query InputSingleValue {
  posts(filter: { ids: 1 }) {
    title
  }
}
 
query InputListOfSingleItem {
  posts(filter: { ids: [1] }) {
    title
  }
}Copy

​

Schéma WordPress davantage complété

Des entités supplémentaires du modèle de données WordPress ont été ajoutées au schéma GraphQL :

Voyons quels nouveaux éléments ont été ajoutés.

​

Catégories

Les catégories ont été mappées, via le nouveau type PostCategory, et les nouveaux champs :

• Root.postCategories: [PostCategory]
• Root.postCategory: PostCategory
• Post.categories: [PostCategory]

Par exemple, cette requête récupère les catégories des publications :

{
  posts {
    id
    title
    categories {
      id
      name
      url
    }
  }
}Copy

Un champ mutation, pour assigner des catégories aux publications, a également été ajouté :

• MutationRoot.setCategoriesOnPost: Post

Et une entrée categories a été ajoutée aux champs mutation pour les publications :

• MutationRoot.createPost
• MutationRoot.updatePost
• Post.update (lorsque les nested mutations sont activées)

​

Meta

Les valeurs meta des custom post, utilisateur, commentaire et taxonomie peuvent désormais être interrogées, via les nouveaux champs :

• Post.metaValue: AnyScalar
• Post.metaValues: [AnyScalar]
• User.metaValue: AnyScalar
• User.metaValues: [AnyScalar]
• Comment.metaValue: AnyScalar
• Comment.metaValues: [AnyScalar]
• PostCategory.metaValue: AnyScalar
• PostCategory.metaValues: [AnyScalar]
• PostTag.metaValue: AnyScalar
• PostTag.metaValues: [AnyScalar]

Par exemple, cette requête récupère le meta last_name pour les utilisateurs :

{
  users {
    id
    lastName: metaValue(key: "last_name")
  }
}Copy

Comme les valeurs meta peuvent être n'importe quoi (string, integer, float, ou boolean), elles ont été mappées via le nouveau type scalaire générique AnyScalar.

Les valeurs meta peuvent être publiques ou privées. Les meta keys pouvant être interrogées doivent être configurées explicitement sur la page de paramètres :

Par défaut, la liste des meta keys autorisées est vide.

​

Menus

Les menus ont été mappés, via le nouveau type Menu, et le nouveau champ Root.menu.

{
  menu(by: { id: 176 }) {
    itemDataEntries
  }
}Copy

​

Settings

Les paramètres du site (stockés dans la table wp_options) peuvent être interrogés via le nouveau champ Root.option: AnyScalar.

Par exemple, cette requête récupère le nom du site :

{
  siteName: optionValue(name: "blogname")
}Copy

Les options accessibles doivent être configurées explicitement sur la page de paramètres :

Par défaut, seules les options suivantes peuvent être interrogées :

• "home"
• "blogname"
• "blogdescription"

​

User posts

Les utilisateurs connectés peuvent récupérer leurs propres publications, pour n'importe quel statut (publish, pending, draft ou trash), via les nouveaux champs :

• Root.myPosts: [Post]
• Root.myPostCount: Int
• Root.myPost: Post

Par exemple, nous pouvons maintenant exécuter cette requête :

# 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
    }
  }
}Copy

​

Ajout de champs admin "unrestricted" au schéma GraphQL

Le schéma GraphQL doit trouver un équilibre entre champs publics et privés, afin d'éviter d'exposer des informations privées dans une API publique.

Le nouveau module Schema for the Admin ajoute des champs admin "unrestricted" au schéma GraphQL, qui peuvent exposer des données privées :

Root :

• unrestrictedPost
• unrestrictedPosts
• unrestrictedPostCount
• unrestrictedCustomPost
• unrestrictedCustomPosts
• unrestrictedCustomPostCount
• unrestrictedGenericCustomPost
• unrestrictedGenericCustomPosts
• unrestrictedGenericCustomPostCount
• unrestrictedPage
• unrestrictedPages
• unrestrictedPageCount
• unrestrictedUsers
• roles
• capabilities

User :

• unrestrictedPosts
• unrestrictedPostCount
• unrestrictedCustomPosts
• unrestrictedCustomPostCount
• roles
• capabilities

PostCategory :

• unrestrictedPosts
• unrestrictedPostCount

PostTag :

• unrestrictedPosts
• unrestrictedPostCount

Par exemple, pour accéder aux données de publication, nous avons actuellement le champ posts, qui expose uniquement les données publiques, en récupérant les publications publiées.

Désormais, nous pouvons également accéder aux données de publication via le champ unrestrictedPosts, qui expose les données publiques et privées, en récupérant des publications avec n'importe quel statut ("publish", "draft", "pending", "trash").

{
  unrestrictedPosts(status: [draft, pending]) {
    id
    title
    status
    author {
      id
      name
    }
  }
}Copy

​

Introduction du type scalaire AnyScalar

Le type scalaire AnyScalar représente n'importe lequel des scalaires intégrés (String, Int, Boolean, Float ou ID).

Il est utilisé sur les champs option et metaValue(s) récemment introduits, car nous ne connaissons pas à l'avance le type de leurs données retournées, et l'union des types scalaires n'est pas encore supportée par la spécification GraphQL.

​

Settings en format long

Les options de la page Settings sont divisées par onglets. Depuis v0.8, il est également possible de les visualiser toutes ensemble dans une seule page longue.

Pour activer ce comportement, décochez l'élément "Have all options in this Settings page be organized under tabs, one tab per module." dans les Settings, et appuyez sur "Save Changes" :

Ensuite, tous les paramètres seront affichés ensemble en format long :

​

Changements non rétrocompatibles

La version v0.8 produit des changements non rétrocompatibles avec la version précédente.

​

Changements non rétrocompatibles de configuration

Les CPTs suivants ont eu leur bloc "Options" reconstruit :

• Schema Configurations
• Custom Endpoints
• Persisted Queries

Dans la précédente v0.7, un seul bloc Options pour ces entités contenait de nombreux éléments de configuration. Depuis v0.8, ce bloc a été découplé en plusieurs blocs indépendants, chacun contenant sa propre configuration.

Par exemple, dans v0.7, (en plus d'activer/désactiver l'endpoint) le bloc Custom Endpoint Options permettait de configurer les clients GraphiQL et Interactive Schema :

Depuis v0.8, cette configuration est ajoutée via les blocs GraphiQL et Interactive Schema :

La configuration stockée dans les blocs Options pour les 3 CPTs n'est pas automatiquement migrée vers le nouveau format. Par conséquent, avant de mettre à jour vers v0.8, veuillez noter votre configuration stockée, et la répliquer après la mise à jour vers la nouvelle version.

Nous nous excusons pour ce désagrément.

De plus, vous devrez cliquer sur le bouton "Reset the template" affiché dans l'éditeur WordPress, pour toutes les entrées des 3 CPTs.

​

Directives non standard supprimées

Les directives non standard ont été supprimées du plugin :

• @default
• @removeIfNull
• @export

​

Modules supprimés

Les modules suivants ont été supprimés du plugin :

• Field Deprecation
• Configuration Cache
• Schema Cache
• Multiple Query Execution
• Proactive Feedback
• Schema Editing Access
• Embeddable fields

​

Feuille de route à venir

Maintenant que v0.8 a été lancée, nous pouvons commencer à planifier la route à suivre.

Le plan actuel est le suivant :

Lancer v0.9 en septembre 2021, incluant :

• Custom scalars
• Un schéma GraphQL mis à jour, utilisant des custom scalars lorsque c'est approprié (ex : Post.date retournera le type Date au lieu de String)
• Améliorations supplémentaires pour supporter les extensions

Puis, lancer v1.0 vers la fin d'année ou début 2022, incluant :

• Une démo d'un plugin d'extension
• Des guides de documentation complets sur la création d'extensions
• Lancement du plugin Gato GraphQL sur wp.org

Pour recevoir des notifications sur l'état actuel, vous pouvez vous abonner à la newsletter.

​

Vous avez rencontré des problèmes ?

Si vous avez un problème pour installer ou exécuter v0.8, veuillez créer un issue dans le dépôt.