Page tree problems after translating including subtree

[leewesleyv]

When translating a page through the Wagtail admin (localize/submit/page/<page_id>) and including the subtree, the (translated) page tree is corrupt. The numchild value for the translated page stays 0, which causes the subpages to not appear in the Wagtail admin. I've been able to reproduce this on multiple Wagtail instances.

How to reproduce

On a fresh installation of Wagtail (using wagtail start), configure i18n using the Wagtail docs. Install wagtail-localize following the installation guide. Then perform the following actions:

• Add a new locale
• Add a subpage to the existing start page
• Translate the start page for the newly added locale, including subpages

[zerolab]

Hey @leewesleyv,
Thank you for reporting this. Which versions of wagtail-localize/Wagtail are you on?

[leewesleyv]

@zerolab

Currently using the following versions:

wagtail==5.2.3
wagtail-localize==1.7

Besides these versions I've tried with main (of wagtail-localize) where the problem also seems to be present.

[danthedeckie]

Does running the ./manage.py fixtree help?

[leewesleyv]

@danthedeckie Running that command will indeed find and fix the problem (see 4th screenshot in #773 (comment)).

[zerolab]

By way of update: I was hoping to get to it last week, but I didn't get to it, sorry!

[zerolab]

I was able to replicate this. Working on a fix

[stevejalim]

Naively wondering if we can effectively run fixtree after the page copying process has run. Will see if I can make time to address it this way, as this is a blocker for us and I'm happy to help

[stevejalim]

Rummaging around, trying to pinpoint where the page tree goes awry.

I slotted in a call to wagtail.management.commands.fixtree.Command().handle() just a the end of form_valid to see if that would spot any issues with the tree just after the translations were made.

It appears not:

> /Users/steve/Code/wagtail-localize/wagtail_localize/views/submit_translations.py(164)form_valid()
-> ft_func()
(Pdb) ft_func()
Checking page tree for problems...
No problems found.

Checking page tree for problems...
No problems found.

Checking collection tree for problems...
No problems found.

INFO 2024-10-14 07:47:57,950 signal_handlers Creating redirects for page: 'REDACTED base route' id=45
INFO 2024-10-14 07:47:57,978 signal_handlers 0/0 redirects were created successfully.
INFO 2024-10-14 07:47:57,991 publish_revision Published: "REDACTED base route" pk=45 revision_id=156
INFO 2024-10-14 07:47:58,003 publish_revision Published: "Hello, World" pk=50 revision_id=158
INFO 2024-10-14 07:47:58,067 publish_revision Published: "test parent page" pk=51 revision_id=160
INFO 2024-10-14 07:47:58,082 publish_revision Published: "child of parent page" pk=52 revision_id=162

So now it's off to deeper in the stack, possibly in core wagtail(?)

If anyone else knows where this is being caused, please do say 😄

[zerolab]

Thank you for the investigation @stevejalim
Added to my list for this week.

[urlsangel]

@stevejalim

I've been having the exact same problem on a site that I'm developing, and I've successfully implemented the following, which solves it until it's fixed upstream (put this in signals.py or similar as per the docs):

from django.core.management import call_command
from wagtail.signals import page_published


def publish_page(sender, **kwargs):  
    call_command('fixtree')


page_published.connect(publish_page)

[stevejalim]

Thanks @urlsangel!
Out of curiosity, have you tried it with the copy_for_translation_done signal? I was just wondering whether that would trigger fixtree less often, but still at an appropriate point in time

[urlsangel]

@stevejalim

I haven't, as I wasn't aware that signal existed 😅

I'll try that implementation when I get back on the project - it's still in development, so it would be good to respond to a signal like that rather than the page_published one each time.

Thanks for the tip! 🙏

[stevejalim]

@urlsangel Fingers crossed that it works - it might be sent slightly before the tree gets mangled (I don't know), but here's hoping it's a lighter-touch workaround, yeah!

[urlsangel]

@stevejalim

Just tried with the copy_for_translation_done signal, and no joy I'm afraid, so have reverted back to page_published.

Shame, as copy_for_translation_done would be a much better place to handle the signal 😞

[stevejalim]

Ah bad luck @urlsangel 😢 Thanks for letting me know, though!

Maybe there's something in the built-in hooks that might be more focused. I think it'll depend on knowing when exactly the tree gets messed up.

Maybe after_create_page or after-publish-page and after-publish-page where we could look at page in question (eg poke its revisions) to know whether the tree is likely to need fixing. A bit awkward, though