Se añade la integración del script de Monetag (MultiTag: popunder + push + in-page
push + vignette) como alternativa a AdSense para monetizar sin depender de que
Google apruebe el sitio.
Tres interruptores (ver components/Monetag.tsx):
1. `MONETAG_SRC` + `MONETAG_ZONE` en el .env (no versionadas, documentadas en el
README). Cualquiera de las dos vacía = no se carga nada. Se leen en el servidor
y se pasan como props, así que encender/apagar es tocar el .env + reiniciar,
SIN rebuild. Ahora mismo van vacías: la integración queda instalada pero inerte
hasta que se pegue la zona del panel de Monetag.
2. El filtro común de publicidad, extraído a lib/ads.ts (`shouldServeAds`): fuera
para admins y para quien sea rango 2+ o haya pagado alguna vez. Antes esta lógica
vivía dentro de AdSense.tsx; ahora la comparten la etiqueta de AdSense y el
script de Monetag desde un único sitio, para que no se puedan desincronizar.
3. El consentimiento «Marketing» del banner, en components/MonetagScript.tsx
(cliente). A diferencia de la etiqueta de AdSense, MultiTag escribe cookies y
pide permisos, así que NO puede cargarse sin aceptar la categoría. Mismo patrón
que Analytics.tsx: useConsent reacciona en caliente, arranca en false.
El push de MultiTag necesitará además un sw.js servido desde la raíz del dominio
(public/sw.js, descargado del panel). Sin él, el resto de formatos funcionan igual.
Verificado: con las variables vacías la web queda idéntica (ni script de Monetag ni
cambios) y la etiqueta de AdSense sigue intacta. Con una zona de prueba, el filtro
de servidor deja pasar a anónimos y rango 1 sin pagos, y corta a los admins. Sin
consentimiento no se inyecta ningún <script> (la zona solo viaja como prop inerte
en el payload de React).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Se añade `<meta name="google-adsense-account">` al <head> de todas las páginas, que
es lo que pide Google para verificar la propiedad del sitio. OJO: esto NO muestra
anuncios ni carga adsbygoogle.js todavía; solo permite que Google confirme que el
dominio es nuestro y arranque la revisión.
TRES interruptores (ver components/AdSense.tsx):
1. `ADSENSE_CLIENT_ID` en el .env (no versionado). Vacío o sin poner = no se emite
nada. Documentada en el README. NO lleva prefijo NEXT_PUBLIC_ a propósito: la
etiqueta se pinta en el servidor, así que no hace falta exponerla al bundle ni
rebuildear para activarla/desactivarla, al revés que NEXT_PUBLIC_GA_ID.
2. Admin (ADMIN_EMAILS o gmlevel de AzerothCore): sin etiqueta, para que la
navegación del staff no cuente como tráfico con anuncios.
3. Rango de la cuenta (ns-ranks) Y pagos: solo ve anuncios el rango 1 (Newbie, el
de por defecto) que ADEMÁS nunca ha pagado.
Los dos cortes del punto 3 son distintos a propósito y no basta con mirar el rango:
el mínimo de SumUp son 0,20 €, que a 100 PD/unidad son 20 PD, y eso sigue siendo
rango 1. Mirando solo el rango, quien pagara el mínimo seguiría viendo anuncios,
que es justo lo contrario de lo que queremos.
Para no duplicar el SQL, las consultas de saldo y de total donado salen de
getAccountDashboard a dos helpers (`getPoints`, `getDonatedPD`) que reutiliza el
nuevo `getAccountRankInfo`, con las dos consultas mínimas en vez del panel entero
(personajes, baneos, correo…). El criterio de rango es el mismo que ya usaba
/my-account: el máximo entre lo donado y el saldo actual.
Verificado contra la web real: anónimo y rango 1 sin pagos SÍ reciben la etiqueta;
rango 1 con 99 PD también; 100 PD de saldo (rango 2) no; rango 1 tras pagar 0,20 €
tampoco; admin tampoco; y con la variable vacía no la recibe nadie. Los dos últimos
casos no existían en la BD, así que se probaron con datos temporales en la cuenta
14 (fila en stripelog y en api_points), ya borrados. /my-account sigue pintando el
rango correcto tras mover las consultas.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Se añade GA4 (gtag.js) con el componente oficial `@next/third-parties`, que es lo
que recomienda el doc de Next 16 y carga el mismo gtag pero tras la hidratación.
DOS interruptores:
1. `NEXT_PUBLIC_GA_ID` en el .env (no versionado). Vacío o sin poner = no se carga
nada. Documentada en el README.
2. El consentimiento del visitante. El sitio YA tenía un banner con la categoría
«Analíticas» que se puede rechazar: soltar gtag en el <head> lo habría
convertido en mentira, y con visitantes en la UE, en un problema legal.
Para lo segundo se expone `useConsent(categoría)` desde CookieConsent, que además
reacciona en caliente: `writeConsent`/`revokeConsent` ya disparaban el evento
`ns:consentchange`, así que la analítica entra en cuanto se acepta y desaparece
si se revoca, sin recargar. Arranca en `false` a propósito: hasta confirmar el
consentimiento no se carga nada.
Verificado en el build: sin consentimiento no hay ni rastro de googletagmanager
en el HTML, y la condición compilada es `id && consent ? <GoogleAnalytics/> : null`.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El prefijo venía del nombre de la app Django (`home`), jubilada y borrada hoy,
así que ya no significaba nada: home_stripelog -> stripelog. La BD se sigue
llamando django_wow por historia (renombrarla es otra operación).
Comprobado antes de tocar nada: 0 colisiones con nombres existentes, 0 palabras
reservadas (contrastado contra las 260 de MySQL), sin vistas ni triggers que
dependieran de ellas. El RENAME va en una sola sentencia porque así es atómico,
y MySQL reapunta solo las 4 claves ajenas entre estas tablas.
170 referencias actualizadas en 37 ficheros. Se dejó a propósito
sql/drop_home_securitytoken_authuser_fk.sql sin tocar: es una migración ya
aplicada y reescribirla sería falsear el historial.
De paso salió un fallo previo: prices.ts consultaba `home_restoreitemprice`,
una tabla que NO existe. El try/catch de priceFrom se comía el error y devolvía
siempre el precio por defecto, así que el precio de restaurar objetos nunca fue
configurable. Se deja documentado en el código; crear la tabla es otra decisión.
Verificado tras aplicar: 0 tablas home_, las 51 siguen ahí, y el conteo exacto
de filas cuadra con el volcado previo (store_item 3068, item_data 44873,
stripelog 35, store_order 26, noticia 50). La web responde 200 en todas las
rutas y la portada carga las noticias sin errores.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El cutover se hizo hoy: Caddy manda www.nightspire.gg a :3001 (Next), así que
Django se quedó sin dominio y sin uso. Se comprobó antes de borrar que nada
dependía de él: ninguna referencia a :8001 en Caddy, el timer de reconciliación
llama a Next, DJANGO_API_BASE no lo leía ni una línea del código (se quita
también de la unidad de systemd), web-next/public es autónomo (736 ficheros
reales, 0 symlinks) y no hay ni una referencia a /static/. Con Django parado la
web siguió dando 200 en todas las rutas.
Se va: home/, novawow/, forum/, wotlk_db/, frontend/ (las islas React que Next
sustituyó), static/, staticfiles/, manage.py, requirements.txt, db.sqlite3 y el
Docker de Django.
Se quedan docs/ y sql/: no son código Django sino documentación y esquemas, y
sql/forum_schema.sql describe la BD acore_web que Next usa hoy.
La BASE DE DATOS no se toca. django_wow y sus 41 tablas home_* son ahora de
Next, que las consulta con SQL directo. El nombre se queda por historia.
README reescrito: describía cómo montar un Django que ya no existe (venv,
manage.py migrate, gunicorn, Docker).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- README.md: guía de instalación (venv, .env, migraciones, gunicorn) y notas de producción/seguridad
- Dockerfile: imagen Python 3.14 con deps de sistema para mysqlclient/Pillow
- docker-compose.yml: servicios web (Django+gunicorn) y db (MySQL 8.4) con las 4 BBDD
- docker/entrypoint.sh: espera a MySQL, migra, collectstatic y arranca gunicorn
- docker/mysql-init.sql: crea django_wow + bases acore_*
- .dockerignore y gunicorn en requirements
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Inna