Skip to content
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

Rich Text parse Linked Resource without locale specification #65

Closed
lamasfoker opened this issue Dec 1, 2022 · 1 comment
Closed

Rich Text parse Linked Resource without locale specification #65

lamasfoker opened this issue Dec 1, 2022 · 1 comment

Comments

@lamasfoker
Copy link

lamasfoker commented Dec 1, 2022

Steps to reproduce

  1. Create a Contentful Space with 2 locales: English (default) and Italian;
  2. Create an Entry Model "Blog Post" with a Body field of type Rich Text;
  3. Create a "Blog Post" Entry with an Image in the Body field, the same image for the English and Italian Body fields;
  4. The Image Asset has both title and description filled in both languages;
  5. Try to render the Blog Post Entry in the not default language (Italian)

Expected Result

The title of the image present in the Body of the Blog Post should be in Italian

Actual Result

The title of the image present in the Body of the Blog Post is in English

Considerations

The issue is in the use of the \Contentful\Core\Api\LinkResolverInterface Interface. The Mappers should pass also the locale code in the second argument $parameters.
The Mappers that use this interface are:

  1. \Contentful\RichText\NodeMapper\AssetHyperlink
  2. \Contentful\RichText\NodeMapper\EmbeddedAssetBlock
  3. \Contentful\RichText\NodeMapper\EmbeddedAssetInline
  4. \Contentful\RichText\NodeMapper\Reference\EntryReference
Sebb767 added a commit that referenced this issue Dec 22, 2022
This commit adds correct localization to richtext parsing. Previously,
the parser wasn't given a locale. This lead to bugs when the parser
attempted to resolve embedded entries or assets which were localized.
Note that this changes the ParserInterface and the NodeMapperInterface,
which means that this is a backwards-incompatible change and might need
adjustments for custom types.

See issue #65
@Sebb767
Copy link
Collaborator

Sebb767 commented Dec 22, 2022

This is resolved with v4.0.0 :)

@Sebb767 Sebb767 closed this as completed Dec 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants