Dos cambios que van juntos porque atacan el mismo fallo: en las webs de Forge no
salia ni un correo.
1. LOS CAMPOS DEL PANEL AHORA SIRVEN PARA ALGO
La tabla `configuracion` lleva desde siempre email_smtp, email_host,
email_port, email_secure, email_username, email_password, email_from y
email_from_name... y no los leia NADIE. Aparecian solo en el schema: el panel
te dejaba rellenarlos, se guardaban en la BD, y el envio seguia usando los
defaults de la clase —con la contrasena VACIA— o lo que hubiera a mano en
lib/variables.php. Un formulario decorativo.
`cargarSmtpDeConfiguracion()` los vuelca sobre la clase cuando el check
email_smtp esta marcado y email_host tiene valor. Se llama desde send() antes
de enviar, no solo desde send_email().
El schema de `configuracion` es PER-WEB y no todas tienen esas columnas
(villagrancanaria no las tiene): se lee con @ sobre el array, asi que una web
sin ellas se comporta exactamente igual que antes.
2. FUERA EL PROXY
send_email_coco_proxy() mandaba a cocosolution.com/?sendQuantumEmail=1. Se
quita por dos motivos medidos hoy:
- Ese endpoint RECHAZA TODO. Probados seis formatos (JSON crudo,
form-urlencoded, anidado, y el payload cifrado por tres vias) y siempre
contesta {"error":1,"message":"Need SMTP data and Params"}, incluso con
smtp_data completo. Es decir: ninguna web de Forge ha podido enviar por
ahi, y eso es anterior a los cambios de hoy.
- No hace falta. El container alcanza los SMTP por su cuenta: verificado
contra smtp.gmail.com:465 y :587 y smtp.ionos.es:465, con banner 220.
PHPMailer conecta solo cuando $smtp = true.
Se va con el encrypt(), que solo usaba el proxy y en una linea que ya estaba
comentada dentro de esa misma funcion. Cero llamadas a ambas fuera de la
clase, comprobado en los cuatro arboles.
Verificado en cdn-ecommerce: con el check marcado, la traza pasa de
"smtp=no host=smtp.gmail.com pass=VACIA" a "smtp=si host=<el del panel>", y
PHPMailer intenta la conexion. Falta solo poner credenciales de verdad.
OJO, queda pendiente: send_email() devuelve NULL siempre, tanto si entrega como
si no. Un fallo de envio es hoy indistinguible de un exito.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El proxy no era prescindible: el container de las webs de Forge NO tiene MTA.
`which sendmail mail postfix ssmtp msmtp exim4` no devuelve nada y
`sendmail_path` apunta a /usr/sbin/sendmail, que no existe. Con $smtp = false
PHPMailer cae a mail() de PHP y ahi no sale nada, en silencio.
Medido sobre las webs de Forge:
26 configuran CocoEmail::$smtp = true propio -> enviarian igual
57 NO configuran SMTP -> se quedaban SIN correo
Entre esas 57 esta cdn-ecommerce, que es justo la web de pruebas. Se vuelve a
la version condicional: proxy cuando hay .acai (Forge/test) y directo cuando no
(legacy de produccion). Cubre los tres casos, porque el proxy reenvia con el
smtp_data que le llega en el payload, asi que las 26 con SMTP propio siguen
saliendo por su servidor.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El commit anterior dejaba el envio condicionado al entorno (proxy en local,
directo en produccion) para poder unificar el fichero entre los dos canales sin
cambiarle el comportamiento a nadie. Decision posterior: el proxy no hace falta,
asi que se adopta la version de core_client tal cual y se envia SIEMPRE directo.
Se van dos funciones con el, y ninguna deja huerfanos:
send_email_coco_proxy() POST a cocosolution.com/?sendQuantumEmail=1
encrypt() solo la usaba el proxy, y en una linea que ya estaba
comentada dentro de esa misma funcion
Comprobado antes de quitarlas: cero llamadas fuera de la clase en web-base, en
las 131 webs de Forge, en el CMS central y en core_client.
Con esto core_client y web-base quedan identicos: 0 ficheros de deriva fuera de
plugins/, que actualizacion.php se salta a proposito.
OJO al alcance: las webs de Forge pasan de enviar por el proxy a enviar
directo. Es el cambio que se buscaba, pero conviene confirmarlo con un envio
real desde una web local antes de darlo por bueno.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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>
