Skip to content

fix: localized fields within block references were not handled properly if any parent is localized#11207

Merged
AlessioGr merged 25 commits into
mainfrom
fix/block-references-localization
Feb 17, 2025
Merged

fix: localized fields within block references were not handled properly if any parent is localized#11207
AlessioGr merged 25 commits into
mainfrom
fix/block-references-localization

Conversation

@AlessioGr

@AlessioGr AlessioGr commented Feb 16, 2025

Copy link
Copy Markdown
Member

The localized properly was not stripped out of referenced block fields, if any parent was localized. For normal fields, this is done in sanitizeConfig. As the same referenced block config can be used in both a localized and non-localized config, we are not able to strip it out inside sanitizeConfig by modifying the block config.

Instead, this PR had to bring back tedious logic to handle it everywhere the field.localized property is accessed. For backwards-compatibility, we need to keep the existing sanitizeConfig logic. In 4.0, we should remove it to benefit from better test coverage of runtime field.localized handling - for now, this is done for our test suite using the PAYLOAD_DO_NOT_SANITIZE_LOCALIZED_PROPERTY flag.

Todo

Comment thread packages/db-mongodb/src/utilities/buildJoinAggregation.ts Outdated

@DanRibbens DanRibbens left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to add a function that returns field.localized && (process.env.NEXT_PUBLIC_PAYLOAD_COMPATIBILITY_allowLocalizedWithinLocalized === 'true' so that this nasty env variable isn't literred everywhere.

Comment thread packages/db-mongodb/src/create.ts Outdated
Comment thread packages/graphql/src/schema/buildObjectType.ts Outdated
Comment thread packages/payload/src/utilities/traverseFields.ts
Comment thread test/eslint.config.js
Comment thread test/localization/int.spec.ts Outdated
@AlessioGr AlessioGr dismissed DanRibbens’s stale review February 17, 2025 04:59

Done - added fieldShouldBeLocalized

@AlessioGr AlessioGr marked this pull request as ready for review February 17, 2025 05:01
@AlessioGr AlessioGr requested a review from denolfe as a code owner February 17, 2025 05:01
@AlessioGr AlessioGr enabled auto-merge (squash) February 17, 2025 19:14
@AlessioGr AlessioGr merged commit e6fea1d into main Feb 17, 2025
@AlessioGr AlessioGr deleted the fix/block-references-localization branch February 17, 2025 19:50
AlessioGr added a commit that referenced this pull request May 21, 2026
…AD_DO_NOT_SANITIZE_LOCALIZED_PROPERTY env var (#16693)

## BREAKING

Removes `config.compatibility.allowLocalizedWithinLocalized` and the
`PAYLOAD_DO_NOT_SANITIZE_LOCALIZED_PROPERTY` env var. Sanitize no longer
strips `localized: true` from fields nested under a localized parent -
`fieldShouldBeLocalized` decides this at runtime instead.

**Who is affected:**

- Users of `compatibility: { allowLocalizedWithinLocalized: true }`
- Anyone with `localized: true` nested under a localized parent - end
behavior is unchanged (Payload's own code already uses
`fieldShouldBeLocalized`), but `field.localized` is no longer being
deleted. Custom plugin/hook code that reads `field.localized` directly
will now see `true` where it previously saw `undefined`.

**How to migrate:**

- Remove the `compatibility` block from your config. If your Mongo data
still has the redundant nested-localized shape, flatten the config and
run a data migration
- Replace any direct `field.localized` reads in custom code with
`fieldShouldBeLocalized({ field, parentIsLocalized })` from
`payload/shared`.

## Why these existed

**`allowLocalizedWithinLocalized`**
([#7933](#7933)) was an
opt-out for the new auto-stripping behavior, aimed at pre-3.0 Mongo
users with data already written under nested-localized configs. Always
marked for removal in 4.0.

**`PAYLOAD_DO_NOT_SANITIZE_LOCALIZED_PROPERTY`** existed because of
block references. Blocks defined at the top of the config can be
referenced from both localized and non-localized parents, but sanitize
visits each block only once (`_sanitized = true`), so whichever parent
it sees first locks in the wrong answer for the other.
[#11207](#11207) fixed this by
moving the check to runtime via `fieldShouldBeLocalized({ field,
parentIsLocalized })`.

Whether we sanitize the localized properties away or not does not have
an impact on this functionality. However, we had to set
`PAYLOAD_DO_NOT_SANITIZE_LOCALIZED_PROPERTY` in our monorepo to test
against sanitization disabled, in order to guarantee correct runtime
handling through our tests.

Removing `PAYLOAD_DO_NOT_SANITIZE_LOCALIZED_PROPERTY` and making it the
default behavior ensures that the behavior users will encounter matches
what we have and test for in the payload monorepo.


---
- To see the specific tasks where the Asana app for GitHub is being
used, see below:
  - https://app.asana.com/0/0/1214980013153702
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants