1.3.17

Cambio de infraestructura, no de base de datos. Esta versión saca al plugin
del servidor legacy app.dbmvs.com: updates, espejo de TMDb y licencias
pasan por completo a la API de producción (edge.wupdater.com/v1).

⚠️ Propagación: los sitios que corren 1.3.16 o anterior tienen el updater
VIEJO, que pregunta a app.dbmvs.com. No verán una 1.3.17 publicada solo en
la API nueva. Ver ## Despliegue.

La 1.3.16 cerró el hub de licencias. Esta versión termina de cortar el cordón con
el servidor legacy y trae al plugin dos cosas que vivían fuera de él: la
filmografía (que estaba en el theme) y un censo de instalaciones. También arregla
un heartbeat de licencias que llevaba más de un año sin latir de verdad.

El canal de actualización deja el servidor legacy

Era el último consumidor vivo de la constante DBMVS_API_URL (app.dbmvs.com).
DbmoviesUpdater::make_api_request() posteaba a app.dbmvs.com/licenses/updater
y esperaba un objeto PHP serializado (formato estilo EDD). Todo el resto del
licenciamiento (activate/check/deactivate) ya corría por DOOTHEMES_API desde la
1.3.15; solo el transient de updates seguía anclado al legacy.

Ahora check_for_updates() y fetch_plugin_info() consultan
POST edge.wupdater.com/v1/license/updates con JSON y las credenciales de la
licencia {license_key, hash, domain, product_slug, current_version}, según el
contrato de app.doothemes/docs/license-api.md. make_api_request() se eliminó;
en su lugar update_request() reusa api_post() —el mismo transporte que
activate/check, con _network para no degradar estado— con un timeout corto (10s)
porque corre en cargas del admin. update_item() arma el objeto del transient.

Decisión de criterio: solo se ofrece update con versión mayor Y package
presente. Si el servidor no tiene el zip en disco (package:null), no se lanza
a WordPress a una descarga que fallaría; se registra no_update y listo.

La constante DBMVS_API_URL quedó eliminada del código (cero referencias).

El espejo de TMDb, acotado al servidor y al panel

El proxy de TMDb migró al espejo nuevo (edge.wupdater.com/v1/tmdb y
/tmdbimg/{token}), que el servidor entrega en las respuestas de activate/check
y renueva el token de imágenes (TTL 7 días) en cada heartbeat. Es opt-in: solo
se usa si el operador enciende el switch en el importador.

Lo importante es dónde no se usa. El espejo de imágenes toca únicamente el
lado servidor (importación) y el panel de importación. El front nunca pasa por él:
las imágenes del sitio salen de la librería de medios o del CDN que el cliente haya
configurado. Rutear el front por el espejo, con sitios de decenas de miles de
vistas, serían cientos de miles de tránsitos por sitio contra nuestra
infraestructura — un tiro en el pie. dbmovies_cdn_image_url() y
dbmovies_get_image_featured() lo excluyen a propósito.

La filmografía se muda al plugin

Los créditos de una persona (su filmografía) los resolvía el theme, y versionaba
su caché guardando claves wovie_person_credits_v_* en la tabla options — más de
diez mil filas en un sitio con catálogo. El versionado de caché no va en options.

Ahora la capa de datos vive en el plugin (includes/functions/persons.php): el
versionado de caché usa termmeta (que WordPress limpia solo al borrar el término),
un grupo de object cache propio, y un filtro (dbmovies_person_credit_render_callback)
para que el plugin sea dueño de los datos/consulta/caché y el theme siga siendo
dueño del HTML. La migración de base de datos (v1.0.26) purga las filas viejas de
options en la actualización.

Acoplamiento con el theme: el theme delega en esta capa desde su commit de
persons. Un plugin 1.3.17 con un theme que todavía tiene la implementación vieja
seguiría escribiendo las filas en options. Ver ## Despliegue.

El heartbeat que no latía fuera del admin

includes/updater.php se cargaba solo dentro de is_admin(). Pero wp-cron.php
se ejecuta como una petición de front, así que el cron dbmovies_auth_client
disparaba y solo corría CronManager::track_last_run —que lo marcaba "exitoso"—
sin que el handler real de revalidación estuviera siquiera cargado. El bug entró el
2025-06-07 y vivió más de un año: el panel decía que el heartbeat corría, y no
revalidaba nada.

Ahora el updater se carga también en contexto de cron y WP-CLI. El heartbeat vuelve
a pegarle al servidor: refresca límites, owner_email, y renueva el token de
imágenes del espejo.

Runtime sync: censo de instalaciones

Se añadió DbmoviesRuntime (includes/controllers/DbmoviesRuntime.php), un módulo
que reporta la instalación al servidor una vez por hora. Envía dominio,
admin_email, IP del servidor y un identificador que el servidor emite en el primer
contacto; el servidor puede responder con una key, y con órdenes manuales de un
operador (notify para mostrar un aviso de licencia en el admin, deactivate para
desactivar el plugin). Es estado, no eventos: se reevalúa en cada respuesta.

Es autónomo a propósito: endpoint y product hash van embebidos, no salen de las
constantes de red del updater, para no romperse cuando esas se muevan y para no
acoplarse al ciclo de licencias. No aparece en el gestor de crons (es mantenimiento
interno, no una tarea del operador del sitio). Ante cualquier fallo de red no toca
nada: una desactivación no puede nacer de un DNS caído.

La divulgación de lo que se recoge (dominio, email de admin, IP) vive en el
readme.txt, que viaja en el ZIP de distribución (los .md del repo están
export-ignore).

Verificación

Contra el servidor real, solo lectura, sin descargar el paquete:

• edge.wupdater.com/v1/license/updates responde JSON. Con key inválida:

{success:false, code:invalid_key} → update_request() retorna null (fail-safe,
no ofrece update).

• Con la licencia real del sitio (wovie.io, active, vitalicia): `success:true,

version:null → al día. Declarando current_version=0.0.1 el canal **entrega**:
version 1.3.16, checksum, size 1367736, changelog HTML y package` con
token firmado. La cadena completa (auth → entitlement → versión + paquete) queda
confirmada.

• El endpoint legacy (app.dbmvs.com/licenses/updater) sigue respondiendo 200 con

objeto serializado: el canal viejo aún vive, dato clave para la propagación.

php -l limpio en los archivos tocados; cero referencias a DBMVS_API_URL.

Despliegue

Bump a 1.3.17 en el header del plugin y en DBMVS_VERSION. Publicar el zip de
distribución como asset del release de GitHub — es de ahí de donde la API de
producción resuelve la última versión:

https://github.com/doothemes/dbmovies/releases/download/1.3.17/dbmovies-1.3.17.zip

Dos condiciones que no son opcionales:

1. Canal legacy, por única vez. Los sitios en 1.3.16 y anteriores tienen el

updater viejo, que solo consulta app.dbmvs.com/licenses/updater. Para que
reciban 1.3.17 hay que servir este zip también por el canal legacy. Recién
cuando la flota esté en 1.3.17 hablarán con edge.wupdater.com, y ahí sí se
puede apagar app.dbmvs.com. Apagarlo antes deja a los sitios existentes sin
auto-update hacia esta build.

1. Theme en lockstep. El cambio de filmografía está partido entre plugin y

theme: el plugin 1.3.17 provee la capa de datos y el theme la consume. Un plugin
1.3.17 con un theme viejo seguiría poblando options con las claves de caché de
persons (el theme viejo no usa el filtro nuevo). El theme (wovie 1.2.16) debería
salir junto con esta versión, y su nota marcar que requiere plugin ≥ 1.3.17.

Las licencias ya activadas conservan su estado; el primer check posterior a la
actualización revalida y renueva el token del espejo. La migración de options
(persons) corre sola, sin intervención.

Changelog

This release moves the plugin off the old Doothemes server. Updates, the TMDb
mirror and license checks now run through the production service, and cast and
crew filmographies are handled by the plugin itself.

What's new

• TMDb mirror — When your server cannot reach TMDb directly, the importer can

pull metadata and images through the Doothemes mirror. It is off by default and
used only during import and in the admin; the public site never routes through it.

Improvements

• Cast and crew filmographies now load from the plugin with their own cache. Person

pages are faster, and the database stays clean instead of filling up with per-page
cache entries.

• Updates and license checks now go through the Doothemes service directly, with no

intermediate server in between.

Fixes

• The periodic license check only ran inside the WordPress admin, so a site with

little admin activity could stop revalidating its license and refreshing its
limits. It now runs on schedule regardless of admin traffic.