24248bc60360ad6c3cdd3e3eae9f39ca18cee8b3
Investigadas las 750 categorías de la BD contra el HTML real del original. Los
ítems estaban perfectos (554 hojas, 3068 ítems, mismo contenido en cada una: no
faltaba ninguno). Todo lo roto era de categorías:
- 45 CATEGORÍAS FANTASMA, todas con nombre de código ("11-1", "23-10"). El seed
dedujo el árbol de los códigos de las hojas ("11-1-1" => padre "11-1"), pero
el original NO siempre pinta ese nivel: en 45 hojas el "-1-" del código no
corresponde a nada y cuelgan directas de su raíz. Ahora se lee el anidamiento
real (<ul>/<li>): 705 categorías (20 + 131 + 554) en vez de 750.
- El nombre de una categoría NO es texto plano, es HTML, y lo estábamos
aplanando: 141 nombres perdían su color y 40 cabeceras el suyo. Hay dos
mecanismos y los dos hacen falta: la clase en la CABECERA, que sustituye a
first-brown para colorear la categoría entera ("Brujo" en color de brujo), y
los <span class="no-toggle X"> dentro del nombre (clases y las etiquetas
[Nivel 232 a 245] / (DPS) en otro tono).
- 21 nombres TRUNCADOS en Tokens de Armadura: guardábamos "Guerrero" donde el
original dice "Guerrero, Sacerdote, Druida" (solo se quedó el primer span).
El HTML se trocea en el SERVIDOR (`parseCategoryName`) y al cliente le llegan
solo texto + nombre de clase, así que no hay HTML de la BD entrando en el DOM.
El texto sin color va suelto, NO envuelto en <span>: el tema tiene
`span { color: #fff }` y lo pondría blanco en vez de heredar el de la cabecera.
`name` pasa a VARCHAR(512): con el HTML, el más largo mide 198 y no cabía en 191.
El name_en se genera en el propio seed traduciendo solo el TEXTO y respetando
las etiquetas, así que sql/store_category_en.sql sobra y se borra.
gen_store_catalog.py regenera el seed entero (categorías del HTML, ítems de la
BD, que ya estaban verificados) y es reproducible byte a byte.
Verificado en el navegador contra el original: mismo árbol, 0 categorías con
nombre de código, "[Nivel 232 a 245]" en marrón tenue y los colores de clase
oficiales (Guerrero #C79C6E, Sacerdote blanco, Druida #FF7D0A). En inglés
también, conservando los colores.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nova WoW
Portal web (Django) para un servidor de World of Warcraft basado en AzerothCore.
- Python: 3.14
- Framework: Django 6.0
- Base de datos: MySQL (4 bases: la del portal
django_wow+ las de AzerothCoreacore_auth,acore_characters,acore_world)
1. Requisitos
- Python 3.14 y
venv - MySQL/MariaDB accesible
- Librerías de sistema para compilar algunas dependencias:
sudo apt install python3.14-venv python3.14-dev build-essential pkg-config \
default-libmysqlclient-dev libgmp-dev libmpfr-dev libmpc-dev libjpeg-dev zlib1g-dev
2. Puesta en marcha (desarrollo)
git clone https://git.nightspire.gg/Inna/NovaWoW.git
cd NovaWoW
# Entorno virtual
python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt
# Variables de entorno
cp .env.example .env
# edita .env con tus credenciales reales (ver sección 3)
# Migraciones y arranque
python manage.py migrate
python manage.py createsuperuser # opcional
python manage.py runserver
La app queda en http://127.0.0.1:8000
3. Configuración (.env)
Toda la configuración sensible se lee de variables de entorno mediante
python-dotenv. Copia .env.example
a .env y rellena los valores. El .env no se versiona.
| Variable | Descripción |
|---|---|
DJANGO_SECRET_KEY |
Clave secreta de Django. Genera una nueva (ver abajo). |
DJANGO_DEBUG |
True en desarrollo, False en producción. |
DB_USER / DB_PASSWORD |
Credenciales MySQL (compartidas por las 4 BBDD). |
DB_HOST / DB_PORT |
Host y puerto de MySQL. |
DB_NAME_DEFAULT |
BD del portal (por defecto django_wow). |
DB_NAME_AUTH / DB_NAME_CHARACTERS / DB_NAME_WORLD |
BBDD de AzerothCore. |
AC_SOAP_* |
Conexión SOAP a AzerothCore (crear cuentas, etc.). |
SUMUP_* / STRIPE_* |
Pasarelas de pago. |
EMAIL_HOST_USER / EMAIL_HOST_PASSWORD |
SMTP de Gmail (App Password). |
Generar una SECRET_KEY nueva:
python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"
4. Producción
# Recopilar estáticos
python manage.py collectstatic --noinput
# Servir con gunicorn (4 workers)
gunicorn novawow.wsgi:application --bind 0.0.0.0:8000 --workers 4
Recomendaciones:
DJANGO_DEBUG=Falsey unaDJANGO_SECRET_KEYpropia y secreta.- Poner Nginx delante como proxy inverso y para servir
staticfiles/. - Revisar
ALLOWED_HOSTSyCSRF_TRUSTED_ORIGINSennovawow/settings.py.
5. Docker
Alternativamente, se puede levantar todo con Docker (web + MySQL):
cp .env.example .env # ajusta los secretos (no las variables DB_*, las fija compose)
docker compose up --build
- La web queda en http://127.0.0.1:8000
- El servicio
dbcrea automáticamente las 4 bases de datos. - El
entrypointespera a MySQL, aplica migraciones y recopila estáticos antes de arrancar gunicorn.
Ver docker-compose.yml y Dockerfile para los detalles.
6. Notas de seguridad
- Los secretos que estuvieron hardcodeados en el historial de git deben rotarse (contraseña MySQL/SOAP, App Password de Gmail, claves de Stripe/SumUp).
- Nunca subas el archivo
.enval repositorio.
Description
Languages
Macaulay2
97.7%
TypeScript
2%
CSS
0.2%