Logo
Blog

🚀 Neue Version 0.8 von Gato GraphQL veröffentlicht!

Leonardo Losoviz
Von Leonardo Losoviz ·

Version 0.8 von Gato GraphQL ist jetzt zum Download verfügbar! 🎉

Das ist ein großes Release, das sich auf drei Bereiche konzentriert:

  1. Refactoring des Codes zur Aktivierung von Erweiterungen
  2. Weitere Konformität mit der GraphQL-Spezifikation
  3. Vervollständigung des GraphQL-Schemas

Außerdem unterstützt es das neue WordPress 5.8 und enthält zahlreiche Fehlerbehebungen und Verbesserungen.

Bitte beachte, dass dieses Release Breaking Changes enthält!

Im Folgenden die Release Notes. Quicklinks:

Unterstützung für WordPress 5.8

WordPress 5.8 deprecates mehrere Filter-Hooks, darunter allowed_block_types und block_categories (die von diesem Plugin verwendet werden).

Die betroffenen Hooks wurden ersetzt:

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

Verbesserte Unterstützung für PHP 8.0

Dieses Release behebt einige Probleme bei der Verwendung von PHP 8.0.

Vereinfachter Code durch durchgängige Verwendung von Container Services

Der Code des GraphQL-Servers wurde refaktorisiert, um einen Service Container zur Registrierung aller Schema-Elemente zu verwenden (type resolvers, field resolvers, interface resolvers, custom scalar resolvers und andere).

Das ist ein Meilenstein, der einen einheitlichen Ansatz für die Entwicklung des Plugins und seiner Erweiterungen einführt und deren Code und Dokumentation erheblich vereinfacht.

Die Dokumentation zur Erstellung benutzerdefinierter Erweiterungen für Gato GraphQL kann endlich geschrieben werden. Die Arbeit daran beginnt bald und wird im Bereich Anleitungen veröffentlicht.

Cache wird unter wp-content gespeichert

Das Plugin speichert Ergebnisse auf der Festplatte zwischen, um die Performance zu optimieren.

Die zwischengespeicherten Dateien wurden bisher in einem Systemordner gespeichert, der für den Admin-Benutzer nicht sichtbar war. Ab sofort werden sie unter wp-content/graphql-api/cache/ gespeichert.

Ein GraphQL-Endpoint mit "festem Schema" wurde eingeführt, um den WordPress-Editor zu unterstützen

Jetzt gibt es 2 Endpoints im wp-admin:

  1. GRAPHQL_API_ADMIN_CONFIGURABLESCHEMA_ENDPOINT
  2. GRAPHQL_API_ADMIN_FIXEDSCHEMA_ENDPOINT

Mit GRAPHQL_API_ADMIN_CONFIGURABLESCHEMA_ENDPOINT wird das GraphQL-Schema durch Benutzereinstellungen geändert, z. B. ob es unter einem Namespace steht oder nicht, ob Typen/Direktiven aktiviert sind oder nicht, und anderes.

Mit GRAPHQL_API_ADMIN_FIXEDSCHEMA_ENDPOINT wird das GraphQL-Schema nicht durch Benutzereinstellungen geändert und zeigt immer alle Typen, Felder und Direktiven an, einschließlich der „unrestricted" Admin-Felder.

Der feste Endpoint ermöglicht es Gutenberg-Blöcken, alle Felder abzufragen, unabhängig davon, ob sie vom Benutzer aktiviert sind oder nicht, und mit uneingeschränktem Zugriff.

Weitere Unterstützung von Feldtypen im Schema

Die Unterstützung für Listen als Feldtypen wurde erweitert und unterstützt nun folgende Funktionen:

  • Listen mit nicht-null-Elementen: [String!]
  • Listen von Listen: [[String]]
  • Beliebige Kombinationen davon: [[String!]!]

Input coercion: einen einzelnen Wert akzeptieren, wenn eine Liste erwartet wird

Wir können jetzt einen einzelnen Wert in der GraphQL-Abfrage eingeben, wo eine Liste erwartet wird, wie in der GraphQL-Spezifikation definiert.

Zum Beispiel sind diese queries jetzt gleichwertig:

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

WordPress-Schema weiter vervollständigt

Weitere Entitäten aus dem WordPress-Datenmodell wurden zum GraphQL-Schema hinzugefügt:

GraphQL schema

Schauen wir uns an, welche neuen Elemente hinzugefügt wurden.

Kategorien

Kategorien wurden über den neuen Typ PostCategory und die neuen Felder abgebildet:

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

Zum Beispiel ruft diese query die Kategorien der Posts ab:

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

Es wurde auch ein Mutation-Feld hinzugefügt, um Posts Kategorien zuzuweisen:

  • MutationRoot.setCategoriesOnPost: Post

Und ein Input categories wurde den Mutation-Feldern für Posts hinzugefügt:

  • MutationRoot.createPost
  • MutationRoot.updatePost
  • Post.update (wenn nested mutations aktiviert sind)

Meta

Custom Post-, Benutzer-, Kommentar- und Taxonomie-Meta-Werte können jetzt über die neuen Felder abgefragt werden:

  • 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]

Zum Beispiel ruft diese query den Meta-Wert last_name für die Benutzer ab:

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

Da Meta-Werte beliebig sein können (string, integer, float oder boolean), wurden sie über den neu eingeführten generischen skalaren Typ AnyScalar abgebildet.

Meta-Werte können öffentlich oder privat sein. Welche Meta-Keys abgefragt werden können, muss explizit auf der Einstellungsseite konfiguriert werden:

Definition der Einträge
Definition der Einträge

Standardmäßig ist die Liste der erlaubten Meta-Keys leer.

