[Page Statique v2] Ajout type Élément de Menu (`MenuItem`)

[marcantoinedupre]

Je propose d'introduire un nouveau type d'entité Élément Menu (MenuItem).

Objectifs :

• séparer les concepts actuellement portés par le modèle Page Statique
• implémenter l'arborescence de menu

séparer les concepts actuellement portés par le modèle Page Statique

L'implémentation actuelle du modèle Page Statique embarque plusieurs concepts différents :

• le label qui apparaît dans la barre de navigation ("titre").
• le contenu d'une page éditoriale : titre, contenu, cover image.
• définition d'une cible alternative (lien externe) au clic dans la barre de navigation plutôt que d'aller sur la page.

Ce travail d'ajout de fonctionnalités pour les pages statiques est l'occasion de séparer ces concepts et clarifier ce modèle. Le modèle Page Statique conservera uniquement le concept d'une page éditorial et de son contenu. Le nouveau modèle Entrée de menu (MenuItem) portera le concept d'une entrée de menu dans des menus arborescents avec une possible cible définie (page, lien interne ou externe, page des actualités).

implémenter l'arborescence de menu

Les objets Entrées de menu seront liées entre eux de façon arborescente, soit au moyen d'un champ "parent" ou avec l'implémentation fournie par une app Django comme django-treebeard ou django-mptt-admin. L'intérêt d'une app Django est de bénéficier d'une vue arborescente dans le AdminSite.

Maquette de l'interface admin: vues listes + formulaires

Pour l'arborescence suivante :

Types de contenu :

• P = Page
• L = Lien
• A = Page d'actualités

La destination
-- Le territoire (P)
-- -- Article territoire 1 (P)
-- -- Article territoire 2 (P)
-- -- Article territoire 3 (P)
-- Les actualités (A)
-- Agenda et animations du parc (L)
-- Blog (P)
-- -- Article blog 1 (P)
-- -- Article blog 2 (P)
-- -- Article blog 3 (P)
-- Se déplacer sur le territoire (L)
La randonnée à la journée
-- Inspirations (P)
-- -- Article inspiration 1 (P)
-- -- Article inspiration 2 (P)
-- Nos itinéraires (L)
Infos et bonnes pratiques (P)
À propos de la marque Territoire (P)

Et les pages hors-arborescence :

- FAQ
- Mentions légales

(fichier zip avec maquettes Excalidraw)

Champs de formulaire pour les modèles Page Statique et Entrée Menu

Inventaire pour donner une idée de la séparation entre les 2 modèles :

Champs de Page Statique (modèle FlatPage)

• published (par langage)
• titre (traduit)
• contenu (traduit)
• cover image
• cover image author
• sources
• portals
• attachments (en fait c'est la cover image ? Ou bien un champ support pour le tinymce ?)

Champs de Élément Menu (modèle MenuItem)

• parent
• label (traduit)
• type de cible/contenu : page, lien interne, lien externe
• order (ou position ?)
• portal
• cible (remplacer par "plate-forme"/"media"/"usage" ?)

Migration depuis l'existant

• les MenuItems sont créés automatiquement à partir des FlatPages puis liés à ces dernières
• si Page publiée sur plusieurs portails : 1 entité MenuItem créée pour chacun des portails

pas de rétro-compatibilité de l'API

• Étant donné que la section Pages Statiques de l'API est uniquement utilisée par GTR et Geotrek Mobile on pense qu'il est acceptable et préférable d'introduire un breaking change plutôt que d'entrer dans une rétro-compatibilité avec une stratégie d'obsolescence pour certains champs.
• Cela implique une stratégie de mise à jour conjointe entre GTA et GTR (le endpoint /api/v2/version pourrait être utile en plus de la documentation appropriée).
• Protection dans Geotrek Rando pour ne pas planter si un endpoint d'API est manquant ou pas à la bonne version
• Applications mobiles : n'utilise pas l'API mais la commande de synchro mobile sera à adapter
• pas de support pour Geotrek Rando v2 (commande synchro rando)

protections/contraintes

Certaines propriétés actuelles (visibilité, cible web/mobile, publication(?) ) devraient se propager du parent vers le bas de l'arborescence. Par exemple : ça n'a pas de sens d'avoir des Élément de Menu enfants visibles si le parent ne l'est pas. Je propose de limiter l'édition de certains attributs aux entités de premier niveau (c-à-d sans parent).

• on peut seulement modifier le portail sur un MenuItem de premier niveau (sans parent).
• on peut seulement modifier la plateforme cible (All, Web, Mobile) sur un MenuItem de premier niveau.

questions fonctionnelles

• que se passe-t'il en cas de dépublication d'une page ?
• permettre de cibler uniquement les pages publiées ?

[marcantoinedupre]

Implémentation d'une arborescence pour les pages

Suite discussion il est acté que les pages seront organisées dans une arborescence de pages. Il y aura donc deux arborescences d'entités : l'arborescence des menus et l'arborescence des pages.

La différence par rapport à la conception précédente est qu'une page ne pourra avoir qu'une seule page parente.

• L'objectif est toujours d'afficher automatiquement les pages enfants à la suite du contenu de la page sur le portail rando,
• l'arborescence rendra la hiérarchie des pages plus claire pour le visiteur et l'implémentation d'un fil d'Ariane est facilitée.

[marcantoinedupre]

Quelques éléments pour la migration [pages statiques] vers [pages v2 + menu items]

• Migration d'une page qui est mobile-only : création d'un menuitem avec mobile-only
• Migration d'une page hidden : pas de création de MenuItem, la page garde ses portals et sera donc retourné par l'API
• Migration d'une page non-publiée : pas de création de MenuItem

Si les 2 champs « Lien externe » et « Contenu » comporte des données idéalement la migration devrait être stoppée et l'anomalie remontée pour résolution préalable.

[marcantoinedupre]

Notes sur le champ « Cible »

• disparaîtra complètement de l'API : la notion de "hidden" est assuré par le lien ou non avec un MenuItem et l'API ne retournera que les éléments de menus avec les valeurs « All » ou « Web ».
• concernant /api/v2/flatpage/?portals=1,2 : retournera les pages associées directement aux portails 1 ou 2 OU indirectement via un menu associé à ces portails (et que la valeur plateforme cible de ce menu indique une diffusion via l'API).

[marcantoinedupre]

Notes sur la notion de page publiée

• un menu ne devrait pouvoir référencer que des pages publiées (pour éviter les liens cassés sur le portail rando).
• Côté menu : le champ de sélection d'une page cible affichera uniquement les pages publiées.
• Côté page : on pourrait imaginer un bouton « Cibler cette page dans un menu » dans le formulaire, cliquable uniquement si la page est publiée (pour un second temps, à prioriser).
• pour rester simple dans un premier temps je ne me soucie pas de dépublication. C'est une action qui n'est plus censée arriver. Au pire une page dépubliée provoquera une erreur « 404 - Page non trouvée » sur le portail.
• La notion de publication permet de préparer une page et son contenu sans qu'elle soit visible dans l'API. Contrairement à actuellement la publication ne contrôlera plus la visibilité de la page dans le header (transféré aux menus).

[camillemonchicourt]

Fait dans la 2.104.0 (nécessite Geotrek-rando 3.19+) avec la création d'un objet "Elément de menu" complémentaire aux pages statiques, et qui pilote donc le menu désormais. Voir doc : https://geotrek.readthedocs.io/en/latest/usage/static-pages.html