Warning
You're browsing the documentation for an old version of Webiny. Consider upgrading your project to Webiny 5.39.x.
What you'll learn
  • how to extend the Page Builder-related GraphQL types and operations

Use the webiny watch command to continuously deploy application code changes into the cloud and instantly see them in action. For quick (manual) testing, you can use the built-in API Playground.

Adding New Page Fields
anchor

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 GraphQLSchemaPluginexternal link, which we’ll need to register within our GraphQL API’s application code. Once we have that, optionally, we might want to register the IndexPageDataPluginexternal link plugin, which will enable us to get the value of the new special field also while listing pages.

api/code/graphql/src/plugins/pages.ts

The code above can be placed in the api/code/graphql/src/plugins/pages.tsexternal link file, which doesn’t exist by default, so you will have to create it manually. Furthermore, once the file is created, make sure that it’s actually imported and registered in the api/code/graphql/src/index.tsexternal link entrypoint file.

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:

For example:

Marking an Existing Page as SpecialMarking an Existing Page as Special
(click to enlarge)

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:

Querying Pages with the New Special Field Included in the ResultsQuerying Pages with the New Special Field Included in the Results
(click to enlarge)

Modifying GraphQL Queries
anchor

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 SearchLatestPagesPluginexternal link and SearchPublishedPagesPluginexternal link plugins (both extending SearchPagesPluginexternal link):

api/code/graphql/src/plugins/pages.ts

With all the changes in place, we should be able to run the following GraphQL query:

For example:

Listing Special PagesListing Special Pages
(click to enlarge)

Note that because we’ve created both the SearchLatestPagesPluginexternal link and SearchPublishedPagesPluginexternal link plugins, we can also apply the same special: true filter within the listPublishedPages GraphQL query.

The difference between the listPagesexternal link and listPublishedPagesexternal link 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.

Custom GraphQL Mutations
anchor

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 GraphQLSchemaPluginexternal link plugin.

api/code/graphql/src/plugins/pages.ts

The code above can be placed in the api/code/graphql/src/plugins/pages.tsexternal link file, which doesn’t exist by default, so you will have to create it manually. Furthermore, once the file is created, make sure that it’s actually imported and registered in the api/code/graphql/src/index.tsexternal link entrypoint file.

With all the changes in place, we should be able to run the following GraphQL mutation:

For example:

Duplicating an Existing PageDuplicating an Existing Page
(click to enlarge)

After the mutation has been executed, we should be able to see the created copy in the list of pages:

Listing Pages After A Copy Has Been CreatedListing Pages After A Copy Has Been Created
(click to enlarge)

FAQ
anchor

What Is thecontextObject and Where Are All of Its Properties Coming From?
anchor

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/code/graphql/src/index.tsexternal link entrypoint file.

That’s why, for example, we were able to utilize the context.pageBuilder.pages.getexternal link and context.pageBuilder.pages.updateexternal link methods, in the Custom Mutations section.

For easier discovery and type safety, we suggest a type is always assigned to the context object in your GraphQL resolver functions.