Resolviendo errores 500 en Apache y automatizando la publicación de artículos

Escrito el por griquelme
Facebook Twitter WhatsApp LinkedIn

Estaba configurando mi mirror local de XAMPP cuando me topé con un error bastante molesto: varias direcciones específicas, como las páginas de categorías, devolvían un 500 Internal Server Error. Al principio, pensé que el problema residía en la configuración del VirtualHost o en alguna regla general de Apache. Sin embargo, tras inspeccionar los archivos, descubrí que el error real estaba muy cerca.

Log de error de servidor mostrando un bucle de redirección interna en Apache.
El log de Apache revelaba que las reglas de reescritura estaban creando un bucle infinito de redirecciones internas.

El log del servidor mostraba un mensaje claro y revelador: Request exceeded the limit of 10 internal redirects. Esto indicaba que Apache estaba atrapado en un bucle de reescritura. Al revisar mi archivo .htaccess, noté que las reglas de reescritura estaban configuradas para una ruta subcarpeta, lo cual no coincidía con la ubicación real del DocumentRoot.

La solución fue directa: corregí el bloque de WordPress en el .htaccess, asegurándome de usar una base de redirección correcta y manteniendo intacto el resto de las configuraciones. Una vez aplicado este cambio, las categorías volvieron a funcionar perfectamente.

Pero, mientras resolvía esto, me di cuenta de que mi flujo de trabajo para la gestión de contenido también necesitaba optimizarse. Quería poder publicar artículos en lote desde WordPress 4.7.29 sin tener que editar cada entrada manualmente. Inicialmente, el script PHP encargado de la publicación estaba asignando automáticamente la fecha actual a todos los borradores.

Archivo .htaccess corregido con reglas de reescritura apropiadas para WordPress.
La corrección en el archivo .htaccess resolvió el bucle y restauró el acceso a las categorías del sitio.

Esto no era ideal, ya que quería preservar las fechas originales de cuando se redactaron los artículos. Investigué y descubrí que el problema radicaba en mi script Python, crear_articulo_lmstudio.py. Este estaba escribiendo la fecha del sistema directamente en el archivo de datos.

Diagrama del flujo de datos desde el Markdown hasta la base de datos de WordPress.
El script Python ahora lee la fecha original del Markdown para evitar errores de sincronización en las publicaciones.

Decidí modificar únicamente ese script para que busque y extraiga la fecha original desde el encabezado del Markdown antes de generar cualquier archivo. Ahora, si el campo DATE falta o no coincide con el texto del archivo fuente, el script se detiene y muestra un error claro en lugar de publicar contenido desincronizado.

Ajustar tanto la configuración del servidor como los scripts de automatización ha hecho que mi entorno local sea mucho más robusto. Ya no tengo errores 500 por bucles de reescritura, y las publicaciones automáticas respetan el contexto temporal original de cada documento.