kontent-ai/gatsby-packages

Monorepo with Gatsby Kontent packages.

Gatsby Kontent.ai Packages

Monorepo with Gatsby Kontent.ai packages.

The repository contains the development site (/site) that could automatically load packages (packages) thanks to npm workspaces.

Content

Packages

Package	Summary	Version
Gatsby Source Kontent.ai Plugin	plugin providing data from Kontent.ai REST API to Gatsby GraphQL model
Gatsby Kontent.ai Components	package containing React components useful when processing Kontent.ai data to site

Site

• Development Site - Site using for development purposes and code examples showcasing packages possibilities

Examples

Navigation showcase

• Navigation showcase - Showcase including the navigation best practices. Description, how to do the content modeling with all benefits of the modular content as well as have tree-based menu structure.

Resolution showcase

• Resolution showcase - Demonstration how to resolve the Rich Text element and it's inline images, inline content items, and content components.

Relationships showcase

• Relationships showcase - Schema customization examples demonstrating relationship possibilities among Kontent.ai GraphQL nodes.

DSG and SSR showcase

• DSG and SSR showcase - Example showcasing Deferred Static Generation and Server side Rendering features with Kontent.ai.

Development

Prerequisites

• Nodejs

Install

1. Install packages

   npm install # install all npm dependencies in the repository

2. Start watch mode packages

   npm run watch # run watch mode through all packages source code

3. Run development site

   npm run develop:site # run `gatsby develop` command in the development site

Now you are good to go. You could start browsing http://localhost:8000 for development site and http://localhost:8000/___graphql for GraphiQL explorer.

Tests

To run all tests, there is npm script prepared.

npm run test # run test script in all packages as well as in the development site

• Packages are using Jest framework for testing.

Build

To build all of the packages as well as a development site, you could use one command.

npm run build # run build script in all packages as well as in the development site

Lint

To lint all of the packages as well as a development site, you could use one command.

npm run lint # run lint script in all packages as well as in the development site

• Packages are using ESLint with Typescript plugins for linting.

Publishing

As a publishing framework, there is a Lerna framework set up. This package is using Fixed/Locked mode. All minor and major changes should publish all packages, in case of patch version, it is up to developer decision.

How to publish new version

If you have the rights to publish packages, just use lerna and specify the version when prompted. All the changes made by lerna are automatically committed.

A typical scenario is when everything is ready and you want to publish the version, just use command.

npx lerna publish --tag-version-prefix=''

That should summarize the publish information and prompt you to define the version number and acknowledge the publish. Once everything is OK and you acknowledge the publish:

• the new version is published to npm
• <YOUR VERSION> is set to lerna.json's version
• commit with this change (and package.json files version changes) is pushed to the repository
  • commit also contains tag <YOUR VERSION> that could be used for creating GitHub release if you want

💡 If you want to test out the beta version first (which is recommended) use following command and if everything is OK, release another patch version as the final version.

npx lerna publish --tag-version-prefix='' --dist-tag=beta

gatsby-packages's Issues

Missing data or fields in the GraphQL schema

Brief bug description

The issue is described in https://rshackleton.co.uk/articles/gotchas-and-workarounds-with-gatsby-and-kentico-cloud-part-1

Repro steps

1. Create a content type with at least one text field
2. Connect project to Gatsby
   (DON'T CREATE A CONTENT ITEM BASED ON THIS CONTENT TYPE)
3. Query the content type

{
  allKenticoCloudItem<CONTENTTYPECODENAME> {
    edges {
      node {
        system {
          codename
        }
        elements {
          <ELEMENTNAME> {
            value
          }
        }
      }
    }
  }
}

4. See error

{
  "errors": [
    {
      "message": "Cannot query field \"<CONTENTTYPECODENAME>\" on type \"Query\".",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ]
    }
  ]
}

Expected behavior

The query should return empty data without error.

Gatsby schema customization might solve the issue

GraphQL schema generator might help with implementation: https://github.com/Kentico/kentico-cloud-graphql-schema-generator

Additional context

Twitter feed: https://twitter.com/shackleberry112/status/1132245949491896320
@rshackleton's article with description how to implement the schema customization on the application https://rshackleton.co.uk/articles/learning-about-gatsby-schema-customisation-with-kontent-ai

Some URLs within a rich text field are unresolved when using urlSlugResolver

I have URL resolvers set up for each model in my project that creates a page. Sometimes the URL relies on a value in a linked item (such as a parent entry) to create a URL like /parent-slug/entry-slug.

The issue I'm running into is the Kontent Delivery SDK for Javascript should return a link and a context item to the URL resolver, but in the Gatsby source plugin, sometimes the context item is empty when the link is within a rich text field. It seems related to the order the items are sourced by the Gatsby plugin.

Here is an example of a URL resolver that presents the issue:

import { ContentItem } from "@kentico/kontent-delivery"

module.exports = class Page extends ContentItem {
  constructor() {
    super({
      urlSlugResolver: (link, context) => {
        const entry = context.item
        const [parentElement] = entry ? entry.parent_element.value : []
        const [grandparentElement] = parentElement
          ? parentElement.parent_element.value
          : []

        if (!entry) {
          return null
        }

        return {
          url: `${
            grandparentElement ? `/${grandparentElement.url_slug.value}` : ``
          }${parentElement ? `/${parentElement.url_slug.value}` : ``}/${entry.url_slug.value
          }`,
        }
      },
    })
  }
}

If an entry w/ a content item name later in the alphabet is linked in a rich text field from a content item w/ a name that comes sooner in the alphabet the context variable won't be available to resolve the link. For example, a page named "Evaluation" with a link to a page called "Spiral" in it's rich text field won't include the necessary context item for the "Spiral" entry's link to be resolved. The variables using the resolver in the example above are:

context:
  item: undefined
  linkId: "dc284d7c-bcd7-4f42-8e93-774060aea8db"
  linkText: "imperial"

link: Link
  codename: "spiral_evaluation_form__imperial_"
  linkId: "dc284d7c-bcd7-4f42-8e93-774060aea8db"
  type: "page"
  urlSlug: "spiral-evaluation-form-imperial"

entry: undefined
grandparentElement: undefined
parentElement: undefined

Expected behavior

The context variable should include the entry being resolved under the item key. If that isn't possible, it would be nice to include the resolved URL on the links field that is included with the body in the GraphQL model. The URLs for each model are successfully resolved under the urlSlug.resovledUrl field, but that is not currently available from the body field.

Test environment

• Platform/OS: gatsby-source-kentico-cloud language-fallback branch, kontent-delivery 7.2.0

Make languageCodenames optional for config

Motivation

To simplify configuration for simple, single-language projects -- not require them to add additional options when getting started.

Proposed solution

Make languageCodenames optional in gatsby-config.js with a fallback to default if not provided.

Error when installing packages [email protected] and [email protected]

Brief bug description

