Logo
Blog

🚀 Wydana nowa wersja 0.8 Gato GraphQL!

Leonardo Losoviz
Autor: Leonardo Losoviz ·

Wersja 0.8 Gato GraphQL jest teraz dostępna do pobrania! 🎉

To ogromne wydanie, skupiające się na trzech obszarach:

  1. Refaktoryzacja kodu w celu umożliwienia rozszerzeń
  2. Lepsze spełnianie specyfikacji GraphQL
  3. Uzupełnienie schematu GraphQL

Ponadto obsługuje nowy WordPress 5.8 i zawiera wiele poprawek błędów oraz ulepszeń.

Należy pamiętać, że to wydanie zawiera breaking changes!

Poniżej znajdują się informacje o wydaniu. Szybkie linki:

Wsparcie dla WordPress 5.8

WordPress 5.8 oznaczył kilka filter hooks jako przestarzałe, w tym allowed_block_types i block_categories (używane przez ten plugin).

Zmienione hooks zostały zastąpione:

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

Ulepszone wsparcie dla PHP 8.0

To wydanie naprawia kilka problemów przy korzystaniu z PHP 8.0.

Uproszczony kod, z użyciem container services wszędzie

Kod serwera GraphQL został zrefaktoryzowany, aby używać kontenera usług do rejestrowania wszystkich elementów schematu (type resolvers, field resolvers, interface resolvers, custom scalar resolvers i innych).

To jest kamień milowy, który wprowadza jednolite podejście do rozwijania pluginu i jego rozszerzeń, znacznie upraszczając ich kod i dokumentację.

Dokumentacja dotycząca tworzenia niestandardowych rozszerzeń dla Gato GraphQL może być wreszcie napisana. Prace nad nią rozpoczną się wkrótce i zostaną opublikowane w sekcji przewodników.

Cache jest zapisywany w wp-content

Plugin przechowuje wyniki w cache na dysku, aby zoptymalizować wydajność.

Pliki cache były wcześniej przechowywane w folderze systemowym, poza zasięgiem użytkownika administratora. Od teraz są przechowywane w wp-content/graphql-api/cache/.

Wprowadzono endpoint GraphQL ze "stałym schematem" do obsługi edytora WordPress

Teraz w wp-admin dostępne są 2 endpointy:

  1. GRAPHQL_API_ADMIN_CONFIGURABLESCHEMA_ENDPOINT
  2. GRAPHQL_API_ADMIN_FIXEDSCHEMA_ENDPOINT

W przypadku GRAPHQL_API_ADMIN_CONFIGURABLESCHEMA_ENDPOINT schemat GraphQL jest modyfikowany przez preferencje użytkownika, takie jak stosowanie przestrzeni nazw lub nie, włączanie lub wyłączanie typów/dyrektyw i inne.

W przypadku GRAPHQL_API_ADMIN_FIXEDSCHEMA_ENDPOINT schemat GraphQL nie jest modyfikowany przez preferencje użytkownika, zawsze ujawniając wszystkie typy, pola i dyrektywy, w tym "unrestricted" pola admin.

Stały endpoint umożliwia blokom Gutenberg odpytywanie wszystkich pól, niezależnie od tego, czy są włączone przez użytkownika, oraz z nieograniczonym dostępem.

Dalsze wsparcie typów pól w schemacie

Wsparcie dla list jako typów pól zostało rozszerzone, teraz obsługując następujące funkcje:

  • Listy z elementami non-null: [String!]
  • Listy list: [[String]]
  • Dowolna ich kombinacja: [[String!]!]

Input coercion: akceptowanie pojedynczej wartości gdy oczekiwana jest lista

Teraz możemy podać pojedynczą wartość w query GraphQL tam, gdzie oczekiwana jest lista, zgodnie z definicją w specyfikacji GraphQL.

Na przykład, te queries są teraz równoważne:

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

Dalsze uzupełnienie schematu WordPress

Dodatkowe encje z modelu danych WordPress zostały dodane do schematu GraphQL:

Schemat GraphQL

Zobaczmy, jakie nowe elementy zostały dodane.

Kategorie

Kategorie zostały zmapowane za pomocą nowego typu PostCategory i nowych pól:

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

Na przykład, ta query pobiera kategorie dla postów:

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

Dodano również pole mutation do przypisywania kategorii do postów:

  • MutationRoot.setCategoriesOnPost: Post

Oraz input categories został dodany do pól mutation dla postów:

  • MutationRoot.createPost
  • MutationRoot.updatePost
  • Post.update (gdy nested mutations są włączone)

Meta

Wartości meta custom post, użytkownika, komentarza i taksonomii mogą być teraz odpytywane za pomocą nowych pól:

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

Na przykład, ta query pobiera meta last_name dla użytkowników:

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

Ponieważ wartości meta mogą być czymkolwiek (string, integer, float lub boolean), zostały zmapowane za pomocą nowo wprowadzonego generycznego typu skalarnego AnyScalar.

Wartości meta mogą być publiczne lub prywatne. Które klucze meta mogą być odpytywane, musi być jawnie skonfigurowane na stronie ustawień:

Definiowanie wpisów
Definiowanie wpisów

Domyślnie lista dozwolonych kluczy meta jest pusta.

Menu zostały zmapowane za pomocą nowego typu Menu i nowego pola Root.menu.

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

