Jordan DiazandClaude Opus 5
f81c5a26e1
Segundo intento. El primero (92f092d, revertido en9a4906e) metia una funcion `esEntornoLocal()` en `funciones.php` y la llamaba desde `header.php`. Tumbo villagrancanaria.com con un Fatal error nada mas desplegarse. POR QUE FALLO, QUE ES LO QUE HAY QUE RECORDAR **Cada web puede tener PERSONALIZADO cualquier fichero del core, y el sync lo respeta.** villagrancanaria tenia su propio `funciones.php` (38 KB frente a los 17 KB del nucleo: carga de modulos por AJAX, `dame_registros` en vez de `CocoDB::get`, globales propias). Al sincronizar recibio el `header.php` nuevo —que no estaba personalizado— y conservo su `funciones.php` viejo. Resultado: `Call to undefined function esEntornoLocal()`, fatal, pagina entera caida. Y lo hizo por el camino que no probe: las paginas de builder van por `slug.php` -> `builder_saas/controlador.php` -> `header.php`, que NO pasa por `funciones.php`. Yo verifique solo el camino de `index.php`. Conclusion de diseño: **no se puede añadir una funcion a un fichero del core y llamarla desde otro**. No hay garantia de que los dos lleguen a la misma web, y cuando no llegan el fallo es FATAL, no degradado. Una linea duplicada es preferible a una dependencia que el sync puede no entregar. QUE HACE AHORA `$esEntornoLocal = is_file(dirname(__FILE__) . "/.acai")`, en linea, sin funcion compartida ni includes. La señal es la presencia del `.acai`: 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, lo seguro es respetar `pagina_publicada`. local -> siempre se ve prod + publicada -> se ve prod + sin publicar + ?pruebas -> se ve, con el cartel rojo prod + sin publicar + visitante -> mantenimiento Sustituye a un `if (1)` hardcodeado que desactivaba la comprobacion entera, y al `header.php.prod` que se habia empezado a mantener y que ADEMAS estaba MAL: al comentar el `if(1){...}else{`, el cuerpo del else pasaba a ejecutarse siempre y un visitante de una web PUBLICADA recibia `die(mantenimiento)`. Nadie lo vio porque un `.prod` solo corre en produccion. VERIFICADO sobre webs reales y por LOS DOS CAMINOS, incluido el del builder: builder + local -> 403238 bytes, la web builder + prod publicada -> 403238 bytes, la web index.php + local -> 78104 bytes, la web index.php + prod sin publicar-> 1943 bytes, mantenimiento Cero fatal errors. Sintaxis con el PHP 8.3 de Plesk, 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 y pasara a mostrar mantenimiento. 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.