El core viaja por dos canales que deberian ser iguales y no lo eran:
core_client -> webs legacy via el CMS, y web-base -> webs de Forge. Nadie los
sincroniza, asi que el mismo arreglo se hacia dos veces, por separado y con
implementaciones distintas.
Medida la deriva: 5 ficheros de classes/ (el resto eran plugins/, que
actualizacion.php se salta a proposito).
CocoDB.php, CocoDB_alias.php <- de core_client
Traen los guards `if (file_exists(...))`: si falta el alias o AcaiAPI,
CocoDB se declara igual con la implementacion legacy. Es degradacion
real para webs viejas y aqui no la teniamos. Se pierde la declaracion de
CocoDB_old, que no referencia NADIE en ninguno de los cuatro arboles.
AcaiAPI.php, CocoParser.php -> ya iban a core_client desde aqui
AcaiAPI resulto ser el MISMO codigo: 9252 tokens en ambos y 0
diferencias al ordenarlos. El bloque de auditoria de updatedDate estaba
colocado antes o despues del if($isInsert), y como ese bloque no escribe
en $record, las dos posiciones son equivalentes.
CocoEmail.php <- fusion, y la unica divergencia REAL
web-base mandaba SIEMPRE por el proxy y core_client SIEMPRE directo, asi
que el fichero no se podia unificar sin cambiarle el comportamiento a
media plataforma. Ahora el camino se elige por entorno con el mismo
criterio que header.php:81 (un .acai en la raiz = local), en linea y sin
depender de otro fichero.
Para las webs de Forge NO cambia nada: las 131 tienen .acai salvo dos
directorios abandonados de abril sin index.php ni cms/lib/classes, que no
llegan a ser webs. Verificado en villagrancanaria: home, listado y ficha en
200 sin un solo error PHP, listado renderizando y hook en 54 ms.
Con los dos arboles ya identicos, el paso siguiente es que el CMS legacy se
nutra de web-base y dejar de mantener dos copias a mano.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