Error when installing packages via yarn.

[email protected]
[email protected]

error An unexpected error occurred: "could not find a copy of gatsby to link in C:\\Projects\\Personal\\rshackleton.co.uk\\node_modules\\gatsby-source-kentico-cloud\\node_modules".

The error seems to happen from [email protected] onwards.

Test environment

• Platform/OS: Windows 10, Yarn 1.13.0

Additional context

Not sure if this is an issue with Yarn, an environmental issue or an issue with the particular versions of the packages.

Update kentico-cloud-delivery to 5.x.y

We should update gatsby to use latest kentico-cloud-delivery version.

Add feature toggle for Taxonomy

Motivation

Users who do not need to use the Taxonomy from Kontent should be able to exclude them from the build via configuration.

Proposed solution

Add a feature toggle into the Gatsby configuration that will allow developers to turn off the taxonomy generation.

Additional context

Related to #91, #1

kentico-cloud-delivery dependency is deprecated

kentico-cloud-delivery deprecated

Kentico Cloud has changed it's name to Kentico Kontent. Kentico also changed the delivery package from kentico-cloud-delivery to @kentico/kontent-delivery.

Expected behavior

The gatsby-source-kentico-cloud package is still depending on kentico-cloud-delivery. It shoud depend @kentico/kontent-delivery

Additional context

See https://www.npmjs.com/package/kentico-cloud-delivery

Hotfix Gatsby's conflict with KC assets

Brief bug description

Assets, in the Delivery response JSON, have GUIDs as keys. This gives Gatsby GraphQL code headaches. In particular, GUIDs that start with a number.

The immediate hotfix would be to prefix the keys with either alphabeticals or underscore.

This should be done properly in the future transformer plugin. For the time being, we can hotfix this in the source plugin and instruct site devs to use the GUIDs right underneath, in the image_id property.

Repro steps

1. Put images into rich text fields in KC
2. Run Gatsby develop

Expected behavior

Gatsby won't throw.

Add the otherLanguages field into the generated schema

Motivation

The otherLanguages field generated for item's variant is not part of the schema definition generated by createTypeNodesSchema() from typeNodesSchema.js.

Proposed solution

The goal of this issue is to add the mentioned field into the generated schema, write test(s), and update documentation.

Local images for Gatsby Image

Motivation

Gatsby image is a super plugin to help optimise and serve images, but as it currently stands this cannot be used with kentico cloud as it requires the images to be stored locally. Creating this would allow optimised and lazyloaded images to be included very easily in the intended way for gatsby.

Proposed solution

I'm not familiar enough with the build to create a PR myself but it definitely seems doable. This solution has already been implemented by other CMS' (Contentful for example) and makes optimising images via sharp extremely easy.

Expected steps during build

1. Assets required for build are uploaded to kentico cloud CMS
2. The user has a valid GraphQL query for images runs gatsby develop
3. During build, the tool finds all used images and downloads them to src/image (or similar), creating references to the source so that they can be queried with GraphQL via the normal asset route.

Error: Missing or invalid access token. Please include the valid access token value in the Authorization header field as an HTTP bearer authorization scheme

The GatsbyJS source plugin instructions mention to scaffold your project using Gatsby Kentico Cloud starter site however if you decide to use your own instance of a Kentico Cloud project with its own project configurations, you may run into an error when running 'gatsby-develop'.

The error I received was 'Error - Plugin gatsby-source-kentico-cloud returned an error.'

A detailed version of the error was 'Error: Missing or invalid access token. Please include the valid access token value in the Authorization header field as an HTTP bearer authorization scheme.'

There was also a warning message of 'The gatsby-source-kentico-cloud plugin has generated no Gatsby nodes. Do you need it?'

Linked items fields may (incorrectly) contain content items from another language

Brief bug description

In some instances GraphQL queries may return content items from different languages in linked item fields.

Repro steps

1. Create a content item in the default language that includes a linked item field
2. Select a content item in the linked field that has been translated
3. Do not translate the content item from Step 1
4. Query the content item from Step 1 in the default language using the Gatsby GraphQL API and include the linked item field in your request

query {
  entry: kenticoCloudItemProduct(system: {language: {eq: "en-US"}}, elements: {url_slug: {value: {eq: "a-product-that-hasn-t-been-translated"}}}) {
    id
    system {
      type
      language
    }
    elements {
      title {
        value
      }
      url_slug {
        value
      }
      product_line {
        ... on KenticoCloudItemProductLine {
          system {
            type
            language
          }
          elements {
            title {
              value
            }
            url_slug {
              value
            }
          }
        }
      }
    }
  }
}

The response will include the non-default language item in the linked field.

{
  "data": {
    "entry": {
      "id": "545f4ed0-4c33-53ed-9fe8-4294e259c630",
      "system": {
        "type": "product",
        "language": "en-US"
      },
      "elements": {
        "title": {
          "value": "A product that hasn't been translated"
        },
        "url_slug": {
          "value": "a-product-that-hasn-t-been-translated"
        },
        "product_line": [
          {
            "system": {
              "type": "product_line",
              "language": "de"
            },
            "elements": {
              "title": {
                "value": "A German product line"
              },
              "url_slug": {
                "value": "a-german-product-line"
              }
            }
          }
        ]
      }
    }
  }
}

Expected behavior

Querying for the same content item via the Delivery API will return the linked item from the same language as the content item as expected.

https://deliver.kenticocloud.com/e3e8b9bd-a86d-008d-0c64-2a0f18d1f39e/items/a_product?language=en-US&depth=1

GET /e3e8b9bd-a86d-008d-0c64-2a0f18d1f39e/items/a_product?language=en-US&depth=1

{
    "item": {
        "system": {
            "id": "e3cb36de-50ee-431b-a2ad-7bcbf7ed32cc",
            "name": "A product",
            "codename": "a_product",
            "language": "en-US",
            "type": "product",
            "sitemap_locations": [],
            "last_modified": "2019-09-14T18:05:19.5238556Z"
        },
        "elements": {
            "title": {
                "type": "text",
                "name": "Title",
                "value": "A product that hasn't been translated"
            },
            "url_slug": {
                "type": "url_slug",
                "name": "URL slug",
                "value": "a-product-that-hasn-t-been-translated"
            },
            "product_line": {
                "type": "modular_content",
                "name": "Product line",
                "value": [
                    "a_product_line"
                ]
            }
        }
    },
    "modular_content": {
        "a_product_line": {
            "system": {
                "id": "d94a39ee-8a87-4f51-8fc0-d59c9cf70ec1",
                "name": "A product line",
                "codename": "a_product_line",
                "language": "en-US",
                "type": "product_line",
                "sitemap_locations": [],
                "last_modified": "2019-09-14T18:05:06.9627187Z"
            },
            "elements": {
                "title": {
                    "type": "text",
                    "name": "Title",
                    "value": "A product line"
                },
                "url_slug": {
                    "type": "url_slug",
                    "name": "URL slug",
                    "value": "a-product-line"
                }
            }
        }
    }
}

