Multiple wysiwyg editors in same schema

[choffa]

Description

Hi

I am having some issues with the plugin and multiple wysiwyg editors. The issue arises when using multiple of the basic wysiwyg editor in the same schema. My problem is that when I edit one of them, the other's field resolves to null the next time I run gatsby develop. I have a custom resolver for the field as such (This should not be required, but was useful for debugging purposes, issue happens regardless):

resolve(source, args, context, info) {
  return context.nodeModel
    .getAllNodes()
    .find((node) => source.<field-name>___NODE === node.id)
  },
},

And debugging confirms that the resolver does not find a FlamelinkTextHtmlContentNode for <field-name>___NODE.

The even more confusing bit is that if I then run gatsby develop again and without running gatsby clean the FlamelinkTextHtmlContentNode resumes to exist i GraphiQL and using the resolver described above. However, this is not reflected in the corresponding page component, as I suspect Gatsby does not see any changes to the content and therefore does not re-run the page Query. Checking the React developer tools confirms this, as the data field is not updated in the component inspector.

Summary

1. Create schema with two vanilla wysiwyg editors field1 and field2
2. When updating field1 the FlamelinkTextHtmlContentNode corresponding to field2 disappears after restarting the development server
3. Restarting the development server again makes the node reappear in the GraphiQL interface but this is not reflected in the page component.
4. Running gatsby clean restores expected behaviour

Please let me know if you need any more information!

[gitdubz]

Hi @choffa, I have marked this and will have a look at as soon as possible, it seems to be related specifically to the cache, but I will have a look to make sure the data is as expected when editing content via the Flamelink interface.

Please feel free to contribute and create a PR for the issue if this is at all possible.

[choffa]

Update: The error appear to affect any schema with more than one child node type

I have done some further investigating and the error appears affect any schema that has more than one child node type. I have tested this with the following conditions now:

• A schema with 2 wysiwyg
• A schema with 1 wysiwyg and 1 field group
• A schema with 2 field group

Again the content does not appear anywhere on the first build after changing the CMS, not in the <field-key> or the child<type-name> fields on the schema type, nor in the all<type-name> query node.

[choffa]

Any updates on this @gitdubz ? Given the update above this is quite critical to our use of the plugin.

[dewetvdm]

I am replicating the suggested schemas and having a look into it.

Does the content appear when you make a change in the CMS and then run a clean build?

[choffa]

Yes it does.

[gitdubz]

Hi @choffa, working on the issue, think we have found the problem. For now the only workaround is the clean before a build every time unfortunately.

I will keep you posted, this might take a couple of days to resolve.

[choffa]

@gitdubz Any updates on this? Our client is very keen on having automatic publishing after CMS updates, and until this is fixed that is simply not possible (we use Gatsby Cloud for builds, which does not have an option to automatically clean before build).

[choffa]

@gitdubz Again, any updates or timeframe? I don't mean to bug you, but I would like to see this fixed so we can start using automatic builds again. You say you have been able to find the problem? If the issue is time, could you share your findings so I can take a look myself? Thanks! :)

[gitdubz]

Hi @choffa, sorry for taking so long to respond.

We will need to implement cache clearing when fetching data as mentioned here https://www.gatsbyjs.com/docs/creating-a-source-plugin/#caching-data-between-runs https://www.gatsbyjs.com/docs/build-caching/

It would need to be done here in these two files, when the node is created a cache object would need to be set, alternatively we could try to set a global cache key https://github.com/flamelink/gatsby-source-flamelink/blob/master/src/gatsby-node.js https://github.com/flamelink/gatsby-source-flamelink/blob/master/src/helpers/normalize.js

As for the automated builds, From the gatsby docs, they mention deleting the .cache folder before the build should also have the same result. would it be possible to add something like rm -rf .cache in your build process?

[leevi978]

Hi @gitdubz

How is the progress on this issue?