Bug #105843
open
Language fallback broken for objectstorages
0%
Description
Language fallbacks currently don't work for objectstorages (and possibly other relation types too). Example use case:
- Post <1:n> Comment ("inline" relation in TCA, objectstorage in Extbase)
- Post records are localized (L=0 + L=1)
- Comment records are NOT localized (only exist in L=0)
- Site configuration "fallbackType" is "fallback" (with L=1 fallback to L=0)
Now showing a "Post" record in frontend in L=1, it doesn't show any related "Comment" records at all (when using $post->getComments()). Even when the "Comment" records are set to sys_language_uid = -1 they won't show up. As a workaround, instead of using $post->getComments() , i've added an own repository method $commentRepository->findByPost() like following:
class CommentRepository extends Repository
{
public function findByPost(Post $post): QueryResultInterface|array
{
$query = $this->createQuery();
$query->matching(
$query->equals('post', $post->getUid()) // This uid comparision is the important part!
//$query->equals('post', $post) // This fails
);
return $query->execute();
}
}
This way the fallback behaviour works fine! The important part here is, that the constraint must explicitly compare against the "uid" (using $post->getUid() ). The "magic" repository method findBy***() fails here, too, because it down't seem to compare against the "uid" internally.
So i guess, there are some parts in core where this kind of uid comparison is still missing.
Updated by Garvin Hicking 6 months ago
I've worked around this occassionally by using sys_language_uid=-1 here; then "all languages" is triggered more specifically.
(Not saying this issue here is [not] a bug, just stating another possible setuo)
Updated by Jan Kornblum 6 months ago
Garvin Hicking wrote in #note-1:
I've worked around this occassionally by using sys_language_uid=-1 here; then "all languages" is triggered more specifically.
Thats what i've already tried yesterday in v12. But even with "sys_language_uid=-1" that didn't work (see above).
Updated by Tymoteusz Motylewski 6 months ago
- Assignee deleted (
Tymoteusz Motylewski)
Updated by Jan Kornblum 5 months ago
- Related to Feature #94539: Documentation on how to work with 1:n and n:1 relations and translations added
Updated by Jan Kornblum 5 months ago
- Related to Bug #102336: Add support for localizing n:1 relations added
Updated by Jan Kornblum 5 months ago
- Related to Bug #89768: l10n_mode "exclude" does not work with inline type added
Updated by Jan Kornblum 5 months ago
- Related to Bug #90430: Language handling of bidirectional mm selects is not consitent. added
Updated by S P 6 days ago
Can confirm, sort of. I am on v13, my use-case:
Domain model with ObjectStorage relation to other entities of the same table.
When I am in FE L>0 context and do a findByUid() call, then Extbase overlays this exact object correctly, but the objects inside the ObjectStorage are all in L=0.
This also has the super-unintuitive side-effect that when doing two consecutive findByUid() calls (on different UIDs), that the second one can end up in L=0, because it already implicitly is in the persistence session when being fetched for the ObjectStorage of the first object!
Example: doing findByUid(1); findbyUid(2); gets object 1 in L>1 and object 2 in L=0, but if you do findByUid(2); findbyUid(1) it results exactly in the other way round - just because they are related by an ObjectStorage and whichever is called explicitly first gets correctly overlayed and the other one (being fetched implicitly by an ObjectStorage relation) is not overlayed.
Updated by S P 5 days ago
For anyone stumbling in here: In my case using #[Lazy] on the ObjectStorage did the trick.
Also, as a side-observation in #106483 another curious limitation of ObjectStorages came up (a model can not have a non-TCA ObjectStorage). It seems since v12 that ObjectSrorages in general are kind of broken.
Updated by S P 5 days ago
- Related to Bug #106483: Exception 1546632293 Could not get value of property [model] make sure the property is either public or has a getter added