Test environment

I'm using version 3.1.0 of the source plugin. This is what my config looks like:

    {
      resolve: `gatsby-source-kentico-cloud`,
        options: {
          deliveryClientConfig: {
            previewApiKey: process.env.KENTICO_CLOUD_PREVIEW_API_KEY,
            projectId: process.env.KENTICO_CLOUD_PROJECT_ID, // Fill in your Project ID
            enablePreviewMode: Boolean(process.env.KENTICO_CLOUD_ENABLE_PREVIEW_MODE || false),
            typeResolvers: [],
          },
          languageCodenames: [
            `en-US`, // Languages in Kentico (Project settings -> Localization)
            `de`
          ]
      }
    }

Additional information

The project ID above can be used for tests against this issue. It only includes the two content items/types referenced above.

The issue may be caused by the non-translated "product" node being created with the same ID as the default language's node since the node id only takes into account the codename and system language on content items.

Modifying createContentItemNode in itemNodes.js to accept a languageCodename parameter and passing defaultLanguageCodename and
languageCodename from getFromDefaultLanguage() and getFromNonDefaultLanguage() respectively and using the languageCodename value when calling createNodeId() seems to fix the issue so the expected linked item is returned via the GraphQL API.

For example:

const getFromNonDefaultLanguage = async (client, nonDefaultLanguageCodenames, contentTypeNodes, createNodeId) => {
  const nonDefaultLanguageItemNodes = new Map();

  for (const languageCodename of nonDefaultLanguageCodenames) {
    const languageResponse = await client.items().languageParameter(languageCodename).getPromise();

    const allItems = _.unionBy(languageResponse.items, languageResponse.linkedItems, 'system.codename');

    richTextElementDecorator.resolveHtml(allItems);
    const languageItemsFlatted = parse(stringify(allItems));
   // Pass the language codename
    const contentItemsNodes = languageItemsFlatted.map(languageItem => createContentItemNode(createNodeId, languageItem, contentTypeNodes, languageCodename));
    nonDefaultLanguageItemNodes.set(languageCodename, contentItemsNodes);
  }

  ;
  return nonDefaultLanguageItemNodes;
};

Accept the language code name as an argument and use it to create an ID instead of system.id on the content item.

const createContentItemNode = (createNodeId, contentItem, contentTypeNodes, languageCodename) => {
  if (!_.isFunction(createNodeId)) {
    throw new Error(`createNodeId is not a function.`);
  }

  validation.checkItemsObjectStructure([contentItem]);
  validation.checkTypesObjectStructure(contentTypeNodes);
  const codenameParamCase = changeCase.paramCase(contentItem.system.codename);
  const languageParamCase = changeCase.paramCase(languageCodename);
  const nodeId = createNodeId(`kentico-cloud-item-${codenameParamCase}-${languageParamCase}`);
  const parentContentTypeNode = contentTypeNodes.find(contentType => contentType.system.codename === contentItem.system.type);
  const itemWithElements = normalize.parseContentItemContents(contentItem);
  const additionalData = {
    otherLanguages___NODE: [],
    contentType___NODE: parentContentTypeNode.id
  };
  return normalize.createKcArtifactNode(nodeId, itemWithElements, `item`, contentItem.system.type, additionalData);
};

Include dimensions in image data

Motivation

Including the original image dimensions in the GraphQL data will allow generated image/picture elements to include inline widths or use the intrinsic ratio technique to preallocate space on the page when lazy-loading images.

Currently, we have access to this data:

{
  "name": "bandwidth-close-up-computer-1148820.jpg",
  "type": "image/jpeg",
  "size": 2536272,
  "description": "...",
  "url": "..."
}

The Kentico Cloud UI also includes the upload date and dimensions so the data is clearly already available.

Proposed solution

Include dimensions in GraphQL schema.

{
  "name": "bandwidth-close-up-computer-1148820.jpg",
  "type": "image/jpeg",
  "size": 2536272,
  "description": "...",
  "url": "...",
  "width": 6016,
  "height": 4016
}

Spike: Consider alternatives to using "debug"

Expected result

In reaction to gatsbyjs/gatsby#8053, we re-wrote the plugin to get data from the debug property of the JS SDK response object. But, the debug property was not meant to be used for other than debugging purposes.

Consider the alternative approaches:

• De-conversion of class instances produced by the SDK back into plain JS objects using a library (eg. https://www.npmjs.com/package/flatted)
• Writing our own recursive de-conversion method (similar to https://stackoverflow.com/a/34701165/4074527)

Also, consider the performance impact of the de-conversion in environments like Netlify.

update npm with README

Brief bug description

old readme (the badges using old package name) on:

• https://www.npmjs.com/package/@kentico/gatsby-source-kontent
• https://www.gatsbyjs.org/packages/@kentico/gatsby-source-kontent/ (sourced from npm)

Expected behavior

updated README

Possible error when using nested Linked Items

Brief bug description

There appears to be an bug with querying nested linked items that was introduced with Schema changes in v4.0.0-beta4. The error seems to occur whenever a linked item contains another linked item.

Example: I have a content type Page - Home, which consists of multiple linked items of content type Section - Article section. Each Section content type has one or more linked items of content type Article. Basically, the Section content types are used as a kind of drag and drop for our content editors to reorder the sections on the homepage as a way to display linked Articles.

Repro steps

Example GraphQL Query:

query {
  kontentItemPageHome {
    elements {
      sections {
        linked_items {
          ... on KontentItemSectionHomepageFullWidth {
            id
            elements {
              article {
                linked_items {
                  elements {
                    title {
                      value
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

Query Error:

"message": "Cannot query field \"elements\" on type \"KontentItem\". Did you mean to use an inline fragment on \"KontentItemArticle\", \"KontentItemArticleEarned\", \"KontentItemAuthor\", \"KontentItemCollection\", or \"KontentItemNavigationMain\"?"

Expected behavior

Queries work fine in v4.0.0-beta1 and before, tested with the errors on on v4.0.0 and v4.1.0-beta7.

Test environment

• MacOS Catalina
• Chrome
• Version 79
• plugin versions greater than 4.0.0-beta4

Additional context

I don't have much knowledge about GraphQL schema. At first I thought it was my usage of GraphQL fragments, but I'm getting the same errors when trying to query the data in GraphiQL IDE.

I'm rendering our Rich Text linked items the way described by @rshackleton in his excellent example. It doesn't appear to be throwing errors there, only when a linked item contains another linked item.

Parse content components

Blocked: #19

Motivation

With the introduction of content components into Kentico Cloud, we should start supporting them. This support should span across both the source plugin and the future transformer plugin.

With the current version of our source plugin, content components are neither physically included in their parent Rich text element HTML nor represented by GraphQL nodes.

Proposed solution

In the future transformer plugin, make provisions of parsing the components' data into HTML, similarly to how link resolvers and rich text resolvers work in the JS SDK. The data of components should be prepared by the source plugin somehow for the transformer plugin to use it.

Additional context

According to Gatsby, the sole job of source plugins is to take the source data and convert them into GraphQL nodes. All other "enhancements" should be done by transformer plugins.

Therefore, the process of building of the output HTML of content components should be done by the future transformer plugin. But, the data of those components should be transferred from the source plugin to the transformer plugin somehow. Most probably the data would have to be in the form of ordinary GraphQL nodes (even though components only live inside their parent items).

Using .forEach() probably leads to indeterministic ordering

Brief bug description

When creating the _nodes sibling GraphQL properties by the plugin, using forEach() causes the iterations to run in arbitrary order (asynchronously), which leads to reordered results (as opposed to the original collection).

Expected behavior

The order of the items in the _nodes property should reflect the ordering in the original collection.

Normalize fields you get from kentico-cloud-delivery

Motivation

url field that is missing is instance of TextField class ( https://github.com/Enngage/kentico-cloud-js/blob/94ce81548f167530c9376e7a852ac733a708e85b/packages/delivery/lib/fields/field-types.ts#L8-L32 ), which gatsby can't handle first time it sees it. But it works on second try because after serializing data to cache and deserializing it again we get plain object with properties which gatsby can handle

Proposed solution

since the objects are coming from your client, so for now you should probably convert those to objects in the plugin.

Additional context

• conversation here

secureApiKey on gatsby-config not work

Brief bug description

When I had my 'Delivery API secured access' enabled and provided secureApiKey with the Delivery API key

Repro steps

1. Run gatsby develop
2. Monitor the terminal
3. See error

Expected behavior

What the correct behavior is?
This should work by generating the node for each content types and content items

Test environment

• Windows 10 Subsystem for Linux (Ubuntu 18.04)
• Gatsby CLI version: 2.7.47
• Gatsby version: 2.15.14
• gatsby-source-kentico-cloud 3.1.0

Additional context

Screenshots

Gatsby Source Plugin - Rebranding to Kentico Kontent

Hi @Simply007 !
We've just renamed Kentico Cloud to Kentico Kontent. We are in the process of renaming all SDKs, developer tools, and sample apps. Please consider renaming your project (code: namespaces, classes; repo, wiki, GH topics, etc.) to Kentico Kontent. See the guidelines at https://gitter.im/Kentico/Kontent?at=5d8b643d692d464f7969c6d9.

Thank you!

Support relationships via links to content items in Rich text elements

Motivation

We already support most kinds of relationships among GraphQL nodes. One of the two remaining kinds is relationships based on links to content items in Rich text elements.

Proposed solution

Implement the relationships similarly to the decorateItemNodeWithLinkedItemsLinks method.

Cannot access content from a "Rich Text" field in a content item

Brief bug description

Trying to access a "Rich Text" type field in the GraphQL data. The query returns an error with the following message:

{
  "errors": [
    {
      "message": "Cannot query field \"page_content\" on type \"elements_4\".",
      "locations": [
        {
          "line": 20,
          "column": 7
        }
      ]
    }
  ]
}

However, the data should include a page_content field as it is defined in the contentType:

{
  "data": {
    "kenticoCloudItemContentPage": {
      "id": "18dbf59a-07c3-5111-957b-f5650dd604f8",
      "contentType": {
        "elements": [
          {
            "name": "Slug",
            "codename": "slug",
            "type": "url_slug"
          },
          {
            "name": "Page Content",
            "codename": "page_content",
            "type": "rich_text"
          },
          {
            "name": "Thumbnail",
            "codename": "thumbnail",
            "type": "asset"
          },
          {
            "name": "Template Name",
            "codename": "template_name",
            "type": "multiple_choice"
          },
          {
            "name": "Summary",
            "codename": "summary",
            "type": "text"
          },
          {
            "name": "Title",
            "codename": "title",
            "type": "text"
          }
        ]
      }
    }
  }
}

There is a single content item with the page_content field populated and the other data is being returned as expected:

{
  "data": {
    "kenticoCloudItemContentPage": {
      "id": "18dbf59a-07c3-5111-957b-f5650dd604f8",
      "elements": {
        "title": {
          "value": "About"
        },
        "slug": {
          "value": "about"
        },
        "template_name": {
          "value": [
            {
              "name": "Standard",
              "codename": "standard"
            }
          ]
        },
        "summary": {
          "value": "Its all about the service"
        }
      }
    }
  }
}

Expected behavior

Would expect the content to be accessible in the GraphQL data.

Test environment

• Platform/OS: NodeJS 10.3.0, Gatsby 2.4.5
• Version: 2.1.0

`run queries` step much slower after v4.0.0-beta2

After updating to v4.3.0 from 4.0.0-beta2, the step in gatsby build where queries are run is much slower. On our project w/ 2 languages enabled, builds go from 2.3 minutes to 11.6 minutes.

With everything else the same, downgrading the plugin back to 4.0.0-beta2 returns the build times to their prior level. With all languages enabled on our site, builds timeout in CI/CD environment at 90 minutes (builds are typically ~40 minutes).

I've tried Gatsby versions 2.17.5, 2.19.10, and a few in-between that are compatible w/ 4.3.0 and with each version, changing between the older version of gatsby-source-kontent and the latest produces the same slow/fast result. After further digging, it appears the slow down occurs between 4.0.0-beta2 and 4.0.0-beta4.

Is there any logging we can enable that would provide more insight into what is happening on this step? Is there something related to the generated schema that affects the step where queries are run?

Repro steps

1. Run a build using v4.0.0-beta2 and record the time the build takes
2. Run a build using v4.0.0-beta4 or newer and record the time the build takes

Expected behavior

Builds should take similar amounts of time

Test environment

• Node v10.16.1
• Gatsby v2.19.10
• Gatsby Source Kontent v4.0.0-beta4 - v4.3

Prepare for Fair user policy updates

Brief bug description

From the 1st of February the /items endpoint is limited to 1000 (incl. linked items) as described in Kontent API changes.

After that date, queries resulting in more than 1K content items per language won't load more than that 1K items.

Expected behavior

There is an alternative endpoint introduced /items-feed.

Allow source plugin to configure, whether /items or /items-feed endpoint is used and describe the pros and cons in Readme.

Additional context

In the SDK, there is a method itemsFeedAll that allows the loading of all of the items.

• There is only one downside is that after this - the Embedded JS SDK resolution is not performed and resolution must be made manually according to the article, or by using the sample component.

The new cycle detection logic is inefficient

Motivation

The updated logic (introduced by #33) builds the processedContents array out of joined codenames. The array is always `pushed with the same string, just with another codename appended. This is inefficient and not needed (see Expected behavior below).

Moreover, such detection logic always needs to split the string by semicolons to reveal the cycle. There is a better way of doing it.

Proposed solution

The processedContents argument to the parseContentItemContents method should contain the codenames separated, not joined up-one-level. Without that, no split has to be done. The processedContents argument by nature always contains a path of just one Linked items element. Therefore, there's no need for the joined-up-one-level history.

Get codenames of modular (linked) items in a newer way

Blocked: We should first decide if using debug is better or not in #12

Motivation

Up until now, the JS SDK was stripping the modular_content array of codenames of content items from the response. It is no longer the case.

Proposed solution

Remove the normalize.refillRichTextModularCodenames method in favor of using the new linkedItemCodenames property of rich text element objects.

Image transformer plugin

Motivation

Implement transformer plugin that allow enrich the data provided by this source plugin by image transformations.

Allow configuring which image transformations should be generated into the Gatsby GraphQL model and on what fields they should be applied.

Proposed solution

Create a separate repository with the transformer plugin.

The configuration would accept an object with properties containing identification of types in following structure.

It is possible to use javascript SDK to implement the creation - https://github.com/Kentico/kentico-cloud-js/blob/master/packages/delivery/DOCS.md#image-transformations

• Ask @Enngage in case of neccestiy to extract methods of ImageUrlBuilder to be able to provide configuration without actual URL.

const config = {
  article: { // type definition
    teaser: { // element definition
      square: [ // image transformation name
        { // parameters by https://developer.kenticocloud.com/reference#image-transformation
          paramname: "w",
          value: "100"
        },
        {
          paramname: "h",
          value: "100"
        }
      ],
      black_background: [
        {
          paramname: "bg",
          value: "000000"
        }
      ]
    },
    // twitter_image {...} -> another element
  },
  // product: { ... } -> another content type
};

The new cycle detection logic is inefficient & cannot reveal cycles properly

Brief bug description

The detection mistakenly compares against a non-existent contentItem.codename property, instead of the correct contentItem.system.codename.

Expected behavior

Use contentItem.system.codename for checking.

Add tests for decorate* methods

Blocked: #19

Motivation

While the tests/normalize.spec.js test file tests whether content type nodes and content item nodes get properly created, it still doesn't test the decorateTypeNodesWithItemLinks and the decorateItemNodeWithLanguageVariantLink methods.

Design guidelines

• Use the existing contentItemNodes.json and contentTypeNodes.json files as test fixtures.
• Adjust them to be ready for testing of the above two methods (e.g. add more data into the JSON files).
• Add test counterparts for the above two methods into the tests/normalize.spec.js Jest file.
• Run the tests for the first time to generate new snapshots.
• Check the correct shape of the snapshots.

Reference

• https://jestjs.io/docs/en/snapshot-testing

There are conflicting field types in your data. GraphQL schema will omit those fields

Brief bug description

Added new "linked items" field to a content model and then the Gatbsy build started reporting an error during page generation. The new field was added to a "Service" content model and the query reporting an error is related to the "Home page" content model. Looks like an error during the GraphQL schema generation causes the "page_sections" field to be removed.

success open and validate gatsby-configs — 0.010 s
success load plugins — 0.209 s
success onPreInit — 1.003 s
success delete html and css files from previous builds — 0.051 s
success initialize cache — 0.006 s
success copy gatsby files — 0.284 s
success onPreBootstrap — 0.012 s
⠁ The 'sourceNodes' API implementation starts.
projectId: d92a1dd4-01a3-0004-e56d-397f00237833,
languageCodenames: default.
⠈ source and transform nodesThe 'createNode' API is called.
contentTypeNode.id: 91d10190-069e-5ea4-b8fc-bedba5f354a5
The 'createNode' API is called.
contentTypeNode.id: 106a2487-27b6-55ad-97f0-3e7e442c3531
The 'createNode' API is called.
contentTypeNode.id: 2b5c2014-b628-5f0a-902d-16196b2b87af
The 'createNode' API is called.
contentTypeNode.id: 53f4d140-3907-546c-b01b-e7336b5febc5
The 'createNode' API is called.
contentTypeNode.id: 515a3dac-6ad0-59ee-bc8f-63a5733c05eb
The 'createNode' API is called.
contentTypeNode.id: 96a315e5-a175-5bbe-aadd-6fc3d479cfe9
The 'createNode' API is called.
contentTypeNode.id: 515697e3-fab3-58fd-9eef-40a7b62bd77b
The 'createNode' API is called.
contentTypeNode.id: c979f5de-5e2f-5574-8375-f5050abd64b3
The 'createNode' API is called.
contentTypeNode.id: 948ec2e0-b36c-5ff1-82a3-a889ae2d4210
The 'createNode' API is called.
contentTypeNode.id: a63fc8b3-f6fd-5871-8e41-0449cfd7da16
The 'createNode' API is called.
contentTypeNode.id: 7e13b0ab-bae6-5c5a-b966-0c4d8b4f9ea7
The 'createNode' API is called.
contentTypeNode.id: 2d534c25-88ab-576f-8c63-cb35afbd1497
The 'createNode' API is called.
contentTypeNode.id: f8cacacb-0fa8-5337-b1b9-12f515479d1d
The 'createNode' API is called.
contentTypeNode.id: eb8be8be-7df2-520e-9dd4-2f371e22d0be
The 'createNode' API is called.
contentTypeNode.id: 53157248-b5ff-5ca7-a6b5-275222f65c42
The 'createNode' API is called.
contentTypeNode.id: 6efd340d-df7e-5180-90a1-29e11ea28ab6
The 'createNode' API is called.
contentTypeNode.id: 50156b81-0011-5888-a689-b6673f8a869e
The 'createNode' API is called for content item nodes.
The 'createNode' API is called.
contentItemNode.id: 18dbf59a-07c3-5111-957b-f5650dd604f8
The 'createNode' API is called.
contentItemNode.id: 6e22b5d8-964a-5f99-a317-088e8094783c
The 'createNode' API is called.
contentItemNode.id: c6482219-a78d-5d59-94a1-b7f832c7c0dc
The 'createNode' API is called.
contentItemNode.id: 4b7e3c4f-edbd-5cb5-bb69-8ec6e1be404c
The 'createNode' API is called.
contentItemNode.id: fc1c4370-a8a0-5e0d-9534-043de91a9325
The 'createNode' API is called.
contentItemNode.id: 6febbc4b-230e-5add-b7f5-b627230dc980
The 'createNode' API is called.
contentItemNode.id: 28e68b6f-c8d8-558e-9261-93e78ebee5f6
The 'createNode' API is called.
contentItemNode.id: 1261b19a-0bdc-5992-ae44-37d1c7f83347
The 'createNode' API is called.
contentItemNode.id: 727bf742-b99e-5ffa-901f-7b11149ca501
The 'createNode' API is called.
contentItemNode.id: 28c03a24-952b-563f-ab68-07490c3cdfa0
The 'createNode' API is called.
contentItemNode.id: 0da1c9d6-c7ad-5bdf-b34d-14dd248ef724
The 'createNode' API is called.
contentItemNode.id: 8e98c4c7-e399-5c08-a802-8d6edc5696b0
The 'createNode' API is called.
contentItemNode.id: 462a4bdf-4cf7-597f-beb4-a911d5cb3c97
The 'createNode' API is called.
contentItemNode.id: 0a761fe2-3706-529c-8725-89b9c1402a1c
The 'createNode' API is called.
contentItemNode.id: acdda811-2095-5b9c-a859-020a419fae33
The 'createNode' API is called.
contentItemNode.id: fd6d2c9f-20d6-5d7f-b556-d4684e19d30f
The 'createNode' API is called.
contentItemNode.id: c5f895e1-f40e-54d4-9a7e-e6cbd5021b33
The 'createNode' API is called.
contentItemNode.id: 3c44f4e4-f0fa-55b7-81d2-4bd6872a89a2
The 'createNode' API is called.
contentItemNode.id: 304e761b-e11f-51af-8f18-be40b88f12c4
The 'createNode' API is called.
contentItemNode.id: bf99bb4c-1e3d-5c23-bd9c-eb012986beba
The 'createNode' API is called.
contentItemNode.id: 96c7268e-d6fc-5417-a892-75bc120bc7e7
The 'createNode' API is called.
contentItemNode.id: e5c7c581-ca74-5759-ad50-3b3e71595fb3
The 'createNode' API is called.
contentItemNode.id: 36b31664-f688-57d1-a52c-764c76e2faa3
The 'createNode' API is called.
contentItemNode.id: fc752aae-0d21-5814-a98e-3cb1e491b05a
The 'createNode' API is called.
contentItemNode.id: a4e1f7d4-ebf5-527c-ac21-c8b33c7bd95c
The 'createNode' API is called.
contentItemNode.id: a81f46d8-0d39-5c73-a5a2-07c1b3288531
The 'createNode' API is called.
contentItemNode.id: cc6eb5bb-2b55-5feb-9702-99e8a1218d73
The 'createNode' API is called.
contentItemNode.id: 8bb2285e-8e54-5555-8c5b-233cc1b7c617
The 'createNode' API is called.
contentItemNode.id: f288cd26-46c7-5a26-a289-ac007027b02d
The 'createNode' API is called.
contentItemNode.id: a8bbcc81-6537-55d2-9c21-8e42f86323ed
The 'createNode' API is called.
contentItemNode.id: 2a394d2b-13e1-5cab-9728-0923c27bed91
The 'createNode' API is called.
contentItemNode.id: dfe0fdaa-4b3b-575b-8ab5-55f5f0c015b8
The 'createNode' API is called.
contentItemNode.id: c889bfe2-4282-5727-bb6a-25e223a12342
The 'createNode' API is called.
contentItemNode.id: ba2e3c36-6126-506e-841e-178753bbe680
The 'sourceNodes' API implementation exits.
success source and transform nodes — 1.543 s
success building schema — 1.010 s
success createPages — 0.151 s
success createPagesStatefully — 0.048 s
success onPreExtractQueries — 0.000 s
success update schema — 0.672 s
warning There are conflicting field types in your data. GraphQL schema will omit those fields.
KenticoCloudItemHomePage.elements.page_sections[]:
 - type: object
   value: { system: [Object], elements: [Object] }
error GraphQL Error Fragment cannot be spread here as objects of type "unionPageSectionsNodesNode_4" can never be of type "KenticoCloudItemBlogPostSection".

  file: D:/Projects/####/src/pages/index.jsx

   9 |         title {
  10 |           value
  11 |         }
  12 |         page_sections {
  13 |           system {
  14 |             id
  15 |             codename
  16 |           }
  17 |         }
  18 |         page_sections_nodes {
> 19 |           ... on KenticoCloudItemBlogPostSection {
     |           ^
  20 |             ...BlogPostSectionInfo
  21 |           }
  22 |           ... on KenticoCloudItemCallToAction {
  23 |             ...CallToActionInfo
  24 |           }
  25 |           ... on KenticoCloudItemGetAQuote {
  26 |             ...GetAQuoteInfo
  27 |           }
  28 |           ... on KenticoCloudItemServicesSection {
  29 |             ...ServicesSectionInfo

success extract queries from components — 0.215 s
⠁ (node:208576) DeprecationWarning: Passing lineNumber and colNumber is deprecated to @babel/code-frame. Please use `codeFrameColumns`.
success run graphql queries — 0.019 s — 5/5 269.95 queries/second
success write out page data — 0.017 s
success write out redirect data — 0.007 s
success onPostBootstrap — 0.001 s

info bootstrap finished - 9.56 s

Test environment

• NodeJS: 10.13.0
• Gatsby: 2.0.54
• Version: 2.1.2

Additional context

Using project d92a1dd4-01a3-0004-e56d-397f00237833.

Queries don’t fallback to default language

Brief bug description

It doesn’t appear that the source plugin includes fallback content as described in the Localization in Kentico Cloud portions of the docs.

Repro steps

When querying data, include otherLanguages in the query and include codenames for additional languages in the deliveryClientConfig object in gatsby-config.js. Content Items won't be included if a translation hasn't been created.

{
  allKenticoCloudItemPage {
    edges {
      node {
        id
        system {
          type
          language
        }
        elements {
          url_slug {
            value
          }
        }
        otherLanguages {
          system {
            language
          }
        }
      }
    }
  }
}

Expected behavior

If the language is configured to use a default fallback, content should be included from the default language.

Is there a workaround or config I'm missing?

Multiproject data data source

Motivation

Allow users to load data from more than one project.

Proposed solution

Extend a configuration object by the project identification property that would create the project-specific prefix for created Nodes.

Configuration example:

       {
      resolve: `gatsby-source-kentico-cloud`,
      options: {
        project1: {
          deliveryClientConfig: {
            projectId: `firstProjectGuid`,
          },
          languageCodenames: [
            `en-US`,
            `es-ES`,
          ]
        },
        project2: {
          deliveryClientConfig: {
            projectId: `secondProjectId`,
          },
          languageCodenames: [
            `en-US`,
          ]
        }
      }
    }

Possible workaround

Using Kontent Delivery API directly (or using JS SDK) without the GraphQL layer might work as a workaround:
https://www.gatsbyjs.com/docs/how-to/querying-data/using-gatsby-without-graphql/

Add support for taxonomies

Motivation

Kentico Kontent uses taxonomy groups to organize content. The GraphQL nodes of content items do not contain all taxonomy terms of all taxonomy groups. Just terms used in items.

Proposed solution

Introduce new Gatsby types with a KontentTaxonomy prefix. They should be interlinked with content items that use their taxonomy terms.

Reference

• https://docs.kontent.ai/reference/delivery-api#tag/Taxonomy-groups

Outdated Data When Using ENABLE_GATSBY_REFRESH_ENDPOINT

I am leveraging ENABLE_GATSBY_REFRESH_ENDPOINT to reload data from Kentico when there is an update without restarting the development server (gatsby develop). However, I learned that any data that is removed from Kentico Cloud remains present in Gatsby. The only way to remedy this is by restarting the server, which is time consuming. I'm assuming that it could be because this plugin does not handle clearing existing nodes before reloading data.

Add feature toggle for Types

Motivation

Users who do not need to use the content types data from Kontent should be able to excluded them from the build via configuration and get rid of kontentType* and allKontentType* queries.

Proposed solution

Add a feature toggle into the Gatsby configuration that will allow developers to turn off the type generation.

Additional context

It should clean out the QraphiQL UI as well as is should saves computation time linking content items<->content type.

Enable the use of Inline Fragments with Linked Items fields

Motivation

The use of inline fragments would simplify the data returned from GraphQL queryies when accessing elements within linked item fields. For example:

{
  allKenticoCloudItemHomePage {
    edges {
      node {
        elements {
          page_sections {
            system {
              type
            }
            elements {
              title {
                value
              }
              slug {
                value
              }
              image {
                value {
                  url
                }
              }
              content {
                value
              }
              services {
                elements {
                  title {
                    value
                  }
                  content {
                    value
                  }
                  image {
                    value {
                      url
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

The query above means all items under page_sections will contain all of the possible fields:

{
  "data": {
    "allKenticoCloudItemHomePage": {
      "edges": [
        {
          "node": {
            "elements": {
              "page_sections": [
                {
                  "system": {
                    "type": "services_section"
                  },
                  "elements": {
                    "title": null,
                    "slug": null,
                    "image": null,
                    "content": null
                  }
                },
                {
                  "system": {
                    "type": "features___benefits_section"
                  },
                  "elements": {
                    "title": {
                      "value": "Switching is easy"
                    },
                    "slug": null,
                    "image": null,
                    "content": {
                      "value": "Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt "
                    }
                  }
                },
                {
                  "system": {
                    "type": "call_to_action"
                  },
                  "elements": {
                    "title": {
                      "value": "Excepteur sint occaecat cupid atat non proident?"
                    },
                    "slug": null,
                    "image": null,
                    "content": null
                  }
                },
                {
                  "system": {
                    "type": "get_a_quote"
                  },
                  "elements": {
                    "title": {
                      "value": "Make the switch"
                    },
                    "slug": null,
                    "image": null,
                    "content": {
                      "value": "Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt "
                    }
                  }
                },
                {
                  "system": {
                    "type": "blog_post_section"
                  },
                  "elements": {
                    "title": {
                      "value": "Latest Blog Posts"
                    },
                    "slug": null,
                    "image": null,
                    "content": {
                      "value": "Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt "
                    }
                  }
                },
                {
                  "system": {
                    "type": "testimonial"
                  },
                  "elements": {
                    "title": {
                      "value": "Example testimonial"
                    },
                    "slug": {
                      "value": "example-testimonial"
                    },
                    "image": {
                      "value": [
                        {
                          "url": "https://assets-us-01.kc-usercontent.com:443/d92a1dd4-01a3-0004-e56d-397f00237833/04eb913c-305f-419c-bb50-a2432539cacb/aerial-android-wallpaper-architectural-design-373912.jpg"
                        }
                      ]
                    },
                    "content": {
                      "value": "<p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore.</p>"
                    }
                  }
                },
                {
                  "system": {
                    "type": "press_section"
                  },
                  "elements": {
                    "title": {
                      "value": "In The Press"
                    },
                    "slug": null,
                    "image": null,
                    "content": {
                      "value": "Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt "
                    }
                  }
                }
              ]
            }
          }
        }
      ]
    }
  }
}

Using inline fragments would remove the redundant fields.

Additional context

https://graphql.org/learn/queries/#inline-fragments

Cannot speculatively include types in Linked Item fields

Motivation

When using a linked type field we may wish to support content models which haven't been added to an existing content item. However, when one is added the GraphQL query needs to be updated to support this new content model. For example:

kenticoCloudItemService(elements: { slug: { value: { eq: $slug } } }) {
  id
  elements {
    title {
      value
    }
    service_page_sections {
      system {
        id
        type
      }
    }
    service_page_sections_nodes {
      ... on KenticoCloudItemBlogPostSection {
        ...BlogPostSectionInfo
      }
      ... on KenticoCloudItemCallToAction {
        ...CallToActionInfo
      }
      ... on KenticoCloudItemFeaturesBenefitsSection {
        ...FeaturesBenefitsSectionInfo
      }
      ... on KenticoCloudItemServiceBanner {
        ...ServiceBannerInfo
      }
      ... on KenticoCloudItemTestimonial {
        ...TestimonialInfo
      }
    }
  }
}

If the content editor removes all KenticoCloudItemCallToAction types then the query will throw an error:

GraphQL Error Fragment cannot be spread here as objects of type "unionServicePageSectionsNodesNode_2" can never be of type "KenticoCloudItemCallToAction".

The content editors should be free to make these changes without also requiring code changes.

Proposed solution

Generate the GraphQL schema for linked items to include all other content models, this should ensure that they are supported in GraphQL queries. If the linked item field has a limitation on the content models that can be selected then this should influence the GraphQL schema.

Spike: Support partial rebuild of the node store

Expected outcome

Currently, the source plugin fetches all KC content during the bootstrap process. In large content projects, the bootstrap may take too long. By storing the last update date, the plugin could fetch only content that was created and updated afterwards (delta). Find ways of implementing such story.

Note: There is currently no way of getting the collection of deleted/unpublished content off of the Delivery API. Only web hooks can serve this purpose. Find out if a simple web hook listener can be implemented in a Gatsby site.

Reference

• gatsbyjs/gatsby#3790

Add the resolvedData field into the generated schema

Motivation

The resolvedData field generated for richtext element is not part of the schema definition generated by createTypeNodesSchema() from typeNodesSchema.js.

Proposed solution

The goal of this issue is to add the mentioned field into the generated schema, write test(s), and update documentation.

Changes to schema generation impact some GraphQL filters

Brief bug description

Before automatic schema generation was implemented, it was possible to filter the usedByContentItems property. For example, to show related content where the linked items relationship is made on another entry, you could use the usedByContentItems parameter to retrieve the content so the relationship didn't have to be maintained on multiple entries.

export const query = graphql`
  query BeltIdentifierTypeQuery(
    $url_slug: String!
    $language: String!
  ) {
    pitches: allKontentItemBeltPitch(
      filter: {
        usedByContentItems: {
          elemMatch: {
            system: { type: { eq: "belt_series" } }
            elements: {
              belt_type: {
                linked_items: {
                  elemMatch: {
                    elements: { url_slug: { value: { eq: $url_slug } } }
                  }
                }
              }
            }
          }
        }
      }
    ) {
      nodes {
        id
        elements {
          pitch {
            value
          }
        }
        beltSeries: usedByContentItems {
          ... on KontentItemBeltSeries {
            id
            system {
              type
              language
            }
            elements {
              title {
                value
              }
              url_slug {
                resolvedUrl
              }
            }
          }
        }
      }
    }
  }
`

The query above fails w/ Field "elements" is not defined by type KontentItemFilterInput.

A similar error occurs with otherLanguages in the following query:

export const query = graphql`
  query QueryName(
    $url_slug: String!
    $language: String!
  ) {
    entry: kontentItemBeltSeries(
      preferred_language: { eq: $language }
      elements: {
        url_slug: { value: { eq: $url_slug } }
        belt_identifier_entries: {
          linked_items: {
            elemMatch: {
              otherLanguages: {
                elemMatch: { preferred_language: { in: ["en", "de"] } }
              }
            }
          }
        }
      }
    ) {
      system {
        type
        language
        codename
      }
    }
  }
`

The query above fails w/ Field "otherLanguages" is not defined by type KontentItemFilterInput. Did you mean preferred_language?

It appears the regression occurs somewhere between 4.0.0-beta2 and 4.2.0 — I think related to the automatic schema generation.

Is there something I can fine-tune on the query or another workaround that doesn't affect the content model in Kentico?

Possibly related to the following: #84 , #105

Expected behavior

The query should retrieve data as it did before the schema generation process was updated.

Test environment

• @kentico/gatsby-source-kontent v4.3.0
• @kentico/kontent-delivery v9.0.0

Spike: Consider creating a transformer plugin

Expected result

The JS SDK allows the developer to define so called link resolvers and rich text resolvers. These are methods that operate on Kentico Cloud Rich text elements and produce HTML with hyperlinks and embedded content items.

The source plugin currently builds the _nodes sibling GraphQL properties that contain GraphQL links to content items in a given Rich text element. It also lacks the support for creating (or enriching) the _nodes sibling property based on links. It doesn't do any transformation of the rich text element HTML data.

Such a transformation should be dealt with separately using a Gatsby transformer plugin.

Find out:

• what it takes to create a transformer plugin that transforms links and content items in Rich text
• if the resolvers could be written by developers using the same notation as the JS SDK uses

Also, Gatsby have recently updated their best practice and recommend doing any "enhancement" of source nodes via a transformer plugin (not through a source plugin).

Therefore, consider moving the code that creates the _nodes sibling properties into the new transformer plugin.

Resources

• Resolving URL slugs (links) in JS SDK
• Resolving content items and components in Rich text fields in JS SDK

Handle type errors caused by circular references in data

Brief bug description

See gatsbyjs/gatsby#9560

Retrieving an asset url

Expected result

Get the URL string as shown on GraphiQL in-browser IDE

Additional context

I have copied from the Code Exporter but the result is empty, even when I tried using elements.logo.value node
Any reference/documentation of how to retrieve the URL of an asset?

Screenshots

First Class Source plugin

Motivation

In order to be able to handle the Gatsby preview we need to fulfill the requirements for the "First class source plugin".

Proposed solution

• Have the Gatsby Kentico Kontent source plugin fulfilling “first-class source plugin“ requirements
  • https://www.gatsbyjs.com/docs/integration-guide/source-plugin/

Additional context

Internal link: https://kentico.atlassian.net/browse/DEVREL-319

Dummy items still required to query contentType

Brief bug description

According to v4, (specifically 4.1.0-beta6 and 4.1.0-beta1) there should be no need for dummy items as mentioned here. I attempted to remove them but I'm getting query errors mentioning Unknown field 'contentType' on type 'KontentItemXXX'. Currently putting dummy items back resolves this issue.

ex:

    fragment X on KontentItemXXX {
      contentType { system { codename } }
    }

Set up Schema definition for taxonomies

Motivation

Since there is support for taxonomy - it would be great to have support for schema definition for the taxonomies.

Proposed solution

Define the types in [type definition]https://github.com/Kentico/gatsby-source-kontent/blob/master/src/typeNodesSchema.js#L99) and extend createTypeNodesSchema method to includethese typer for taxonomies by buildObjectType Gatsby method and set it the proper taxonomy type name.

Additional context

https://rshackleton.co.uk/articles/learning-about-gatsby-schema-customisation-with-kontent-ai

Related to #1

Describe Gatsby preview beta testing process

Expected result

Summarize the process, how to test out the beta version of the Gatsby preview!

Additional context

Similarily as other CMS has

• https://www.gatsbyjs.com/docs/sanity/getting-started/
• https://www.gatsbyjs.com/docs/drupal/getting-started//
• https://www.gatsbyjs.com/docs/contentstack/getting-started/

Include path to upgrade instructions

Motivation

Kentico Gatsby Source plugin has been updated to V3. For users who are on an older version of the plugin, the path to upgrading can be confusing. For example, when I was on the previous version of the plugin, the documentation showed that the gatsby-node.js file should be formatted like so.

 `gatsby-plugin-react-helmet`,
    {
      resolve: `gatsby-source-kentico-cloud`,
      options: {
        deliveryClientConfig: { // Configuration object
          projectId: `XXXXXXXXXXXX`,
          typeResolvers: []
        },
        languageCodenames: [ // example configuration
          `en-US`, // default language
          `es-ES`,
        ]
      }

And now it looks like this

    {
      resolve: `gatsby-source-kentico-cloud`,
        options: {
          deliveryClientConfig: {
            projectId: `d3a86fe3-a9c8-00cf-f963-f16f97806550`
          },
          languageCodenames: [
            `default` 
          ]
      }
    },

So it's no longer necessary to use gatsby-plugin-react-helmet. At least that's my assumption that I made after looking over this article you posted in Discord.

https://www.gatsbyjs.org/docs/sourcing-from-kentico-cloud/

Proposed solution

There should be a section in the readme.md file that is specific to people who started using the plugin before V3 and want to update.

Additional context

Allow to pass configuration onject in gatsby config

Motivation

Currently, it is not possible to configure i.e. preview feature.

Proposed solution

An ideal solution for the above problems would be to allow to pass the whole config object to the configuration.

Sample config for gatsby plugin after the feature is implemented:'

      options: {
        config: {
          projectId: 'XXX',
          enablePreviewMode: true,
          previewApiKey: 'YYY'
        },
        kcLanguageCodenames: [
          "default"
        ]
      }
```

### Additional context

Add any other context, screenshots, or reference links about the feature request here.
* https://github.com/Enngage/kentico-cloud-js/blob/master/doc/delivery.md#preview-mode
* https://developer.kenticocloud.com/docs/previewing-content-in-a-separate-environment
* https://developer.kenticocloud.com/reference#delivery-api