- how to extend the Page Builder-related GraphQL types and operations
In this example, we’ll add a new
special boolean field to the central
PbPage GraphQL type. As the name suggests, the field will tell us whether a page is special or not.
It all starts with the
GraphQLSchemaPlugin, which we’ll need to register within our GraphQL API’s application code. Once we have that, optionally, we might want to register the
IndexPageDataPlugin plugin, which will enable us to get the value of the new
special field also while listing pages.
With all the changes in place, we should be able to update an existing Page Builder page and mark it as special, with the following mutation:
Running the above mutation should mark the page with the
60f903881f76a1000820068e#0001 ID as special, which we should be able to see afterwards while performing queries:
If needed, existing pages-related GraphQL queries can be modified too.
Continuing from the previous example, let’s say we also wanted to be able to list special pages only. We can do that with the help of the
SearchPublishedPagesPlugin plugins (both extending
With all the changes in place, we should be able to run the following GraphQL query:
The difference between the
listPublishedPages is in the returned results. The former will always return latest revisions of a pages, which is more useful while listing pages inside the Admin Area application. The latter always returns published revisions of pages, which is more suitable for public applications and websites.
Let’s say we wanted to extend our GraphQL schema with the custom
duplicatePage mutation, which, as the name suggests, would enable us to make copies of pages.
We can achieve this with a single
With all the changes in place, we should be able to run the following GraphQL mutation:
After the mutation has been executed, we should be able to see the created copy in the list of pages:
In the shown examples, you may have noticed we were using the
context object in GraphQL resolver functions. This object contains multiple different properties, mainly being defined from different Webiny applications that were imported in the GraphQL API’s
api/graphql/src/index.ts entrypoint file.
For easier discovery and type safety, we suggest a type is always assigned to the
context object in your GraphQL resolver functions.