La página mostraba un genérico «¡Cuenta activada!» + enlace a iniciar sesión.
Se recupera la estructura de las plantillas del tema (activation_success.html /
activation_invalid.html): bienvenida, la cuenta en `yellow-info`, y el aviso de
enlace inválido en `red-info2` con la línea de contacto.
El original dejaba un hueco: renderizaba `{{ username }}` pero la vista hacía
`render(...)` SIN contexto, así que salía «La cuenta ha sido activada». Aquí
`activateAccount` devuelve el email y sí se muestra. Va el email tal cual se
registró, no el normalizado: ese va en MAYÚSCULAS porque lo exige el SRP6 de
Battle.net y en pantalla quedaría como INNA@INNA.CL.
El nombre del servidor sale de `getRealmName()` (acore_auth.realmlist), como en
el resto de páginas, en vez de escribirlo a mano.
Verificado en producción: el caso inválido lo pinta el servidor y sale idéntico
al del tema; y activando una fila de prueba, el API devuelve {success, email} y
reutilizar el enlace o mandar un hash que no existe dan `invalidLink` (filas de
prueba borradas después).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Dos cosas que el port de Django cambió sin querer:
- El hash de activación se generaba con `randomBytes(16).toString('hex')`: 32
caracteres, sí, pero solo `0-9a-f`. El original era `get_random_string(32)`,
alfanumérico con mayúsculas y minúsculas (`?act=P4JHQDJey2jJDnEBnqUePI5O2qEFB1`).
- El aviso de cuenta creada era un genérico «Revisa tu correo», mientras que el
original decía qué cuenta se creó y a qué dirección fue el enlace. Se recupera
el formato de dos líneas (con id `create-response`, como el original).
El muestreo por rechazo del token de seguridad se sube a `lib/random-token.ts` y
lo comparten los dos generadores, que solo se diferencian en el alfabeto: letras
para el token que se teclea a mano, alfanumérico para el hash de la URL.
Verificado con 100.000 hashes: todos casan /^[A-Za-z0-9]{32}$/, salen los 62
caracteres y la desviación por carácter se queda en 1,3% (ruido).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Antes: <link href="/ns-themes/.../nightspire-style.css?v=2"> en el <head>. Una
peticion aparte, sin minificar y con cache invalidada a mano con ?v=2.
Ahora: app/theme.css, importado al FINAL de globals.css. Next lo compila,
minifica y le pone hash de contenido; se sirve con cache immutable y hay una
hoja de estilo menos (4 -> 3).
⚠ El @import va el ULTIMO y no es cosmético: el tema se diseñó contra los
defaults del navegador y el preflight de Tailwind los pisa (box-sizing,
alturas). Antes ganaba la cascada por cargarse el último en el <head>; ahora
gana por ser el último import. Si sube de sitio, el diseño se rompe.
Las url() pasan a ABSOLUTAS (/ns-themes/ns-ryu/...). Los assets siguen en
public/, y así el compilador no intenta resolverlos: el @font-face declara
.eot/.otf/.ttf que NO existen (solo hay .woff) y con rutas relativas el build
fallaría.
Verificado: los 6 páginas dan exactamente el mismo alto que antes (8159, 1356,
2645, 1356, 2221, 2349 px) con la misma fuente y colores, y el input del login
sigue en box-sizing:content-box — que es justo donde el preflight rompía. Ojo:
el md5 de las capturas NO sirve para comparar, porque la cabecera lleva un vídeo
y cada captura pilla un fotograma distinto.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Renombrado completo de los prefijos heredados: 19 carpetas, 11 ficheros y 318
referencias en 35 ficheros de código, más las clases y las rutas url() de dentro
del CSS del tema. Se usa git mv para conservar el historial.
También fuera del código, que un sed no ve:
- BD: votesite.image_url (4 filas) apuntaba a /nw-themes/...
- Ficheros con la marca vieja en el NOMBRE: novawow-maintenance.webp ->
nightspire-maintenance.webp (lo usa la página de mantenimiento) y
store_novawow_response.js.
⚠ Alias en Caddy /nw-themes/* -> /ns-themes/*: los correos ENVIADOS antes del
rebranding llevan esas rutas escritas y están en las bandejas de los usuarios.
Sin el alias, sus imágenes se romperían. Verificado que las rutas viejas siguen
sirviendo 200.
Nota: ns-js/ y ns-js-handlers/ son CÓDIGO MUERTO (manejadores jQuery del portal
Django, que ya se borró). Se midió en el navegador: la web no pide ni un solo JS
del tema. Se renombran igualmente por consistencia, pero son candidatos a
borrarse.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
La página venía de ultimowow y declaraba 26 cookies que este sitio NO pone.
Empezando por PHPSESSID, que es de PHP: aquí no hay PHP. Además todo el bloque
de Cloudflare (cf_clearance, __cf_bm, _cfuvid, CF_VERIFIED_DEVICE_*,
_cf_logged_in, sparrow_id), Google Analytics (_ga, _gid, _gat), Facebook
(_fbp, _fbc, fr), Adobe (AMCV_*), Zaraz (zaraz-consent, cfz_*) y las de
preferencias del foro/visor 3D de ultimowow (comments_sort, temp_default_3dmodel).
Se comprobó en un navegador contra producción, no de memoria: las únicas cookies
son NEXT_LOCALE (idioma), ns_cookie_consent (consentimiento, 1 año) y
nightspire_session (sesión, httpOnly). Turnstile NO pone ninguna en nuestro
dominio, y el sitio NO está detrás de un proxy de Cloudflare (la IP es del
servidor y no llega cabecera cf-ray), así que ninguna cookie de Cloudflare
aplicaba. Tampoco hay Google Analytics ni píxeles: no aparecen en el código.
Terceros medidos en el navegador: challenges.cloudflare.com (Turnstile, solo en
formularios), wow.zamimg.com (iconos de Wowhead), cdnjs.cloudflare.com
(tipografías/iconos) y YouTube (solo si un creador tiene vídeo configurado).
40 claves de traducción eliminadas en ES y EN; 43 usadas = 43 definidas, sin
huérfanas.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Estaba escrito a mano en el JSX de privacy-policy, refund-policy y
terms-and-conditions, no en las traducciones, por eso no cayó con el
resto. Era el nombre de la empresa heredado de ultimowow, figurando
como responsable del servicio.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sitios de voto: los 4 apuntaban a las fichas de UltimoWoW en los rankings con
SUS ids (Gtop100 94649, pingUsername 91402, etc.). No era cosmética: cada voto
de nuestros jugadores subía a UltimoWoW en el ranking. Se cambian nombre e ids
por un 236588 de relleno, así el enlace deja de acreditar a otro servidor. Las
fichas reales de NightSpire están por crear; entonces habrá que poner sus ids.
Nota legal: decía "Error 404 es la empresa que representa el servicio", heredado
de ultimowow. Al renombrar la marca pasaba a afirmar que una empresa ajena
representa a NightSpire, lo cual es falso. Se quita la empresa en ES y EN.
Prefijo uw- (de UltimoWoW) -> ns-: 100 identificadores en 11 ficheros (clases
CSS, ids de formulario, eventos y la cookie de consentimiento, que pasa a
ns_cookie_consent; a los usuarios les reaparecerá el aviso una vez). Se comprobó
antes que el CSS del tema no define ninguna clase uw-, así que no rompe estilos.
btn-ns-form y ns-cookie-btn-customize se usan sin estar definidas, pero ya era
así antes del cambio: eran clases muertas.
Repo de Gitea renombrado Inna/NovaWoW -> Inna/NightSpire (era la marca vieja más
visible de /changelogs, que forma la URL de cada commit). Gitea redirige la URL
antigua con 301. Se actualizan el remoto y lib/changelog.ts.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Marca, dominios y correos: UltimoWoW/Nova WoW -> NightSpire, cualquier URL de
esos dominios -> https://www.nightspire.gg y los correos -> consultas@nightspire.gg.
98 sustituciones en 16 ficheros de textos de usuario (messages/, app/, components/).
Assets: logo largo de cabecera y vídeo sustituidos por los de NightSpire (el logo
nuevo es 214x28, igual que el viejo, así que no hace falta tocar el CSS).
Redes: apuntan a las cuentas de NightSpire, tanto en el pie de la web como en el
de los correos (que seguían enlazando a las de NovaWoW desde el porte del diseño).
Cookie de sesión novawow_session -> nightspire_session. Cierra la sesión de todos
los conectados una vez; se asume ahora, recién hecho el cutover.
Ficheros del tema renombrados: novawow-style.css -> nightspire-style.css y
novawow-main-logo-transparent.webp -> nightspire-main-logo-transparent.webp, para
que la marca vieja no quede ni en las rutas.
El foro externo (foro.ultimowow.com) pasa a ser el nuestro: <Link> a /forum, que
respeta el idioma y no abre pestaña nueva.
NO se tocan y es a propósito:
- Los comentarios que nombran AzerothCore: describen el comportamiento REAL del
core (límite de 12 ítems por correo, convención de baneos, SOAP...). Cambiarlos
a NightSpire los volvería falsos. Además AzerothCore no aparece en la web: las
14 menciones son todas comentarios de código.
- El regex de brandify() sigue buscando los nombres VIEJOS: son los que hay
escritos en las noticias de la BD.
- lib/changelog.ts REPO='Inna/NovaWoW': es la ruta real del repo en Gitea.
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>
Dos cosas, y la segunda dejaba la página sin contenido:
- El botón "Solicitar nuevo cambio de correo" salía de 250x100 pegado a la
derecha. `.back-to-account` es el botón de la CABECERA de una caja (250px de
ancho, line-height 50, float right); suelto en el CUERPO el float lo pega a un
lado, y el texto no cabe en 250px, se parte en dos líneas y cada una se lleva
sus 50px. Se le deja el aspecto del tema pero ajustado a su texto: pasa a
336x50 y centrado.
- El mensaje rojo ("el enlace ha expirado") NO SE VEÍA: el tema deja
`.alert-message` con display:none porque es el hueco que rellena y revela el
JS, y aquí el aviso es estático. Se pone display:block a mano, igual que hacen
todos los formularios del proyecto. Comprobado que al original le pasa lo
mismo: su página de enlace caducado enseña el título y el botón, y la
explicación queda invisible.
Medido en el navegador: botón 336x50, centrado, sin desbordar, y el mensaje
visible.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Réplica de los partials `expired_link.html` y `maintenance.html`, con las clases
del tema. Con esto web-next ya tiene todo lo que tiene Django: las demás rutas
que faltaban eran los *-success/*-cancel por servicio, que aquí sustituye el
/service-success unificado, y novawow-realm/players, que los sirve la ruta
dinámica [realm].
Dos erratas del original que NO se copian:
- "Enlace Expirado" enseñaba un «No hay códigos de promoción disponibles» que es
de otra página.
- Su botón "Solicitar nuevo cambio de correo" enlazaba a `expired-link`, o sea a
sí misma. Aquí va a /change-email, que es lo que pretendía.
Verificado: /es/ y /en/ de las dos dan 200 (Django también), la imagen de
mantenimiento carga y cabe (437x371, sin desbordar), y el botón apunta a
/es/change-email.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
SiteHeader enlazaba /content-creators y esa página no existía en Next: el menú
VIDEOS llevaba a un 404. Réplica del partial Django `partials/videos.html`, con
sus clases del tema (cc-box, cc-avatar, cc-name...). Lee el primer registro de
home_contentcreator, igual que la vista de Django.
La descripción es HTML de CKEditor (lo edita un admin), así que se sanea con
`cleanPostHtml`, la misma allowlist que los mensajes del foro. Comprobado
metiendo un <script>alert(1)</script> a propósito: no aparece en el HTML servido.
Dos arreglos sobre el diseño de Django, que copiaba tal cual:
- El título va SIEMPRE. Django lo metía dentro del `if content_creator`, así que
sin datos la página quedaba con un <p> suelto, sin cabecera ni caja. Ahora sin
creador sale el título de la sección y el aviso centrado en su box-content.
- Los enlaces de YouTube/Facebook se salían por abajo de la caja. El tema le da a
`.cc-box` una altura FIJA de 172px contando con el content-box del navegador, y
el border-box de Tailwind le restaba el padding y el borde: 24px menos de alto
útil. Es el mismo caso que .item-box en la tienda. Medido: la caja pasa de 172
a 196px de alto y los enlaces dejan de desbordar.
Verificado con un creador de prueba (borrado después): /es/ y /en/ dan 200, el
título, el avatar, el iframe y los enlaces caen dentro de la caja, y con la tabla
vacía sale el mismo texto que Django.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El original lo dice en su propio texto ("los objetos disponibles son los mismos
de la tienda") y lo confirma su JS, que usa #store-list y .store-add-button: el
regalo NO tiene catálogo propio, es la tienda con el correo a otro personaje.
Nosotros teníamos una tabla aparte (home_item) con 8 objetos y precios en euros.
Ahora send-gift monta StoreBrowser en modo `gift`: mismo catálogo (3068 ítems,
PD/PV), mismo carrito con cantidades y las cuatro formas de pago. Antes NO tenía
Stripe: solo SumUp, PD y PV.
Dos pasos, como el original: primero #char-select-div (personaje de origen,
destino, confirmación y token) y solo al pulsar "Mostrar Regalos" aparece el
catálogo. Se borran SendGiftForm, /api/gift/checkout y lib/gift (ya no los usa
nadie); la tabla home_item se queda en la BD, sin usar.
Tres cosas que el usuario pidió y que estaban mal:
- El formulario va con `noValidate`: los avisos los damos nosotros en rojo
(#show-gif-response), no el navegador.
- "Mostrar Regalos" ahora valida contra el SERVIDOR (que el personaje de origen
sea tuyo, que el destino exista y que el token sea correcto). Antes elegías
objetos para descubrir al final que el destino no existía.
- BUG REAL: el nombre del destino distinguía mayúsculas. `characters.name` es
`utf8mb4_bin`, así que "innakh" NO encontraba a "Innakh" (comprobado: 0
resultados; con COLLATE, 1). `findCharacterByName` busca sin distinguir y
devuelve el nombre CANÓNICO, que es el que va al comando SOAP.
La validación vive en lib/gift-check y la usan las dos rutas: /api/gift/check (el
botón) y /api/gift/send, que revalida porque el cliente puede saltarse el paso 1.
También se quita del texto "El pago se realiza mediante SumUp": el original no lo
dice y además ya era falso con cuatro formas de pago.
Verificado: innakh / INNAKH / InNaKh resuelven a "Innakh"; token malo y destino
inexistente salen en rojo sin pasar al catálogo. Con 500 PD de saldo de prueba,
2 copias de un ítem de 200 pasan el cobro (deliveryFailed por el worldserver
caído, con su reembolso) y 3 dan insufficientPd: el servidor cobra por copias.
Datos de prueba borrados.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Salieron al pasar el lint por todo el proyecto. De 47 a 0 (quedan 15 avisos:
<img> vs <Image /> y el <link> del tema, los dos deliberados).
- Footer y Video (42 de los 47, que en realidad eran 7 enlaces: el plugin repite
cada uno 6 veces): usaban `<a href="/terms-and-conditions">` SIN el idioma
delante. No estaba roto de milagro: el middleware lo salvaba mirando la cookie
NEXT_LOCALE. Pero cada clic se comía un 307 y recargaba la página entera en
vez de navegar en cliente, y el idioma lo decidía la cookie en vez de la URL
en la que estás. Ahora van con el `Link` de i18n, que ya existía.
- Turnstile: escribía una ref (`cb.current = onVerify`) DURANTE el render. Es el
patrón de "callback fresca", pero no está permitido: React puede descartar ese
render y dejarla mal. Pasa a un efecto.
- ActivateClient y ConfirmClient: ponían el estado de error con setState dentro
del efecto cuando NO hay hash. Eso se sabe ya al renderizar (es un prop), así
que se deriva del estado inicial y se ahorra un render.
- BattlepayList: `window.location.href = …` -> `.assign()`, igual que en la
tienda.
- CookieConsent: aquí el efecto es correcto y la regla no aplica, así que se
silencia explicando por qué: el consentimiento vive en una cookie del
navegador, en el servidor no existe, y leerlo al renderizar rompería la
hidratación (le saldría el banner a quien ya había decidido).
Verificado: desde /es/ el pie enlaza a /es/terms-and-conditions y desde /en/ a
/en/terms-and-conditions; portada, cookies, tienda y mi-cuenta siguen dando 200.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Como el original (/store-bennu). El slug sale de acore_auth.realmlist, así que
no puede ser una carpeta fija: lo resuelve la ruta dinámica `[realm]`, que ya
servía /<slug>-realm y /<slug>-players con este mismo patrón. Solo hubo que
añadirle el tipo `store`; el contenido de la página se mueve a
components/StorePage.tsx.
/store da 404 sin código extra: al no existir ya la carpeta estática `store`,
entra por `[realm]`, no resuelve y cae en el notFound() que ya estaba.
Enlaces actualizados: el de /my-account (AccountTools, que es cliente y recibe
el href ya calculado) y el cancelUrl de la pasarela, que devolvía a /store.
Verificado: /es/store-trinity y /en/store-trinity dan 200 y la tienda carga el
catálogo; /es/store y /en/store dan 404; un slug ajeno (/es/store-bennu) también
404; /es/trinity-realm y /es/trinity-players siguen bien; y el enlace de
/my-account apunta a /es/store-trinity.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Comparado contra el store original (ultimowow /es/store-bennu) con una sesión
real: markup, CSS y clases que aplica su power.js. Cinco causas distintas:
- Los nombres de ítem salían azules: el layout declaraba `const whTooltips`,
que queda en el ámbito léxico del script y NO crea propiedad en `window`,
que es de donde tooltips.js lee la config -> se ignoraba entera. Ahora
`window.whTooltips`, con colorLinks+iconizeLinks (el original no define
whTooltips y usa esos defaults; sus enlaces acaban con clases `icontinyl q4`).
renameLinks sigue en false: el texto sale de nuestra BD, en español.
- tooltips.js solo recorre el DOM al cargar, así que los enlaces que monta
React (hoja del árbol, carrito) no se teñían. Se pasan por
$WowheadPower.refreshLinks(), igual que hace el original tras cada AJAX.
- globals.css redefinía .item-box/.item-name/.item-img-box/.max-left-table2,
que el tema nw-ryu ya trae del original, y con más especificidad ganaba la
cascada. El peor: un `border-collapse` que anulaba el `border-spacing: 0 8px`
del tema, que es lo que separa las filas del carrito.
- Faltaban la caja "Carrito - <REINO>" y "Personaje seleccionado: <nombre>"
(coloreado por clase), que el original sí tiene.
- El total de la columna "Cant" mostraba el número de líneas en vez de la suma
de cantidades: un ítem que entrega un mazo de 20 debe contar 20, no 1.
Verificado con navegador contra un build de producción: el nombre del ítem sale
con clases `icontinyl q4` y color rgb(163,53,238), el mismo valor exacto que
devuelve el original.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replica el bloque Novedades del diseño original: fieldset plegable con el
changelog (Noviembre 2024) y sus objetos enlazados a wowhead (icono zamimg tiny
+ color por calidad). components/StoreNews.tsx (client, toggle con flecha
rotate/rotate2 del tema), incluido en la caja de info de /store. i18n
Store.newsTitle/newsIntro/newsDate (es/en).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Porta la tienda de ítems/transfiguración del sistema antiguo: elegir personaje →
árbol de categorías (3 niveles) → carrito → enviar por correo. Se paga con el
saldo PD o PV de la cuenta (cada ítem lleva su precio y moneda).
- BD: home_store_category (árbol por code "1-1-1") + home_store_item
(mismos item_id, nombres, iconos, precios y moneda que el original;
2947 en PD, 121 en PV). Seed en sql/store_catalog.sql, extraído del HTML real.
- lib/store.ts: getStoreCatalog (árbol anidado), getStoreBalances, priceStoreCart
(precios REALES de BD), purchaseStoreCart (cobro atómico PD+PV con FOR UPDATE y
reembolso si el envío SOAP falla; `.send items` troceado a 12/correo).
- API: GET /api/store/catalog (tras elegir personaje) y POST /api/store/send.
- components/StoreBrowser.tsx: selector de personaje, árbol colapsable (ítems
montados solo al abrir), carrito con totales PD/PV, enviar, modal de resultado.
- página /store con la info y el título "Tienda - REINO". Enlaces de ítems e
iconos por wowhead/zamimg (con tooltip y locale). El enlace ya existía en
AccountTools. i18n namespace Store (es/en). CSS del árbol/carrito/modal.
Verificado: catálogo E2E (750 cats/3068 ítems), cobro atómico + reembolso y
detección de saldo insuficiente (cuenta 15). SOAP real sin probar (worldserver
caído en este entorno).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El script de tooltips prioriza el atributo data-wowhead sobre el subdominio del
href, y su parámetro `domain` codifica idioma + versión: el 1.er segmento va al
mapa de locales ({es:6,...}) y el resto a la versión (wotlk=WRATH). Antes se
enviaba `domain=wotlk` (sin idioma) → locale 0 = inglés siempre.
Ahora `wowheadData(type,id,locale)` genera `domain=es.wotlk` en español (locale 6)
y `domain=wotlk` en inglés. Verificado: el endpoint de datos con locale 6 devuelve
los nombres en español.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sustituye la base de datos de ítems del sistema antiguo (AoWoW en
wotlk.novawow/wotlk.ultimowow) y los iconos de mirrors por wowhead / zamimg,
con el idioma del tooltip según el locale de la web (es. / www.).
Sistema reutilizable para rutas actuales y futuras:
- lib/wowhead.ts: wowheadUrl/wowheadItemUrl/wowheadWotlkHome (subdominio por
locale), wowheadIcon (zamimg) y wowheadData (atributo data-wowhead, rama WotLK).
- components/WowheadLink.tsx: enlace con tooltip en el locale actual.
- layout raíz: config whTooltips (solo tooltips) + script tooltips.js global;
funciona con contenido añadido por React (carrito, búsquedas).
Aplicado en: send-gift (catálogo + carrito), restore-items, recruit
(RecruitPanel, enlace por item_id + icono zamimg), quest-character (misión/npc/
facción + iconos), y el enlace "WOTLK DB" de la cabecera.
Verificado en prod (:3001): /es -> es.wowhead.com, /en -> www.wowhead.com,
data-wowhead presente, iconos por zamimg.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Solo en /send-gift se añade una 4ª forma de pago: PV (vote points, gratis por
votar). Cuesta más que PD para preservar su valor: coste_PV = coste_PD ×
VP_PRICE_FACTOR (=2, configurable en lib/pay-with-dpoints).
- lib/dpoints: getVPointsBalance, creditVPoints y spendVPoints (débito atómico
del campo vp, con FOR UPDATE), espejo de las de PD.
- lib/pay-with-dpoints: VP_PRICE_FACTOR, vpointsCost() y payServiceWithVPoints()
(descuenta PV, ejecuta el envío y reembolsa si falla).
- gift/checkout: rama provider='vp' (además de 'pd').
- service-success: la entrega inmediata cubre 'pd' y 'vp'.
- PaymentMethodSelect: opción VP opcional (solo si el form pasa vpBalance);
muestra coste en PV, insuficiencia y el saldo VP.
- SendGiftForm + página: pasan el saldo VP.
- i18n Pay: vp, vpCost, insufficientVp, balanceVp, errors.insufficientVp (es/en).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El párrafo "Requiere 1000 PD" era estático y contradecía el nuevo selector.
Ahora indica el coste equivalente (1000 PD o 10 €) y que se puede elegir la
forma de pago (PD, tarjeta con Stripe o SumUp), que ya se muestra en el
formulario.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Renombrar hermandad ya no es solo PD: ahora ofrece el mismo selector de
forma de pago que el resto de servicios (saldo PD / tarjeta Stripe / tarjeta
SumUp). El coste es equivalente: 1000 PD = 10 €.
- lib/guild: se separa la validación (checkGuildRenameEligibility) del
renombrado por SOAP (renameGuildBySoap); nuevo GUILD_RENAME_EUR (10 €).
- paid-services: entrada 'rename-guild' para que la reconciliación/webhook
entregue el servicio tras el pago con tarjeta.
- nueva ruta /api/guild/rename/checkout con las 3 pasarelas (valida
elegibilidad antes de cobrar); se elimina la antigua /api/guild/rename.
- RenameGuildForm usa PaymentMethodSelect y redirige a service-success.
- i18n: Paid.rename-guild (title/success) para la página de éxito.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Los 9 servicios con precio en euros (rename, customize, change-race,
change-faction, level-up, gold, transfer, restore-item, send-gift) ahora
ofrecen un selector de forma de pago con las 3 opciones: saldo PD, tarjeta
(Stripe) o tarjeta (SumUp).
- lib/dpoints: spendDPoints() descuenta PD de forma atómica (FOR UPDATE).
- lib/pay-with-dpoints: paga con saldo PD, ejecuta la acción al momento y
reembolsa si la ejecución falla; 100 PD = 1 €.
- rutas checkout (character/[service] y gift): rama provider='pd' que valida
saldo, descuenta, ejecuta fulfill y devuelve la URL de éxito (sin pasarela).
- service-success: rama provider='pd' (la entrega ya se hizo en el checkout).
- PaymentMethodSelect: componente compartido con coste por método y saldo;
desactiva PD si no hay saldo suficiente.
- Formularios (PaidServiceForm, Gold, Transfer, RestoreItems, SendGift) y sus
páginas pasan el saldo PD y envían el método elegido + locale.
- i18n: namespace Pay (es/en); añadidas claves Paid.restore-item que faltaban.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Al fallar (p.ej. contraseña incorrecta) el token de Turnstile ya se consumió en el
servidor; el reintento reenviaba el mismo token y daba "captcha fallida" aunque
estuviera resuelto. Se resetea el widget (setCaptcha('') + captchaKey++ con
<Turnstile key={captchaKey}>, mismo patrón que recover/restore/quest) en login,
create-account y trade-points (venta y canje). El check de código no usa captcha,
no se resetea ahí.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mueve la página de login a /log-in y actualiza todas las referencias (enlace
CONECTAR del header y los redirect de auth de ~45 páginas). /login ahora da 404.
La API /api/auth/login no se toca (solo la ruta de página).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Desactiva la validación nativa del navegador ("Rellene este campo", formato de
email) en el resto de formularios (recover, reset-password, trade-points,
rename-guild, transfer-dp, gold, promo, transfer, quest, send-gift, 2FA, restore).
Los errores se muestran como red-form-response (por validación en cliente o del
servidor), consistente con login y create-account. Botones ya gateados por campos.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El navegador mostraba "Rellene este campo" (required) en lugar del error del sitio.
noValidate en el form deja que la validación en cliente ya existente muestre el
red-form-response (missingFields).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El navegador mostraba su tooltip nativo "Rellene este campo" en los inputs required
en vez del mensaje de error del sitio. Con noValidate en el form, la validación en
cliente (clientError) muestra el red-form-response también para campos vacíos.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Antes los errores (contraseñas/correos que no coinciden, campos vacíos) solo se
mostraban en rojo tras el envío al servidor. Ahora se validan en el cliente y se
muestran al instante como red-form-response, sin llamada al servidor. Nueva clave
emailMismatch. El servidor sigue haciendo la validación final (Gmail, existe, etc.).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mueve la página de registro a /create-account (los enlaces del header y del login
apuntan ahí; /register ahora da 404 con el 404 del sitio). Rediseño según el
diseño aportado, adaptado a Battle.net (cuenta por email, sin usuario): caja de
info bnet (tipo bnet, reglas de contraseña/Gmail, activación, login por correo),
ojos para mostrar/ocultar contraseña, checkbox de "no accedo desde EEUU" +
términos (con enlaces), ambos requeridos para habilitar el botón, y bloqueo de
pegar en confirmar contraseña/correo. i18n ES/EN. No incluye FingerprintJS
(antiabuso por huella de dispositivo, requiere backend; la protección es Turnstile
+ Gmail + activación).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El nivel/rango usaba el saldo de PD actual, que baja al gastar. Ahora se basa en
el total donado = suma de pagos confirmados (Stripe mode test/live + SumUp),
convertidos a PD (amount * 100). Cuenta todas las pasarelas y donaciones mixtas y
no baja al gastar PD. Se usa max(donatedPD, saldo) para no rebajar el rango a
nadie (p.ej. PD de promo). getAccountDashboard expone donatedPD. Verificado:
cuenta 15 con €43 en pagos -> Nivel 11 aunque el saldo sea 0.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Añade mapa de zonas en inglés (lib/data/zone-names-en.json, 9675 zonas de
FusionCMS wow_zones.php; cobertura 100% de los ids del mapa ES) y nombres de
raza/clase EN (wow_constants.php). getZoneName/getRaceName/getClassName aceptan
locale (EN cae a ES si falta). getAccountDashboard(session, locale) lo propaga y
my-account pasa el idioma. El dinero (oro/plata/cobre) usa iconos, universal.
Verificado: Innadin -> Human/Paladin/Stormwind City en /en.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
formatFecha usaba es-ES fijo; ahora recibe el locale y formatea en en-US para
inglés. /en/changelogs muestra "July 14, 2026 at 07:55 PM"; /es/ en español.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
forum_categories.name_en y forums.name_en/description_en (sql/add_forum_en.sql,
aplicado en prod y traducidos los existentes: Comunidad/Anuncios/Discusión general).
getForumIndex(locale) y getForum(id, locale) usan EN si existe, si no caen al
español. Las páginas del foro pasan el locale. Labels (Temas/Mensajes) ya estaban
traducidos. Verificado: /en/forum en inglés, /es/forum en español.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
getSanctions devuelve claves (scopeKey account/battlenet/character + scopeName;
statusKey active/activePermanent/expired) en vez de español. La página traduce
alcance ("Character: {name}") y estado; "Permanente" ya usaba clave. Motivo y
autor son datos del GM (no se traducen). Nuevas claves History.ban.scope/status.
Verificado con sanciones de prueba (todos los combos resuelven en es y en).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
La lib devolvía la acción ("Token de seguridad solicitado") y el estado del login
web ("Conexión exitosa"/"Contraseña incorrecta") en español. Ahora devuelve claves
(actionKey='tokenRequested'; statusKey='success'/'wrongPassword'/'other' + statusRaw)
y la página las traduce (History.security.action/webStatus). El coloreado rojo pasa
a depender de statusKey==='wrongPassword'. Verificado con datos reales.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Extrae la lógica de concepto traducible a lib/tx-concept.ts (buildConcept +
purchasedPD + SERVICE_CONCEPT) y la reutilizan points-history y trans-history.
La columna Concepto de trans-history ahora se traduce (reusa History.points.concept.*)
en vez de mostrar el product_name en español. Corrige también la sombra de
variable en PlatformBox (map t -> tx). Verificado con la cuenta 15.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Los valores de las columnas Concepto/Método/Estado venían en español desde la lib.
Ahora getPointsHistory devuelve CLAVES (conceptKey+args, method 'vote'/'promo',
status 'delivered'/'pending'/'credited') y la página las traduce. Concepto por
servicio ("Rename character: {char}", "Vote on {site}", "Code {code}", "{n} PD");
los pagos heredados sin servicio caen a conceptRaw. Claves nuevas en History.points.
Verificado con la cuenta 15: todas las combinaciones resuelven en es y en.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
home_noticia gana columnas titulo_en/contenido_en (sql/add_news_en.sql). getNoticias(locale)
usa la versión EN si existe, si no cae al español (título y contenido independientes); la fecha
también se formatea por idioma. El panel de admin permite escribir la traducción al crear y EDITAR
noticias existentes (nuevo PUT /api/admin/news/[id], updateNews). Claves Admin nuevas (título/
contenido EN, editar/guardar). Probado: /en/ muestra EN, /es/ ES; PUT guardado (403 sin sesión).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Los <title> estáticos estaban en español fijo. Se migran 31 páginas a
generateMetadata reutilizando la clave de título ya traducida de cada página
(o del <h1>). Se traducen además los PageShell title hardcodeados de las 6
páginas CharServiceB y los títulos de download-client y changelogs (+ su
mensaje de error). tsc/build OK, paridad es/en, <title> cambia por idioma.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Se externaliza el texto español hardcodeado de ~55 archivos a next-intl y se añaden
traducciones al inglés, con paridad de claves es/en. Nuevos namespaces: History,
CharService, CharServiceB, Points, Legal, UI, Misc (+ altas en Common/Admin).
- Historiales (PD/PV, transacciones, sanciones, seguridad), servicios de personaje
(transfer, send-gift, quest, restore-*, change-*, customize, level-up, gold, rename),
PD/pagos (d-points, trade, promo, transfer-dp, rename-guild, DPointsTabs), páginas
legales (cookies, privacidad, términos, reembolsos, aviso legal, contacto), layout
(cabecera, footer, cookies, 2FA, descargas, jugadores, recluta) y páginas varias
(home, reino, ayuda, addons, 2falogin).
- Textos con markup inline via t.rich; interpolación con ICU.
- Componente <NoteLegend/> para la leyenda NOTA/NOTE compartida.
- payLabel/confirmText de los servicios de pago traducidos.
- Verificado: tsc OK, next build OK, todas las claves t() resuelven en es y en,
todos los t.rich casan etiquetas, páginas 200 en /es/ y /en/ sin claves crudas.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El nav ya mide igual que el original (1112px, items 174px, Futura) tras el fix de
box-sizing; el CSS del tema se servía sin versión y quedaba cacheado. Se añade
?v=2 a novawow-style.css para bustear la caché del navegador.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
trailingSlash true ponía barra en todo (/es/content-creators/). Se pasa a
skipTrailingSlashRedirect + normalización en middleware: raíz de idioma /es → /es/
(con barra), y cualquier sub-ruta con barra final se redirige sin ella
(/es/x/ → /es/x). Sin bucles. Las /api quedan fuera del middleware (sin 308).
El redirect del logout apunta a /es/.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
next.config: trailingSlash true → /es redirige a /es/ y los enlaces se generan
con barra. Se ajustan a barra final los destinos internos que se enlazan a mano
(logout /log-out/ y su redirect, y los window.location.assign de login/
select-account) para evitar el salto 308 extra.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
El selector de cuentas de juego listaba el nombre interno (15#1). Ahora usa
wowAccountLabel (mismo criterio que my-account/cabecera): «15#1» → «WOW1». La
etiqueta se calcula en el Server Component (bnet.ts importa crypto, no vale en
cliente) y se pasa al formulario.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Con router.push el layout persiste entre rutas, así que la cabecera seguía
mostrando "Conectar/Crear cuenta" tras el login hasta recargar. Ahora login y
select-account hacen window.location.assign(/{locale}/...) para que el servidor
re-renderice el layout/cabecera con la sesión nueva.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Construir la URL desde request.url daba https://localhost:3001/es detrás de Caddy
(usa la dirección interna). Ahora el Location es relativo (/es), que el navegador
resuelve contra el dominio público real.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Route Handler GET en app/[locale]/log-out: destruye la cookie de sesión y
redirige (303) a /{locale}. Enlace directo visitable (/es/log-out, /en/log-out)
sin depender de JS; reutiliza getSession().destroy().
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
La columna Usuario mostraba el nombre interno de la cuenta de juego (15#1). Ahora
muestra la etiqueta WOW1 (nº tras #; con varias serían WOW2, WOW3…) y debajo la
cuenta Battle.net (email), sin añadir columnas. Helper wowAccountLabel extraído a
lib/bnet.ts (mismo criterio que my-account).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>