API still returns defaultLocale value even when fallback is set to false
Link to reproduction
No response
Environment Info
Payload: 3.0.0-beta.109
Node: 10.2.4
Next: 15.0.0-canary.170
Describe the Bug
The defaultLocale value for localized fields is still returned even when the fallback value is set to false.
Reproduction Steps
- Create a collection.
- Add a localized field such as:
{
name: 'excerpt',
type: 'textarea',
localized: true,
},
- In your payload.config.ts add:
localization: {
locales: [
{ label: 'English', code: 'en-GB' },
{ label: 'Spanish', code: 'es' },
{ label: 'Dutch', code: 'nl' },
{ label: 'American', code: 'en-US', fallbackLocale: 'en-GB' },
],
fallback: false,
defaultLocale: 'en-GB',
},
In the frontend create a new page from your collection, give the defaultLocale a value, save and then switch to a different locale, check the API tab, you'll see the excerpt in the response.
Adapters and Plugins
mongo-db, s3-storage
My apologies here, closed the issue prematurely without waiting for the PR to be merged, it still hasnt!
Will review and get it merged this week
It also happens to me when I execute the find method with the Local API: although I specify "en-US", if the document doesn't exist, it returns the default locale document (which in my case is "it-IT").
This will be available in the next release, let us know if you encounter any issues with fallback locales and logic here.
🚀 This is included in version v3.0.0-beta.130
I tested with the following script
async function run() {
const payload = await getPayload({ config })
const pages = await payload.find({
collection: 'pages',
locale: 'en-US',
limit: 1
})
console.log(pages)
process.exit(0)
}
run().catch(console.error)
and if I specify the locale en-US I have still a document that doesn't exist in that locale.
{
docs: [
{
id: '66ceee6848cdfa7fb0544740',
title: undefined,
order: 0,
meta: [Object],
publishDate: '2024-08-28T09:30:04.240Z',
author: [Object],
slug: undefined,
breadcrumbs: [],
_status: 'published',
createdAt: '2024-08-28T09:31:20.609Z',
updatedAt: '2024-11-04T14:26:49.266Z',
alternates: [Object],
collectionType: 'pages',
content: [Object]
}
],
totalDocs: 27,
limit: 1,
totalPages: 27,
page: 1,
pagingCounter: 1,
hasPrevPage: false,
hasNextPage: true,
prevPage: null,
nextPage: 2
}
My localization setting in payload.config is the following, I don't even have the 'en-US' locale (I removed to avoid the problem).
localization: {
locales: ['it-IT'],
defaultLocale: 'it-IT',
fallback: false,
}
This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.
This issue has been marked as stale due to lack of activity.
To keep this issue open, please indicate that it is still relevant in a comment below.
This issue is still relevant. I tested now with the current version (v3.6.0).
These are my settings:
payload.config.ts
i18n: {
supportedLanguages: { it, en },
},
localization: {
locales: [
{ label: "Italiano", code: "it-IT" },
{ label: "English", code: "en-US" }
],
defaultLocale: "it-IT",
fallback: false,
},
collections: [Users, Media, Pages],
src/collections/Pages.ts
{
slug: "pages",
admin: {
useAsTitle: "title",
},
versions: {
drafts: {
autosave: true
},
maxPerDoc: 10,
},
fields: [
{
type: "text",
name: "title",
label: {
it: "Titolo",
en: "Title",
},
localized: true,
required: true,
},
{
name: 'content',
type: 'richText',
label: {
it: "Contenuto",
en: "Content",
},
localized: true,
}
]
};
If I run this code in src/app/my-route/route.ts
import configPromise from '@payload-config'
import { getPayload } from 'payload'
export const GET = async () => {
const payload = await getPayload({
config: configPromise,
})
const data = await payload.find({
collection: 'pages',
locale: 'en-US',
limit: 1,
fallbackLocale: false
})
console.log(data)
return Response.json(data)
}
The response is the following
{
"docs": [
{
"id": "675bedb72d0fee04cbcb8acf",
"breadcrumbs": [],
"meta": {
},
"_status": "published",
"createdAt": "2024-12-13T08:17:59.134Z",
"updatedAt": "2024-12-13T08:18:21.016Z"
}
],
"totalDocs": 1,
"limit": 1,
"totalPages": 1,
"page": 1,
"pagingCounter": 1,
"hasPrevPage": false,
"hasNextPage": false,
"prevPage": null,
"nextPage": null
}
@matteo-naif
The response is the following
I believe the response here is correct. Is this content with at least one published locale? Because if so the entire document will return as "published" since it has at least one locale in that state.
If this is not the case could you give me an example of content reproduction? This could be in the form of a seed script to run inside onInit in the payload config
I don't think this is correct. If I'm specifically requesting the list of documents with the en-US locale, the existence of a version with the it-IT locale should be irrelevant. The goal is to retrieve only the posts that are available in the en-US locale — regardless of whether they exist in other locales or not.
I found a workaround by adding an additional where filter to exclude items missing the required property (in my case, slug):
query Posts {
Posts(
locale: en_US,
fallbackLocale: none,
where: { slug: { exists: true } }
) {
docs {
title
slug
}
}
}
Not sure if related but to me it seems as if nested collections (depth > 0) will still use fallbackLocale even when disabled on the query
This issue got me as well for the last couple hours of debugging. I agree if I pass locale=es to the rest api, only docs that contain a valid es version should return. Going to add a fix similar to what @matteo-naif used.
Payload localizes fields not documents. I think the result you are getting back is accurate. If you would like to, you could add another field, i.e. a localized checkbox that you can toggle on/off for docs that are fully localized. Then you could add a where constraint like @matteo-naif did above on the slug field. Or you could just use a filter on a specific field like slug and it would filter out docs how you are expecting.
The expectation to filter out documents based on a field (or many fields) not having localized content is not correct since fields are localized not documents.
This issue has been automatically locked. Please open a new issue if this issue persists with any additional detail.