You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When creating a new page with related objects (using modelcluster.fields.ParentalKey), the last page in the translated siblings does not have the related item - it appears that the original language page id is incorrectly saved.
How to reproduce?
Add an InlinePanel to a page model, with a related page as a foreign key item. When saving the canonical language page, all pages should have identical inline panel objects, with relations to the same page.
In my en, fr, es setup, only the the en and fr pages end up with the correct items.
This applies to any InlinePanel field, and is consistent everytime.
To understand what is going on, I have added print statements to a local copy of Wagtail, here are my findings:
The primary_related_items dictionary is as expected - the related field is the selected page, the item is the parental key to the new page (page_id: 8243), and the pk is the new clusterable modal instance pk.
Again, the primary_related_items dictionary is as expected - the related field is the selected page, the item is the parental key to the new page (page_id: 8244), and the pk is the new clusterable modal instance pk.
However, once everything is saved the item in the second primary_related_items is wrong - it is a reference to the canonical page, and the canonical page does not have appear to have created its own entry - it has taken over the seond language's.
E.g. the item value in the row of pk86 is 8242 - the id of the canonical page, instead of the second translated Spanish page.
This feels like some kind of race condition to me, as if the canonical page is being saved after the translated copies, and is therefore messing up child object relations.
Technical details
Python, django, wagtail and wagtailtrans version
Python 3.8.5
Wagtail 2.10
Wagtailtrans 2.2
Django 3.1
The text was updated successfully, but these errors were encountered:
Issue summary
When creating a new page with related objects (using
modelcluster.fields.ParentalKey
), the last page in the translated siblings does not have the related item - it appears that the original language page id is incorrectly saved.How to reproduce?
Add an InlinePanel to a page model, with a related page as a foreign key item. When saving the canonical language page, all pages should have identical inline panel objects, with relations to the same page.
In my
en
,fr
,es
setup, only the theen
andfr
pages end up with the correct items.This applies to any
InlinePanel
field, and is consistent everytime.To understand what is going on, I have added print statements to a local copy of Wagtail, here are my findings:
This output is from the
latest_revision = page_copy.get_latest_revision_as_page()
call here: https://github.com/wagtail/wagtail/blob/stable/2.10.x/wagtail/core/models.py#L1494First translation: French
The
primary_related_items
dictionary is as expected - therelated
field is the selected page, theitem
is the parental key to the new page (page_id: 8243
), and thepk
is the new clusterable modal instancepk
.Here's the second page.
Second translation: Spanish
Again, the
primary_related_items
dictionary is as expected - therelated
field is the selected page, theitem
is the parental key to the new page (page_id: 8244
), and thepk
is the new clusterable modal instancepk
.However, once everything is saved the
item
in the secondprimary_related_items
is wrong - it is a reference to the canonical page, and the canonical page does not have appear to have created its own entry - it has taken over the seond language's.E.g. the
item
value in the row ofpk
86
is8242
- theid
of the canonical page, instead of the second translated Spanish page.This feels like some kind of race condition to me, as if the canonical page is being saved after the translated copies, and is therefore messing up child object relations.
Technical details
The text was updated successfully, but these errors were encountered: