92f092dcc4cce26da41764fee33b9b428658bbb3
`header.php` tenia un `if (1)` hardcodeado que se saltaba entera la comprobacion
de "pagina publicada". Para produccion se habia empezado a mantener una copia
`header.php.prod` que comentaba esas lineas con `#`.
ESA COPIA ESTABA MAL Y HABRIA TUMBADO TODAS LAS WEBS
Al comentar el `if(1){...}else{`, el cuerpo del `else` pasaba a ejecutarse SIEMPRE:
visitante normal, web PUBLICADA -> die(mantenimiento)
Es decir, cualquier visitante sin sesion `?pruebas` recibia la pagina de
mantenimiento aunque la web estuviera publicada. Verificado ejecutando las dos
versiones. Nadie lo vio porque un `.prod` **solo corre en produccion**: no hay
forma de que ese fallo aparezca antes de estar desplegado.
Ese es el argumento de fondo contra el enfoque `.prod`, mas alla de la
duplicacion: el camino de produccion no se puede probar. Con la condicion en
tiempo de ejecucion se ejercita en local escondiendo el `.acai` un segundo — que
es como se ha verificado este commit.
LA CONDICION, AHORA EXPLICITA
local -> siempre se ve (ahi no existe ni "publicada"
ni ?pruebas: son conceptos de produccion)
prod + publicada -> se ve
prod + sin publicar + ?pruebas -> se ve, con el cartel rojo
prod + sin publicar + visitante-> mantenimiento
DONDE VIVE `esEntornoLocal()`, QUE COSTO TRES INTENTOS
La señal es la PRESENCIA del `.acai` en la raiz: Forge lo escribe en cada copia
local y NUNCA viaja a produccion (esta en el `exclude` del manifest de push-core
y fuera de la allowlist del sync per-web). Se detecta LOCAL explicitamente y todo
lo demas es produccion: si la señal fallara, el comportamiento seguro es respetar
`pagina_publicada`.
Va en `funciones.php` y no en:
- `cms/` -> se sobrescribe al actualizar el core desde el CMS legacy
- `lib/variables.php`-> viaja en el sync PER-WEB (es el unico fichero de raiz que
lo hace), asi que cada web sobrescribe esa copia: una
funcion del nucleo ahi es la proxima divergencia
- un plugin -> `TokenGuard::isLocalTest()` hace esto mismo, pero el
nucleo no puede depender de que un plugin este cargado,
y builder_saas publica solo al editarlo
`funciones.php` es CORE (viaja en el manifest de push-core, como `header.php`) y
lo carga todo el front antes de usarlo.
VERIFICADO sobre una web real (cdn-ecommerce-base), no en un test aislado:
con .acai -> HTTP 200, 78104 bytes, la web entera, sin mantenimiento
sin .acai -> HTTP 200, 1943 bytes, pagina de mantenimiento
Sintaxis comprobada con el PHP 8.3 de Plesk, que es el del hosting.
OJO AL DESPLEGAR: esto hace que la pagina de mantenimiento EMPIECE A FUNCIONAR de
verdad. Hoy el `if (1)` la desactiva en todas las webs, produccion incluida, asi
que cualquier web con `pagina_publicada = 0` se esta viendo entera. Al llegar este
cambio, esas webs pasaran a mostrar mantenimiento — que es lo correcto, pero es un
cambio visible.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019gLX53DZJXGPFCf6DJTPWQ
acai-vscode-webbase
Plantilla base PHP para webs locales de desarrollo con Acai CMS.
Descripcion
Este repositorio contiene la estructura base que se usa al crear nuevas webs locales. Incluye los archivos PHP necesarios, configuracion de Apache, y la estructura de directorios del CMS.
Estructura
.
├── index.php # Punto de entrada
├── header.php # Encabezado
├── footer.php # Pie de pagina
├── funciones.php # Funciones globales
├── slug.php # Gestion de URLs
├── sesion.php # Gestion de sesiones
├── apartados.php # Gestion de apartados
├── captcha.php # Verificacion CAPTCHA
├── .htaccess # Config Apache
├── .user.ini # Config PHP
├── .docker/ # Config Docker (Dockerfile, etc.)
├── cms/ # Core del CMS
│ ├── lib/ # Clases, handlers, plugins
│ ├── data/ # Schemas y cache
│ └── uploads/ # Archivos subidos
├── hooks/ # Hooks PHP del proyecto
├── template/ # Plantillas y modulos
└── cgi-bin/ # Scripts CGI
Relacion con el servidor
El servidor (acai-vscode-server) referencia este directorio como WEB_BASE_DIR para copiar la estructura base al crear nuevas webs locales. Se configura en ~/.docker-web-gui/config.json como web_base_dir.
Languages
PHP
91.4%
JavaScript
5.8%
Go Template
2%
SCSS
0.7%