Hecho con Chinaski

Papelera

Cada eliminación en Chinaski aterriza primero en la Papelera. Una página, post, bloque, formulario eliminado, o cualquier otra cosa cubierta por la papelera, conserva su lugar en la base de datos con una marca de tiempo, desaparece de las listas, del admin y del sitio publicado, y vuelve exactamente como estaba con un clic, o la limpieza automática a los 30 días la borra. El contenido se pierde irrevocablemente cuando tú lo indicas desde la Papelera, o cuando pasan 30 días.

Qué está cubierto

Diez tipos de contenido comparten la Papelera: páginas, posts, bloques, snippets, categorías, formularios, medios, documentos, elementos de navegación, stacks. Eliminar una redirección, un token de diseño, una clave de API o un usuario no pasa por la Papelera; esas son acciones directas (usuarios, claves de API: eliminación verificada de inmediato; redirecciones: según su página). Si lo que eliminaste es un formulario, los campos del formulario y sus envíos se van con él; restaurar un registro destruido junto con un formulario no es posible desde la papelera.

La pantalla Papelera

Abre Trash en la barra lateral (una insignia de conteo en la navegación aparece cuando contiene elementos). Dos vistas:

  • Agrupada: cada tipo en su propia sección (páginas, posts, bloques, snippets, categorías, formularios, medios, documentos, navegación, stacks), listando el nombre del elemento, su tipo/idioma y cuándo fue eliminado.
  • Cronológica: todo intercalado, lo más nuevo primero, 50 por página.

En cada fila:

  • Restore: devuelve el elemento, exactamente como estaba (incluyendo su historial de revisiones).
  • Delete permanently: visible/permitido según el rol: páginas, posts, snippets, formularios, medios y documentos requieren un admin para eliminarse permanentemente; restaurar está disponible para cualquiera que pueda editar ese tipo de contenido.

Las operaciones en bloque se sitúan encima de cada sección: selecciona filas y elige Restore o Delete permanently: se aplican las mismas confirmaciones, incluidas las acciones de eliminación permanente sobre varios elementos.

Restaurar, con seguridad

Una regla te protege de errores de restauración: si ya existe un elemento activo con el mismo identificador, la restauración se rechaza en lugar de crear un duplicado. Los mensajes lo dejan claro: una página se restaura por slug+idioma ("a page with the same slug already exists in language …"), un bloque por nombre+idioma, los medios por nombre de archivo, los documentos por nombre de archivo. Resuelve el conflicto: renombra el elemento más nuevo, o elimínalo, y la restauración procede.

Lo que hace una restauración exitosa: el elemento vuelve a sus listas con todos los campos intactos, la acción queda en el audit log ("restored: name"), y se dispara un rebuild del sitio para que el contenido reaparezca en el sitio live de inmediato. (La única excepción: restaurar medios no reconstruye por sí solo, porque los medios no aparecerán en la salida hasta que una página vuelva a referenciarlos).

Restaurar y luego editar: los enlaces de restauración pueden llevar un parámetro de destino then=edit, un detalle de implementación para flujos automatizados, que la propia pantalla de papelera no emite actualmente.

Eliminación permanente

Dos salidas de la Papelera:

  • Manualmente: "Delete permanently" en una fila o en bloque; solo para admins en el caso de páginas, posts, snippets, formularios, medios y documentos (los editores pueden restaurar pero no destruir). Destruir elimina el elemento, su historial de revisiones, y para los medios el archivo real en el disco; cada destrucción se audita ("permanent: name"), y le sigue un build del sitio (los medios son la excepción documentada, como arriba).
  • Automáticamente, después de 30 días. Una rutina de purga corre en cada arranque de la aplicación, y luego aproximadamente a diario en servidores de larga ejecución, eliminando permanentemente todo lo que haya estado en la papelera durante 30 días o más. La purga limpia las revisiones por lotes, elimina las filas dependientes (los envíos y campos de un formulario en la papelera se van con él), y nunca deja huérfanos. Las categorías no tienen historial de revisiones: solo la fila.

Si cambias de opinión después de la marca de 30 días, los respaldos son la última línea de defensa: restaura la base de datos desde un punto anterior a la eliminación.

Lo que la Papelera no cubre

  • Las redirecciones no se rastrean en la Papelera: eliminar una redirección la elimina (de todos modos, la volverías a crear en la pantalla Redirects en segundos).
  • Los tokens de diseño se editan en su lugar; eliminar uno es inmediato.
  • Los usuarios y las claves de API se eliminan de inmediato (según la página Users & Roles), no después de una etapa de reciclaje.
  • El registro 404, las ejecuciones de respaldo y los build logs antiguos se sitúan junto a la Papelera con sus propias reglas de limpieza (un tope rodante sobre las entradas antiguas: se conservan 50,000 filas de auditoría, 10,000 de auth, 5,000 de eventos y 1,000 de build log) en lugar de restauración por elemento.

Guía práctica

  • Elimina con intención; confía en la Papelera solo para los errores; no es un archivo de versiones (para eso están las revisiones).
  • La insignia en la barra lateral muestra cuántos elementos esperan; restaurar es mejor que eliminar permanentemente para cualquier cosa que no puedas volver a crear.
  • Los conflictos de restauración son informativos: el elemento más nuevo conserva el slug/nombre; resuélvelo renombrando el que llegó segundo.
  • Las páginas restauradas se reincorporan al sitio en exactamente la misma dirección que antes (los slugs vuelven a ser suyos tras una restauración sin conflictos); una página en la papelera que fue renombrada estando live conserva su comportamiento de redirección porque las redirecciones son registros separados.

La versión corta

Diez tipos de contenido, una Papelera compartida: eliminar → invisible, hasta 30 días para restaurar (con restauraciones verificadas contra conflictos que rechazan colisiones de nombres), eliminación permanente (admin para la mayoría de los tipos; limpia el historial), y una purga que respeta el ciclo nocturno y borra automáticamente las filas vencidas. Es la capa de seguridad entre un clic equivocado y lo perdido para siempre.

Lee este sitio en