Hola a todos, buenos días, queridos expertos en WordPress.
Actualmente estoy depurando una instalación de WordPress donde encontré un caso límite interesante (y educativo) entre Apache, mod_rewrite y enrutamiento interno de WordPressy me encantaría escuchar cómo otros razonan sobre este límite.
Configuración (simplificada):
- Apache 2.4 (mod_rewrite habilitado)
- PHP 8.x
- WordPress (clásico, no Bedrock)
- Tipo de publicación personalizada
edih(registrado a través de CPT UI, configuración estándar) - WordPress predeterminado
.htaccessreescribir reglas
Síntomas:
/?p=123obras- El administrador de WP funciona
- Base de datos + PHP claramente bien
.htaccesscontiene la reescritura estándar de WPmod_rewriteesta cargado
Pero:
/foo/→ 403 Acceso denegado/foo/addsmart/→ 403- en algún momento incluso
/test.phpregresó 403
Lo que sugiere fuertemente que Apache bloquea las solicitudes basadas en rutas antes de que WordPress los vea.
Lo que hace que esto sea interesante para mí:
- Algunos razonamientos del lado del servidor esperan una regla de reescritura explícita para
/edih/ - Pero en WordPress, los CPT son nunca mapeado a través de reglas de Apache – solo a través del comodín →
index.php
Entonces la verdadera pregunta parece ser:
¿Dónde comienza exactamente el enrutamiento de WordPress y bajo qué configuraciones de Apache se puede omitir o bloquear por completo?
Estoy especialmente interesado en:
- apache
Require/Optionstrampas - Comportamiento mod_security/WAF con URL sin extensión
- casos donde
.htaccessexiste pero no se evalúa como se esperaba
Siento que esta es una de esas situaciones en las que “sólo se aprende cuando falla”, y me encantaría recopilar experiencias, modelos mentales y estrategias de depuración de otros.
Gracias de antemano y encantado de informarle sobre la causa raíz final una vez encontrada.
Esperamos saber de usted
saludos