Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Preserve canonical content when a custom-layout move fails

Abierto
  • ¿Algo no está bien?
#260 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
php
Área
backend, databases

Línea de trabajo

Comienza en inc/class-wp-markdown-storage.php, en WP_Markdown_Storage::write_profile_post(), especialmente en la secuencia de movimiento de custom-layout alrededor de las líneas 910-924. Sigue el staging, la publicación en el destino, la limpieza de la ruta antigua, la indexación de rutas y los comprobantes de rutas modificadas; después añade cobertura determinista de fallos para la publicación, la limpieza y el reemplazo de directorios. La tarea estará terminada cuando se cumplan los criterios de aceptación sin pérdida de contenido, duplicados ni un estado final inconsistente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

The custom content-layout move path stages the replacement, deletes the old canonical file, and only then renames the staged file into place. If the final rename fails, the old file has already been removed and the staged file is discarded, leaving no canonical copy.

Relevant implementation: WP_Markdown_Storage::write_profile_post() in inc/class-wp-markdown-storage.php, around lines 910-924.

This violates the canonical durability contract required by the database-independent engine in #232.

Required outcome

  • Make custom-layout moves recoverable across the old-path and new-path publication boundary.
  • Preserve at least one complete canonical copy when publication or cleanup fails.
  • Bind staging and commit to the same verified destination directory identity.
  • Keep path indexing and changed-path receipts consistent with the terminal filesystem state.
  • Add deterministic failure injection around destination publication and old-path cleanup.

Acceptance criteria

  • A failed destination rename leaves the original canonical post intact.
  • A successful move leaves exactly one canonical post at the selected route and removes the stale route.
  • Retry after an interrupted move converges without content loss or duplicate durable identities.
  • Directory replacement between staging and commit fails closed.

AI assistance

GPT-5.6 Sol via OpenCode reviewed the custom-layout publication sequence, identified the delete-before-publish failure mode, and helped structure this issue and its acceptance criteria. Chris Huber directed the review and issue creation.

Lenguaje dominante
PHP
Estrellas
7
Forks
1
Merge medio
1 d 4 h
PR fusionados (30 d)
12

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Automattic/markdown-database-integration

Todos los issues de Automattic/markdown-database-integration

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.