Corbeille

Chaque suppression dans Chinaski atterrit d'abord dans la corbeille (Trash). Une page, un billet, un bloc, un formulaire supprimés (ou tout autre élément couvert par la corbeille) garde sa place dans la base de données avec un horodatage, disparaît des listes, de l'administration et du site publié, et revient exactement comme il était d'un seul clic, ou le nettoyage automatique après 30 jours l'efface. Le contenu devient irrévocablement disparu quand vous le dites depuis la corbeille, ou quand 30 jours s'écoulent.

Ce qui est couvert

Dix types de contenu partagent la corbeille : pages, billets, blocs, snippets, catégories, formulaires, médias, documents, éléments de navigation, stacks. Supprimer une redirection, un design token, une clé API ou un utilisateur ne passe pas par la corbeille : ce sont des actions directes (utilisateurs, clés API : suppression vérifiée immédiate ; redirections : selon leur page). Si c'est un formulaire que vous avez supprimé, les champs du formulaire et ses soumissions partent avec lui : la restauration d'un enregistrement détruit avec son formulaire n'est pas possible depuis la corbeille.

L'écran Corbeille

Ouvrez Trash dans la barre latérale (un badge compteur dans la navigation montre quand elle contient des éléments). Deux vues :

Groupée: chaque type dans sa propre section (pages, billets, blocs, snippets, catégories, formulaires, médias, documents, navigation, stacks), listant le nom de l'élément, son type/sa langue, et quand il a été supprimé.
Chronologique: tout entrelacé, du plus récent au plus ancien, 50 par page.

Sur chaque ligne :

Restore: remet l'élément en place, exactement comme il était (y compris son historique de révisions).
Delete permanently: visible/autorisé selon le rôle : pages, billets, snippets, formulaires, médias et documents exigent un administrateur pour être supprimés définitivement ; la restauration est disponible pour quiconque peut éditer ce type de contenu.

Les opérations en masse se trouvent au-dessus de chaque section : sélectionnez des lignes et choisissez Restore ou Delete permanently ; les mêmes confirmations s'appliquent, actions de suppression définitive sur plusieurs éléments comprises.

Restaurer, en sécurité

Une règle vous protège des erreurs de restauration : si un élément actif existe déjà avec le même identifiant, la restauration est refusée plutôt que de créer un doublon. Les messages le disent explicitement : une page se restaure par slug+langue (« une page avec le même slug existe déjà dans la langue … »), un bloc par nom+langue, un média par nom de fichier, un document par nom de fichier. Résolvez le conflit : renommez l'élément plus récent, ou supprimez-le, et la restauration passe.

Ce qu'une restauration réussie fait : l'élément revient dans ses listes avec tous les champs intacts, l'action est journalisée dans l'audit (« restauré : nom »), et un rebuild du site est déclenché pour que le contenu réapparaisse immédiatement sur le site en ligne. (La seule exception optionnelle : restaurer des médias ne déclenche pas de rebuild par lui-même, parce que les médias n'apparaissent pas dans la sortie tant qu'une page ne les référence pas à nouveau.)

Restaurer puis éditer : les liens de restauration peuvent porter un paramètre de destination then=edit : un raffinement d'implémentation pour les flux automatisés, non émis actuellement par l'écran corbeille lui-même.

Suppression définitive

Deux sorties de la corbeille :

Manuellement: « Delete permanently » sur une ligne ou en masse ; réservé aux administrateurs pour les pages, billets, snippets, formulaires, médias et documents (les éditeurs peuvent restaurer mais pas détruire). Détruire retire l'élément, son historique de révisions, et pour les médias le fichier réel sur disque ; chaque destruction est auditée (« permanent : nom »), et un build du site suit (les médias sont l'exception documentée, comme ci-dessus).
Automatiquement, après 30 jours. Une routine de purge s'exécute à chaque démarrage de l'application, puis environ chaque jour pour les serveurs de longue durée, supprimant définitivement tout ce qui a été jeté à la corbeille il y a 30 jours ou plus. La purge efface les révisions par lots, retire les lignes dépendantes (les soumissions et les champs d'un formulaire jeté partent avec lui), et ne laisse jamais d'orphelins. Les catégories n'ont pas d'historique de révisions : juste la ligne.

Si vous changez d'avis après le cap des 30 jours, les sauvegardes sont la dernière ligne de défense ; restaurez la base de données depuis un point antérieur à la suppression.

Ce que la corbeille ne couvre pas

Les redirections ne sont pas suivies dans la corbeille ; supprimer une redirection la retire (vous la recréeriez de toute façon dans l'écran Redirects en quelques secondes).
Les design tokens sont édités en place ; en supprimer un est immédiat.
Les utilisateurs et les clés API sont supprimés immédiatement (selon la page Users & Roles), pas après une étape de recyclage.
Le journal 404, les exécutions de sauvegarde et les anciens journaux de build se tiennent à côté de la corbeille avec leurs propres règles d'entretien (un plafond glissant sur les entrées anciennes : 50 000 lignes d'audit, 10 000 lignes d'auth, 5 000 lignes d'événements et 1 000 lignes de journal de build sont conservées) plutôt qu'une restauration par élément.

Conseils pratiques

Supprimez avec intention ; ne faites confiance à la corbeille que pour les erreurs ; ce n'est pas une archive de versions (ce sont les révisions qui servent à cela).
Le badge dans la barre latérale montre combien d'éléments attendent ; restaurer vaut mieux que supprimer définitivement pour tout ce que vous ne pouvez pas recréer.
Les conflits de restauration sont informatifs : l'élément plus récent détient le slug/le nom ; résolvez en renommant celui qui est arrivé en second.
Les pages restaurées rejoignent le site à exactement la même adresse qu'avant (les slugs leur reviennent après une restauration sans conflit) ; une page jetée à la corbeille qui avait été renommée pendant qu'elle était en ligne garde son comportement de redirection parce que les redirections sont des enregistrements séparés.

La version courte

Dix types de contenu, une corbeille partagée : supprimer → invisible, jusqu'à 30 jours pour restaurer (avec des restaurations vérifiées contre les collisions de noms qui refusent les doublons), suppression définitive (admin pour la plupart des types ; efface l'historique), et une purge respectant l'échéance des 30 jours qui efface automatiquement les lignes périmées. C'est la couche de sécurité entre un faux clic et la disparition à jamais.