-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Rich Text implementation in gatsby-source-contentful #25249
Conversation
679fd35
to
9c627fc
Compare
9c627fc
to
f69face
Compare
Gatsby Cloud Build Reportgatsby-master 🎉 Your build was successful! See the Deploy preview here. Build Details🕐 Build time: 1m PerformanceLighthouse report
|
f69face
to
14891dc
Compare
@axe312ger @wardpeet are we ready to release a canary version of this? |
@ben-rogerson yes, lets get it out into the wild and test it on a bigger scale :) |
099d0e8
to
246dd51
Compare
@axe312ger It seems the type name of the references is always using the contenttype I'm using the setting |
Hi @axe312ger, I know this is a little late in the game but one really useful feature to have in the plugin is the ability to customize locale fallback for assets. In Contentful, the fallback feature applies to all content (entries and assets). This almost never desirable and there doesn't seem to be any plans from them to make that configuration more granular. I noticed in the source plugin (based on 2.3.33) that there is a utility function used to fetch fields with a local fallback. I'm wondering if that can be fed some plugin config option. In the following example, assets that don't have a file set for en-gb will use the file value for en-us. module.exports = {
plugins: [
{
resolve: "gatsby-source-contentful",
options: {
getFallbackLocale: (nodeType, fieldName, locale) => {
if (
nodeType === "ContentfulAsset" &&
fieldName === "file" &&
locale === "en-gb"
) {
return "en-us";
}
},
},
},
],
}; The API is purposely abstracted to support not just assets but any Contentful node type. There are use cases to customise the fallback behaviour for other content types. Another example is that we store our translation phrases as entries in Contentful and if a phrase is defined in |
@disintegrator what you are asking for is a new, non-breaking feature. Can you please open a separate ticket for your feature request? |
@hoenderdaal thanks, good catch. I'll check what going on and republish a fix! |
Thanks for the nudge. #26094 |
@hoenderdaal should be fixed when #26102 is reviewed :) |
246dd51
to
c5bb85d
Compare
Current version published under |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's move forward with this :)
Published under |
Super excited for the launch! Thank you to everyone's hardwork on this! |
Published as |
🎉
…On Fri, 13 Nov 2020, 8:40 PM Peter van der Zee, ***@***.***> wrote:
Published as ***@***.***
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#25249 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAURW7WZQCDJFUA3UFKDNVTSPTPFFANCNFSM4OGOGYBQ>
.
|
This took me too long to find, so I'm going to add my error messages here. When you are following the migration guide:
You get an error like
And you can resolve the error by adding
|
Fail fast when rich-text and __typename not present at least while gatsbyjs#28528 is not finished. because figuring out what was wrong while migrating from v3 to v4, was a pain (gatsbyjs#25249 (comment))
@TjenWellens I adjusted the readme to include __typename in the example |
@axe312ger hey mate, the new plugin updates works like a charm on gatsby, but I cant yet figure out how to get the value for hyperlinks inside rich text. Using the below in my
|
Hey, this is how I've done, maybe it helps you out. ` [INLINES.HYPERLINK]: node => ( |
@mhedengren thanks mate, unfortunately, that used to work before they updated the package. Now it's different since |
@axe312ger looks like people are still running into this issue because the changelog entry has not been updated and is still missing the EDIT: submitted a PR: #29579 |
Changelog is updated now :) |
Hi @axe312ger I'm using |
@gusliedke it is documented in the changelog / migration guide, see: |
Spent 30 minutes trying to find why my references were not coming through the renderer only to find this thread. |
I know, thats unfortunate. I added that info everywhere I guess. The next version won't suffer from this anymore: #31385 |
This is a umbrella PR for the next major/breaking version of
gatsby-source-contentful
This branch is published tagged as
next
. Try it out in your projects:npm i gatsby-source-contentful@next
Features
Breaking changes / migrations:
If you are not using the
Rich Text
Contentful field type there are no breaking changes.Using Rich Text? Follow these migration steps:
Rich Text migration
raw
subfield instead ofjson
references
fieldresolveFieldLocales
option as the newreferences
field automatically resolves localesrenderRichText()
function fromgatsby-source-contentful/rich-text
Check this example code for a simple page template:
Example rendering code