Preservar a ordem das subpáginas após edição

[Copilot]

O que esse PR faz?

Corrige o reordenamento das subpáginas de AboutScieloOrgPage (ex.: Sobre o SciELO) toda vez que uma delas era editada — a página recém-editada subia para o topo da listagem no admin do Wagtail, quebrando a ordem pré-definida pelos editores.

A causa raiz é o default do Wagtail Page.admin_default_ordering = "-latest_revision_created_at", que ordena os filhos no admin pelo timestamp da última revisão.

• Define admin_default_ordering = "ord" em HomePage e AboutScieloOrgPage, fazendo o admin listar os filhos em ordem de árvore (path), igual ao que o site público já exibe via get_children.
• Adiciona testes de regressão em core/home/tests.py.

class AboutScieloOrgPage(Page):
    subpage_types = ["home.AboutScieloOrgPage"]

    # Mantém a ordem manual (path) na listagem do admin, em vez do
    # default `-latest_revision_created_at` do Wagtail.
    admin_default_ordering = "ord"

Onde a revisão poderia começar?

core/home/models.py — atributo admin_default_ordering em HomePage e AboutScieloOrgPage.

Como este poderia ser testado manualmente?

1. No admin do Wagtail, abrir os filhos de uma página AboutScieloOrgPage (ex.: Rede SciELO).
2. Verificar que aparecem na ordem da árvore (mesma do site público).
3. Editar e publicar uma das subpáginas.
4. Voltar à listagem dos filhos: a subpágina editada deve permanecer na mesma posição (não sobe para o topo).
5. Conferir que a página pública (ex.: /pt-br/sobre-o-scielo/rede-scielo/) continua exibindo a mesma ordem.

Algum cenário de contexto que queira dar?

O comando import_about cria as subpáginas em ordem (menu_order) usando parent.add_child(...), o que define o path corretamente. O front-end usa page.get_children.live.public, que herda a ordenação por path do BasePageManager. O único ponto que ordenava por data de edição era a listagem do admin, que é onde os editores percebiam o problema.

Screenshots

N/A — mudança de ordenação no admin; não há alterações visuais no front-end.

Referências

• Wagtail: Page.admin_default_ordering
• wagtail/models/pages.py:421 (default -latest_revision_created_at)
• wagtail/admin/views/pages/listing.py:426 (suporte ao valor "ord")

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• www.scielo.org
  • Triggering command: /home/REDACTED/work/_temp/ghcca-node/node/bin/node /home/REDACTED/work/_temp/ghcca-node/node/bin/node --enable-source-maps /home/REDACTED/work/_temp/copilot-developer-action-main/dist/index.js (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Copilot]

Pull request overview

This PR fixes unintended reordering of AboutScieloOrgPage subpages in the Wagtail admin after edits by overriding Wagtail’s default admin ordering (latest revision timestamp) to use tree order ("ord"), aligning admin behavior with the public site’s path-based ordering.

Changes:

• Set admin_default_ordering = "ord" on HomePage and AboutScieloOrgPage to keep child listings stable in the Wagtail admin.
• Add regression tests asserting the ordering configuration on the relevant page models.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
core/home/models.py	Sets admin_default_ordering = "ord" on the relevant page types to preserve tree/path order in admin listings.
core/home/tests.py	Adds regression tests for the new admin_default_ordering configuration.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The import grouping/order here looks like it will be reformatted by isort (CI runs pre-commit with isort). Consider running isort or reorganizing imports so local-app imports (collection/journal/core.*) are in a single section and sorted consistently, rather than splitting core.home.* into a separate block.

Suggested change

	from core.users.models import User
	from journal.models import Journal, SciELOJournal
	from core.home.models import AboutScieloOrgPage, HomePage
	from core.home.views import _get_scielo_journals_data
	from core.home.models import AboutScieloOrgPage, HomePage
	from core.home.views import _get_scielo_journals_data
	from core.users.models import User
	from journal.models import Journal, SciELOJournal

[Copilot]

This test class only asserts model class attributes and doesn’t use the database; using django.test.SimpleTestCase instead of TestCase would avoid unnecessary DB setup and speed the suite (you’d also need to adjust the import at the top accordingly).

[Copilot]

These tests verify that admin_default_ordering is set, but they don’t actually exercise the regression scenario described in the PR (a subpage moving to the top of the Wagtail admin children listing after edit/publish). Consider adding an integration-style assertion that creates sibling pages, simulates an edit/publish to update latest_revision_created_at, and verifies the admin listing order remains tree/path-based.