Menüs wurden über den neuen Typ Menu und das neue Feld Root.menu abgebildet.

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

Settings

Die Einstellungen der Website (in der Tabelle wp_options gespeichert) können über das neue Feld Root.option: AnyScalar abgefragt werden.

Zum Beispiel ruft diese query den Namen der Website ab:

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

Welche Optionen zugänglich sind, muss explizit auf der Einstellungsseite konfiguriert werden:

Definition der Einträge für die Settings

Standardmäßig können nur folgende Optionen abgefragt werden:

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

User posts

Eingeloggte Benutzer können ihre eigenen Posts für jeden Status (publish, pending, draft oder trash) über die neuen Felder abrufen:

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

Zum Beispiel können wir jetzt diese query ausführen:

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

„Unrestricted" Admin-Felder zum GraphQL-Schema hinzugefügt

Das GraphQL-Schema muss eine Balance zwischen öffentlichen und privaten Feldern finden, um zu vermeiden, private Informationen in einer öffentlichen API preiszugeben.

Das neue Modul Schema for the Admin fügt „unrestricted" Admin-Felder zum GraphQL-Schema hinzu, die private Daten offenlegen können:

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

Um zum Beispiel auf Post-Daten zuzugreifen, haben wir aktuell das Feld posts, das nur öffentliche Daten zeigt, indem es veröffentlichte Posts abruft.

Ab sofort können wir auf Post-Daten auch über das Feld unrestrictedPosts zugreifen, das öffentliche und private Daten zeigt, indem es Posts mit beliebigem Status abruft ("publish", "draft", "pending", "trash").

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

Einführung des skalaren Typs AnyScalar

Der skalare Typ AnyScalar repräsentiert einen der eingebauten Skalare (String, Int, Boolean, Float oder ID).

Er wird in den neu eingeführten Feldern option und metaValue(s) verwendet, weil wir den Typ der zurückgegebenen Daten im Voraus nicht kennen und die Union von skalaren Typen noch nicht von der GraphQL-Spezifikation unterstützt wird.

Settings im Langformat

Die Optionen auf der Settings-Seite sind in Tabs aufgeteilt. Ab v0.8 ist es auch möglich, sie alle gemeinsam auf einer einzigen langen Seite anzuzeigen.

Um dieses Verhalten zu aktivieren, deaktiviere das Element "Have all options in this Settings page be organized under tabs, one tab per module." in den Settings und klicke auf "Save Changes":

Checkbox zum Aktivieren/Deaktivieren von Tabs in den Settings

Dann werden alle Einstellungen zusammen im Langformat angezeigt:

Settings im Langformat

Breaking Changes

Das Release v0.8 erzeugt Breaking Changes gegenüber der vorherigen Version.

Konfigurationsbezogene Breaking Changes

Bei den folgenden CPTs wurde ihr „Options"-Block neu aufgebaut:

  • Schema Configurations
  • Custom Endpoints
  • Persisted Queries

In der vorherigen v0.7 enthielt ein einziger Options-Block für diese Entitäten viele Konfigurationselemente. Ab v0.8 wurde dieser Block in mehrere unabhängige Blöcke aufgeteilt, von denen jeder seine eigene Konfiguration enthält.

Zum Beispiel erlaubte in v0.7 (zusätzlich zur Aktivierung/Deaktivierung des Endpoints) der Custom Endpoint Options-Block die Konfiguration der GraphiQL- und Interactive Schema-Clients:

Options in Custom Endpoint

Ab v0.8 wird diese Konfiguration über die GraphiQL- und Interactive Schema-Blöcke hinzugefügt:

Options in Custom Endpoint

Die in den Options-Blöcken aller 3 CPTs gespeicherte Konfiguration wird nicht automatisch in das neue Format migriert. Bitte notiere daher vor dem Upgrade auf v0.8 deine gespeicherte Konfiguration und repliziere sie nach dem Upgrade auf die neue Version.

Wir entschuldigen uns für diese Unannehmlichkeit.

Außerdem musst du für alle Einträge der 3 CPTs auf den Button "Reset the template" klicken, der im WordPress-Editor angezeigt wird.

Reset the template im WordPress-Editor

Nicht-standardmäßige Direktiven entfernt

Die nicht-standardmäßigen Direktiven wurden aus dem Plugin entfernt:

  • @default
  • @removeIfNull
  • @export

Module entfernt

Die folgenden Module wurden aus dem Plugin entfernt:

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

Kommende Roadmap

Jetzt, da v0.8 veröffentlicht wurde, können wir beginnen, den weiteren Weg zu planen.

Der aktuelle Plan ist folgender:

v0.9 im September 2021 veröffentlichen, einschließlich:

  • Custom scalars
  • Ein aktualisiertes GraphQL-Schema, das custom scalars wo immer sinnvoll verwendet (z. B. wird Post.date den Typ Date statt String zurückgeben)
  • Weitere Verbesserungen zur Unterstützung von Erweiterungen

Und dann v1.0 gegen Ende des Jahres oder Anfang 2022 veröffentlichen, einschließlich:

  • Eine Demo eines Erweiterungs-Plugins
  • Vollständige Dokumentations-Anleitungen zur Erstellung von Erweiterungen
  • Launch des Gato GraphQL-Plugins auf wp.org

Um Benachrichtigungen über den aktuellen Stand zu erhalten, kannst du den Newsletter abonnieren.

Probleme aufgetreten?

Wenn du Probleme bei der Installation oder Ausführung von v0.8 hast, erstelle bitte ein Issue im Repository.

Zurück zu allen Beiträgen

Abonniere unseren Newsletter

Bleib über alle Updates zu Gato GraphQL auf dem Laufenden.