Ustawienia

Ustawienia witryny (przechowywane w tabeli wp_options) mogą być odpytywane za pomocą nowego pola Root.option: AnyScalar.

Na przykład, ta query pobiera nazwę witryny:

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

Które opcje mogą być dostępne, musi być jawnie skonfigurowane na stronie ustawień:

Definiowanie wpisów dla Ustawień

Domyślnie tylko następujące opcje mogą być odpytywane:

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

Posty użytkownika

Zalogowani użytkownicy mogą pobierać własne posty, dla dowolnego statusu (publish, pending, draft lub trash), za pomocą nowych pól:

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

Na przykład, możemy teraz wykonać tę query:

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

Dodano "unrestricted" pola admin do schematu GraphQL

Schemat GraphQL musi zachować równowagę między polami publicznymi a prywatnymi, aby uniknąć ujawniania prywatnych informacji w publicznym API.

Nowy moduł Schema for the Admin dodaje "unrestricted" pola admin do schematu GraphQL, które mogą ujawniać prywatne dane:

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

Na przykład, aby uzyskać dostęp do danych postów, mamy obecnie pole posts, które ujawnia tylko dane publiczne, pobierając opublikowane posty.

Od teraz możemy również uzyskiwać dostęp do danych postów za pomocą pola unrestrictedPosts, które ujawnia dane publiczne i prywatne, pobierając posty o dowolnym statusie ("publish", "draft", "pending", "trash").

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

Wprowadzono skalarny typ AnyScalar

Skalarny typ AnyScalar reprezentuje dowolny z wbudowanych typów skalarnych (String, Int, Boolean, Float lub ID).

Jest używany w nowo wprowadzonych polach option i metaValue(s), ponieważ nie znamy z góry typu zwracanych danych, a suma typów skalarnych nie jest jeszcze obsługiwana przez specyfikację GraphQL.

Ustawienia w formacie długim

Opcje na stronie Ustawienia są podzielone na zakładki. Od wersji v0.8 możliwe jest również wyświetlenie ich wszystkich razem na jednej długiej stronie.

Aby włączyć to zachowanie, odznacz pozycję "Have all options in this Settings page be organized under tabs, one tab per module." w Ustawieniach i naciśnij "Save Changes":

Pole wyboru do włączania/wyłączania zakładek w Ustawieniach

Następnie wszystkie ustawienia zostaną wyświetlone razem w formie długiej:

Ustawienia w formacie długim

Breaking changes

Wersja v0.8 wprowadza breaking changes w stosunku do poprzedniej wersji.

Breaking changes konfiguracji

Następujące CPT miały przebudowany blok "Options":

  • Schema Configurations
  • Custom Endpoints
  • Persisted Queries

W poprzedniej wersji v0.7 jeden blok Options dla tych encji zawierał wiele elementów konfiguracji. Od wersji v0.8 blok ten został podzielony na kilka niezależnych bloków, każdy zawierający własną konfigurację.

Na przykład w wersji v0.7 (poza włączaniem/wyłączaniem endpointu) blok Custom Endpoint Options umożliwiał konfigurację klientów GraphiQL i Interactive Schema:

Options in Custom Endpoint

Od wersji v0.8 ta konfiguracja jest dodawana za pomocą bloków GraphiQL i Interactive Schema:

Options in Custom Endpoint

Konfiguracja przechowywana w blokach Options dla wszystkich 3 CPT nie jest automatycznie migrowana do nowego formatu. Dlatego przed aktualizacją do v0.8 zapisz swoją przechowywaną konfigurację i odtwórz ją po aktualizacji do nowej wersji.

Przepraszamy za niedogodności.

Ponadto będziesz musiał kliknąć przycisk "Reset the template" wyświetlony w edytorze WordPress, dla wszystkich wpisów 3 CPT.

Reset the template w edytorze WordPress

Usunięto niestandardowe dyrektywy

Niestandardowe dyrektywy zostały usunięte z pluginu:

  • @default
  • @removeIfNull
  • @export

Usunięto moduły

Następujące moduły zostały usunięte z pluginu:

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

Nadchodzący plan działania

Teraz, gdy wersja v0.8 została wydana, możemy zacząć planować dalszą drogę.

Obecny plan jest następujący:

Wydanie v0.9 we wrześniu 2021, w tym:

  • Custom scalars
  • Zaktualizowany schemat GraphQL, używający custom scalars tam, gdzie to właściwe (np.: Post.date zwróci typ Date zamiast String)
  • Dalsze ulepszenia wsparcia rozszerzeń

A następnie wydanie v1.0 pod koniec roku lub na początku 2022, w tym:

  • Demonstracja pluginu rozszerzenia
  • Kompletne przewodniki dokumentacyjne dotyczące tworzenia rozszerzeń
  • Uruchomienie pluginu Gato GraphQL na wp.org

Aby otrzymywać powiadomienia o bieżącym statusie, możesz zapisać się do newslettera.

Napotkałeś problemy?

Jeśli masz jakikolwiek problem z instalacją lub uruchamianiem v0.8, utwórz issue w repozytorium.

Powrót do wszystkich wpisów

Zapisz się do naszego newslettera

Bądź na bieżąco ze wszystkimi aktualizacjami Gato GraphQL.