# Novo Portal -- White Antidote (AAC moderno) > **Estado atual (2026-07):** front estatico Next em `html/portal/out`, API em > `html/portal/api` (nao `portal-api/`), deploy em `dev.whiteantidote.com`. > Playbook operacional: `docs/portal-dev-playbook.md`. Seguranca: `docs/portal-security.md`. > Mapa de endpoints: `docs/portal-api-map.md`. Referência viva do projeto de reconstrução do site. O site Gesior atual (raiz do `html`) **continua no ar e intocado** até o cutover manual (troca de subdomínio via Apache) quando o novo portal estiver 100% funcional. > Regra de ouro: **não reescrever sistemas que já funcionam em PHP** ? isolar e > reutilizar. O DB `ot_new` é **compartilhado com o servidor OT**; nenhuma coluna > lida pelo servidor pode mudar, e toda entrega de shop passa por `z_ots_comunication`. --- ## 1. Arquitetura escolhida (Opção A: front moderno + backend PHP) - **Front**: Next.js (React + TypeScript) + Tailwind CSS + shadcn/ui. - Escolhido por ser mais profissional/duradouro (SSR/SEO para highscores, perfis de personagem, guilds; ecossistema maior e longevo). - **Backend/API**: PHP **8.3** (código novo, limpo, só PDO) expondo JSON. - **Sistemas provados ficam como estão** (pagamentos, ponte de shop, outfits): o portal os **chama**, não os reimplementa. ### Coexistência de PHP (o rollback) Rodar várias versões de PHP lado a lado via **PHP-FPM pools**; cada vhost/subdomínio aponta para a sua. Isso É o rollback ? se o PHP 8 quebrar, o site 5.6 nem é tocado. | O quê | Versão PHP | Onde | |---|---|---| | Site Gesior atual (raiz) | PHP 5.6-FPM (intocado) | `ot.whiteantidote.com` | | API PHP nova (limpa, só PDO) | PHP 8.3-FPM | subdomínio `/api` | | Sistemas provados (pagamentos, `animatedOutfits1092`) | versão em que funcionam | reaproveitados | --- ## 2. Estado do PHP legado (auditoria) - **Base é PDO** (`pot/OTS_Base_DB.php` -> `extends PDO`); `config-and-functions.php` usa `parse_ini_file` + PDO. Essa espinha dorsal **sobrevive** ao PHP 7/8. - **Quebram no PHP 7/8** (funções removidas): `createaccount.php` (`mysql_*`, `ereg`, `split`, `create_function`), `cpanel.php`, `forum.php`, `account/ajax_*.php`, `phpmailer` antigo. Provavelmente **aposentados** pelo portal novo (não precisam de correção se substituídos). - **`animatedOutfits1092`** (addons/outfits dos players): usa **só GD** (`imagecreate`/`imagegif`/`imagecopy`), que continua existindo no 7/8. Baixo risco; testar no 8.3 e, se der ruído, manter no pool 5.6. Consumido pelo front como ``. --- ## 3. Versões (Node / front) - **Node.js**: v20.20.2 (LTS) ? travar com `.nvmrc` e `engines` no `package.json`. - **Gerenciador de pacotes**: **npm** (consistência com o outro projeto). Commitar o `package-lock.json`. - **Framework**: Next.js (última estável no dia da instalação). - **UI**: Tailwind CSS 3.x + shadcn/ui. - **i18n**: `next-intl` (ou `react-i18next`) ? UI em EN / PT / ES. - Regra prática: instalar a última estável e **travar no lockfile**. --- ## 4. Design system (retrô + SaaS clean) - Estrutura moderna: grid espaçado, cards, tipografia sem serifa, dark mode, navbar limpa. - **Assets preservados como tempero, não como base**: - fundos artwork (`layouts/tibiacom/images/header/backgrounds/`) -> hero com overlay. - sprites de itens/outfits -> cards e shop. - Tokens de design (cores, espaçamento, raios) num único lugar. - Inventariar todos os assets a preservar antes de codar. --- ## 5. Ambiente de dev, teste e deploy - **Pasta dedicada** no `html` (não toca a raiz): - `html/portal/` -> build do front. - `html/portal-api/` -> API PHP 8.3. - **Subdomínio** (ex.: `beta.ot.whiteantidote.com`) com docroot em `html/portal/` e `/api` no pool PHP 8.3. O `ot.whiteantidote.com` continua na raiz/PHP 5.6. Servidor web: **Apache** (vhost + proxy reverso para o processo Node do Next). - Dev local: `next dev` (hot-reload). Deploy: build e sincroniza para a pasta. - **Escritas com cuidado no beta** (DB é o mesmo live): - usar **conta de teste**; - **pagamentos em sandbox/test** enquanto debuga (nunca creditar `premium_points` de transação real duas vezes). Credenciais reais só no cutover. - **Cutover**: manual, apontando o subdomínio pelo Apache quando 100% funcional. ### Atenção de infra - Sem backup completo do servidor (só do DB). Evitar mudanças globais destrutivas; preferir instalar **ao lado** (FPM pools) em vez de substituir. - Se o `apt` falhar / MySQL ficar incompatível: aceitável atualizar o DB, mas sempre com dump antes. --- ## 6. Fases do ciclo 0. Discovery & inventário (páginas atuais, tabelas por página, assets, MVP). 1. Arquitetura & contrato de API (endpoints JSON; regras de escrita/shop). 2. Design system & protótipo (tokens + componentes; home + 1 página interna). 3. Páginas públicas de leitura (News, Highscores, Who's Online, Character, Guilds, Server Info, Download). 4. Contas & autenticação (criar conta, login SHA1, gerenciar conta/personagens). 5. Sistemas custom (reset, boss room, castle/favela, lottery, trade-off, patentes, cast, task?). 6. Shop & pagamentos **por último** (catálogo, donate MP+PayPal, shop guild, `z_ots_comunication`; **sem PagSeguro**). 7. Cutover & launch (subdomínio -> DNS/Apache; site antigo como fallback). ### Paridade 100% - Inventário mestre: **`docs/parity-inventory.md`** (todos os `subtopic`). - Por domínio: `docs/parity-*.md` antes de codar (ex.: `parity-guilds.md`). - Nada do legado é aposentado no portal, exceto gateway **PagSeguro**. - Shop player / donate / shop guild ficam **por último**, com contexto dedicado na hora. --- ## 7. Git / processo - Branch: `dev-novo-portal` -> PR no GitHub (`pedrominare/html`). - Subir commits incrementais conforme o desenvolvimento. - Marcar blocos alterados com `// BEGIN CHANGE` / `// END CHANGE` (PHP) e comentários de início/fim de mudança nos arquivos novos.