Not able to build an Entry with locale=* and benefit from locale fallback

[pugbyte]

Hello,

I'm trying to build an Entry with locale=* and then output that Entry by using Entry->all() with the non-default locale. I expected this to work, but to my dismay it actually throws an InvalidArgumentException. The problem is here, in Resource/Entry.php:

// getUnresolvedField
if (\array_key_exists($locale, $value)) {
    return $value[$locale];
}
if (!$field->isLocalized()) {
    throw new \InvalidArgumentException(\sprintf(
        'Trying to access the non-localized field "%s" on content type "%s" using the non-default locale "%s".',
        $field->getName(),
        $this->sys->getContentType()->getName(),
        $locale
    ));
}
$locale = $this->walkFallbackChain($value, $locale, $this->sys->getEnvironment());

As you can see, the SDK checks to see if a field is marked as localizable before it attempts to walk the fallback chain for locales. This makes it impossible to build (and more importantly: PSR-6 cache) an Entry object with all locales and then output it in one locale, forcing me to make an API call for each locale for a given Entry ID.

Is there a chance that this behaviour could be revised?

[pgrigoruta]

Andre Jodat-Danbrani (@pugbyte) , can you provide a simple code example that showcases the problem?

[pugbyte]

Sure, I'll do my best to provide an example. Imagine you have a Content Model with two fields: greeting and greeterName. greeting is marked as localizable, greeterName is not. Imagine there's an Entry using this model and it had ID 123abc. Your Contentful Space's default locale is English, but you also have the French locale available, and French is configured to fall back on English. Entry 123abc has the following content:
greeting: "hello" (english locale)
greeterName: "Lorraine" (not localizable)

$myEntry = $client->getEntry("123abc", "*");
$frenchGreeting = $entry->get("greeting", "fr"); // returns "hello" because it did a fallback on English
$frenchGreeter = $entry->get("greeterName", "fr"); // throws an InvalidArgumentException because greeterName is not a localizable field

My example is contrived, but I think it's enough to illustrate the problem. My expectation was that $entry->get("greeterName", "fr"); would return "Lorraine", but instead the SDK throws an error because I tried to access a field that was marked as non-localizable with a non-default locale parameter. I expected it to try falling back on English first.

Does that help? Please don't hesitate to reach out if you need any more information 🙂

[pgrigoruta]

Thanks Andre Jodat-Danbrani (@pugbyte) , this makes it clear. We discussed about this change internally and we decided not to merge it in core as it might be a breaking change for other clients. We also want to keep a consistent behavior between all our other libraries, so if we ever change it, we will do it in all libraries at once.

However, feel free to check my commit at b439e0f and fork the library if this behavior is good for you.

[pugbyte]

That's understandable, no worries. Thanks for taking the time to look at it.

[michaelLoeffelmann]

I have the same issue at the moment. Is it planned to update the behaviour in the SDK or is there an workarround for that?

[Sebb767]

Hi @LrMiLoef ,

for now, this change is not planned. However, I might be able to add a flag for that behavior.

[michaelLoeffelmann]

That would be great, if you can do that. It would save me a lot of work and in my opinion it's a lot more intuitive.

[Sebb767]

Hi @LrMiLoef (and Andre Jodat-Danbrani (@pugbyte) , in case you still need this fix),

I tried to implement a non-breaking work-around for this. This consists of two parts. If you use Entry::all(), you can now use the third parameter to avoid the exception:

$result = $entry->all($locale, $resolveLinks, true);

If you access a specific field via Entry::get(), you can do it like this:

$result = $entry->get($name, $entry->isFieldLocalized($name) ? $locale : null);

For the reasons Paul stated changing the default behavior is not a good idea, but I hope this still enables your use-case :)

For now the changes are only in dev, but I will soon release them.

[Sebb767]

Closing this as the changes were already released with 6.2.0