.datatable-header, .datatable-footer { padding: 10px; } .datatable-header .dataTables_filter, .datatable-header .dataTables_length, .datatable-footer .dataTables_info, .datatable-footer .dataTables_paginate { margin: 0; } .datatable-header .dataTables_filter { float: right; } .datatable-header .dataTables_length { float: left; } .dataTables_processing { width: auto; height: auto; padding: 10px; background: #FFF; border-width: 1px; border-style: solid; border-radius: 5px; top: 50%; left: 50%; margin-top: -50px; margin-left: -50px; } .navbar-brand { padding: 6px 32px; } .navbar-brand > img { height: 33px; } /* ------------------------------------------------------------------ * Redesign visual (v8) - Caio Codigo * Classes utilitarias que centralizam cores que estavam espalhadas como * style="background-color:..." inline nas views de backoffice/admin. * Os valores de cor sao EXATAMENTE os mesmos ja usados antes (nao houve * mudanca de paleta, so migracao de inline -> classe). * ------------------------------------------------------------------ */ .bg-brand { background-color: #d60044 !important; } .bg-brand-navy { background-color: #154360 !important; } .bg-brand-dark { background-color: #151441 !important; } .text-brand { color: #d60044 !important; } /* ------------------------------------------------------------------ * O bloco "Redesign visual (v8)" que existia aqui (.home-navbar, * .home-hero, .home-features, .home-footer etc.) foi REMOVIDO nesta * versao (v9). Causa raiz do bug reportado (texto da secao #features * invisivel): aquele redesign v8 carregava core.css/components.css/ * colors.css no de home.php - arquivos do TEMA DE DASHBOARD * ADMINISTRATIVO (Limitless), nao pensados para uma landing page * publica. Esses arquivos definem, em varios seletores genericos, * cores/heranca de texto pensadas para o contexto do backoffice * (sidebars escuras, paineis coloridos) que acabavam sendo herdadas * pelos elementos h4/p dentro de ".features-text" sem que nenhuma regra * ali definisse um "color" proprio e explicito - resultado: texto * branco (ou proximo disso) sobre fundo branco, ou seja, invisivel. * * A Home agora usa um CSS proprio e AUTOSSUFICIENTE * (assets/css/home-modern.css, carregado por ultimo em home.php) que * define explicitamente cor de fundo E cor de texto em toda secao, * sem depender de core.css/components.css/colors.css (que foram * REMOVIDOS do de home.php - continuam em uso apenas no * backoffice/admin). Bootstrap.css continua carregado (grid/reset/ * componentes basicos como carousel e navbar). * ------------------------------------------------------------------ */ /* ------------------------------------------------------------------ * Sistema de abas (Configuracoes / Notificacoes) - espacamento e cor * O tema (core.css) zera o padding-top do .panel-body quando ele vem * logo depois de um .panel-heading (regra pensada para paineis com * abas), entao o conteudo de cada aba ficava colado direto na faixa * branca abaixo das abas. Aqui devolvemos o respiro (mesmo valor de * 20px que o proprio tema usa em ".tab-content > .has-padding") so * dentro de paineis com abas, sem mexer nos demais paineis planos * (.panel-flat) que nao tem abas. * A cor de destaque da aba ativa tambem era o azul padrao do tema * (#2196F3) - trocada pelo vermelho da marca (#d60044, o mesmo do * cabecalho vermelho usado nas tabelas/paineis com bg-brand) para * ficar consistente com o resto do site. * ------------------------------------------------------------------ */ .panel-body > .tab-content { padding-top: 20px; } .nav-tabs.nav-tabs-highlight > li.active > a, .nav-tabs.nav-tabs-highlight > li.active > a:focus, .nav-tabs.nav-tabs-highlight > li.active > a:hover { border-top-color: #d60044; } /* No mobile (<=768px) o tema vira as abas numa lista em caixa e marca a aba ativa com uma barrinha lateral ::after com background-color (nao border-color) - regra separada da de cima, senao continua azul no celular mesmo com o fix acima. */ @media (max-width: 768px) { .nav-tabs.nav-tabs-highlight > li.active > a:after, .nav-tabs.nav-tabs-highlight > li.active > a:focus:after, .nav-tabs.nav-tabs-highlight > li.active > a:hover:after { background-color: #d60044; } } /* Tabelas (Faturas, Extrato, Saques, itens de fatura etc.) no mobile: a tabela ja rola horizontalmente (.table-responsive tem overflow-x:auto, inclusive quando envolve um .dataTables_wrapper), mas no celular a barra de rolagem some/fica quase invisivel - sem nenhum indicio visual, parecia coluna cortada/faltando em vez de "arraste pro lado". Aviso simples resolve sem mexer nos varios arquivos JS que inicializam cada tabela. Fica so no .table-responsive (nao em .dataTables_wrapper tambem) pra nao duplicar o aviso quando os dois envolvem a mesma tabela. */ @media (max-width: 768px) { .table-responsive:before { content: "\2194 Arraste a tabela para o lado para ver mais colunas"; display: block; font-size: 11px; color: #999; text-align: center; padding: 6px 0; } } /* O fundo azul-marinho do painel (#010031) so estava definido dentro de ".content-wrapper" sob "@media (min-width:769px)" (regra original do tema, components.css) - no celular ele nunca era aplicado e sobrava o cinza claro padrao do body, parecendo "branco". Mesma cor, sem media query, pra valer em qualquer tamanho de tela. */ .content-wrapper { background-color: #010031; } /* ADR-80: cliente confirmou que o vao branco (ADR-46/79) AINDA aparecia mesmo depois do min-height explicito no desktop - nao foi possivel reproduzir de novo aqui (testado ao vivo em producao, na pagina e conta exatas do relato, 1920x1080: html/body/page-container/ content-wrapper/rodape todos batendo exatamente com a altura da tela, sem sobra nenhuma medida via getBoundingClientRect). Ou seja, o min-height do ADR-79 esta correto matematicamente pro motor de renderizacao usado aqui pra testar (Chromium), mas alguma particularidade do navegador/tela real do cliente (motor diferente, zoom, arredondamento, ou "overscroll" revelando o fundo por tras ao rolar alem do conteudo) ainda deixa passar uma fresta. Em vez de continuar tentando acertar o pixel exato de um cenario que nao reproduz aqui, blindado por baixo: o proprio "body" (nao so ".content-wrapper") ganha o mesmo fundo azul-marinho - assim, mesmo que ".content-wrapper" fique curto por qualquer motivo nao identificado ainda, a cor por tras dele ja e a mesma, entao nenhuma fresta aparece como "branca" (cinza claro) de verdade nunca mais, independente da causa exata. Escopado a "body.navbar-top" (classe presente SO nas paginas de painel admin/cliente - ver ADR-41 - nao existe na Home publica nem nas telas de login, que tem fundo proprio com foto e nao podem virar azul-marinho solido). "html" nao precisa de regra propria: sem fundo explicito nele (confirmado ao vivo, transparente), o "body" com fundo definido ja propaga pro canvas da pagina inteira por especificacao do CSS. */ body.navbar-top { background-color: #010031; } /* Logomarca do topo (admin e cliente, classe ".dpx-panel-logo" no , substitui o antigo style inline width:180px/170px fixo com altura livre pro navegador calcular - resultado media so ~42-45px de altura dentro de um header de ~52-54px, sobrando vao vazio e ficando colada no topo com so 1px de margem. Trocado pra altura fixa + width:auto (mesma tecnica ja usada com sucesso na home, ADR-23), margem vertical simetrica pra centralizar. No mobile a altura e menor porque a largura resultante (proporcional, 4:1 no logo.png) precisa caber nos ~155px disponiveis a esquerda do sino/avatar/hamburguer (ver ADR-35/36) sem sobrepor. */ .dpx-panel-logo { float: left; height: 42px; width: auto; margin: 5px 0 5px 27px; } @media (max-width: 768px) { .dpx-panel-logo { height: 34px; margin-top: 10px; margin-bottom: 10px; } } /* Bug real, so em alguns celulares (confirmado no Zenfone 8 do cliente, DPR=2.75 - nao reproduzia em nenhuma largura de tela emulada, so no aparelho real): com o menu mobile aberto, o ".navbar-collapse" (onde fica a lista de itens) as vezes media so ~230px de largura em vez dos ~392px da tela, ficando encolhido e empurrado pra direita, com um vao vazio a esquerda - diagnosticado ao vivo via getBoundingClientRect()/getComputedStyle() no proprio aparelho do cliente (varias rodadas com prints). ".navbar-collapse.in" ganha "overflow-y:auto" so quando aberto (bootstrap.css) - isso cria um novo contexto de bloco (BFC), e um elemento BFC logo depois de um float (a logo, ".dpx-panel-logo", float:left, dentro do ".navbar-header" irmao anterior) pode ter sua largura calculada pra "desviar" do float em vez de ocupar o container inteiro, dependendo de arredondamento de subpixel do motor de renderizacao - o clearfix do proprio Bootstrap no ".navbar-header" deveria bastar, mas na pratica nao bastou nesse aparelho especifico. Forcando a largura aqui resolve independente do mecanismo exato. ADR-55: esse bloco tinha ficado sem media query (bug meu, as regras vizinhas mais abaixo neste arquivo tiveram o cuidado de escopar pra mobile, essa nao) - ".navigation-top{width:100% !important}" valendo tambem no desktop fazia o menu de links (float:left) ocupar 100% da largura da navbar inteira, sem sobrar espaco nenhum pro sino/perfil (float:right) ficarem ao lado - eles "quebravam" pra uma segunda linha por baixo, deixando a navbar fixa bem mais alta (150px em vez de 54px, medido ao vivo) do que o "body{padding-top:54px}" (ADR-43) compensava - o excesso ficava por cima da faixa branca da breadcrumb e da primeira fileira de cards, sem aparecer visualmente obvio na maioria das paginas (fundo escuro sobre fundo escuro se confundem; so ficou visivel de verdade quando a faixa branca ficava por baixo). Cliente reportou com print. Escopado pra mobile apenas, mesmo escopo de quando foi originalmente pensado (o bug do Zenfone 8 so acontecia no mobile mesmo). */ @media (max-width: 768px) { #navbar-mobile { width: 100% !important; float: none !important; clear: both !important; } #navbar-mobile .navigation-top { width: 100% !important; } } /* A logo maior (acima) deixou a navbar fixa com 54px de altura real (42px do logo + 5+5px de margem + ~2px de borda/padding do proprio tema), mas o tema tem ".navbar-top{padding-top:48px}" hardcoded (core.css, calculado pra a navbar ANTIGA de 46px) - o body inteiro empurra o conteudo so 48px pra baixo, entao os 6px finais da navbar ficavam por cima do topo da faixa branca da breadcrumb, cortando ela (reportado pelo cliente: "a faixa branca parece cortada"). Corrigido igualando ao valor real. "body.navbar-top" (tag+classe) tem especificidade maior que ".navbar-top" sozinho do tema, entao ganha independente da ordem de carregamento das folhas de estilo. Precisa ficar dentro de "min-width:769px": no celular o proprio tema tem ".navbar-fixed-top{position:static}" (core.css, media max- width:768px - a navbar deixa de ser fixa/flutuante de proposito nesse tamanho de tela, some do topo quando rola a pagina). Sem a navbar fixa, esse padding-top do body deixa de compensar sobreposicao nenhuma - ele so empurrava todo o conteudo (incluindo a propria navbar, que agora esta no fluxo normal) 54px pra baixo à toa, deixando um vao cinza vazio acima do menu no celular (reportado pelo cliente com print do proprio Zenfone 8). */ @media (min-width: 769px) { body.navbar-top { padding-top: 54px; } } /* Itens do menu mobile (layout "topo", admin e cliente - mesma classe ".navigation-top" nos dois temas): pedido do cliente apos ver o menu no celular - icone/texto pequenos (13px/16px) deixavam cada linha com muito vao vazio a direita mesmo ja ocupando 100% da largura (isso ja foi confirmado, nao e bug de layout). Aumentando o tamanho preenche melhor a linha sem mudar o alinhamento a esquerda. width+text-align no icone alinha o inicio do texto de forma consistente entre icones de larguras naturais diferentes (casa, moedas, arquivo, etc.). */ @media (max-width: 768px) { .navbar-nav.navigation-top > li > a { font-size: 16px; padding-top: 16px; padding-bottom: 16px; } .navbar-nav.navigation-top > li > a > i { font-size: 22px; width: 26px; margin-right: 6px; text-align: center; display: inline-block; } } /* Sombreamento sutil na logomarca, mesma tecnica (varias camadas de sombra empilhadas) usada nos titulos brancos dos slides da Home publica (.dpx-hero-caption h2 em home-modern.css), so que mais leve - aqui e sobre uma cor solida (vermelho), nao uma foto, entao nao precisa do mesmo peso/contraste. drop-shadow (nao text-shadow) porque e uma imagem, nao texto. */ .navbar-header > a > img { filter: drop-shadow(0 1px 1px rgba(0, 0, 0, .65)) drop-shadow(0 2px 4px rgba(0, 0, 0, .45)); } /* Submenus dentro do menu mobile (ex: "Rede" > Indicados Diretos/Sua Rede): o Bootstrap escurece o texto (#151441) pensando num fundo claro por tras - mas o fundo do painel e escuro (#010031), quase a mesma cor, entao o texto ficava praticamente invisivel (abria certinho, so nao dava pra ler). O estado hover/active ja usa laranja (#ff3300, visivel), so o estado normal precisava de ajuste. */ @media (max-width: 768px) { .navbar-default .navbar-nav .open .dropdown-menu > li > a { color: #fff; } } /* O menu mobile (#navbar-mobile) e um .navbar-collapse dentro de .navbar-fixed-top - o Bootstrap limita isso a max-height:340px com scroll interno (pensado pra menus curtos). No admin, com todos os itens do menu mais um submenu aberto (ex: "ADM DPiX" > Home do Site/Sair), o conteudo passa de 340px - os itens no fim continuavam existindo e clicaveis, so ficavam fora da area visivel sem nenhum indicio de scroll, parecendo que o clique nao abriu nada. Deixa crescer livre em vez de cortar. */ @media (max-width: 768px) { #navbar-mobile { max-height: none; } } .recharge-panel-body { background: gray; /* For browsers that do not support gradients */ background: -webkit-linear-gradient(gray, white); background: -o-linear-gradient(gray, white); background: -moz-linear-gradient(gray, white); background: linear-gradient(gray, white); } /* Visualizacao de rede unilevel em bonequinhos (backoffice/tree/unilevel). Cada ".ul-node" e um cliente; ".ul-children" comeca escondido e so recebe o proximo nivel via AJAX quando o avatar e clicado. */ .ul-tree { text-align: center; padding: 10px 0 20px; } .ul-level { display: flex; flex-wrap: wrap; justify-content: center; gap: 40px; padding-top: 20px; margin-top: 10px; border-top: 1px dashed rgba(255, 255, 255, .15); } .ul-node { display: inline-block; vertical-align: top; /* Reserva espaco mais proximo do que o ".ul-info-card" (abaixo) ocupa quando aberto - antes o node so tinha a largura do avatar (64px), entao abrir "Detalhes do Usuario" fazia o card (ate 190px) invadir visualmente o espaco dos vizinhos, dando a impressao de que so ai os bonequinhos se afastaram (o gap do flex nao muda, so parecia mudar). */ min-width: 170px; } .ul-avatar-wrap { cursor: pointer; display: inline-block; padding: 8px; border-radius: 8px; transition: background-color .15s ease; } .ul-avatar-wrap:hover { background-color: rgba(255, 255, 255, .06); } .ul-avatar { width: 64px; height: 64px; border-radius: 50%; border: 3px solid #d60044; object-fit: cover; background: #fff; } /* Pendente/bloqueado: mesmo boneco, sem cor - "consegue clicar do mesmo jeito", so o visual muda. */ .ul-avatar.ul-inactive { border-color: #777; filter: grayscale(100%); opacity: .8; } .ul-name { color: #fff; font-size: 12px; max-width: 90px; margin: 4px auto 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .ul-has-more { color: #d60044; font-size: 11px; margin-top: 2px; } .ul-details-toggle { margin-top: 2px; } .ul-details-toggle a { /* Vermelho da marca (#d60044) tinha pouco contraste sobre o fundo escuro do painel - trocado pelo dourado usado nas letras "$Pi" da logomarca (sampleado direto de assets/images/logo.png: #FFBE00), bem mais legivel aqui. */ color: #FFBE00; font-size: 11px; text-decoration: none; } .ul-details-toggle a:hover { text-decoration: underline; } .ul-info-card { display: none; background: #151441; border: 1px solid #d60044; border-radius: 6px; padding: 10px 12px; margin: 8px auto 0; max-width: 190px; text-align: left; font-size: 12px; } .ul-info-row { color: #fff; padding: 2px 0; } .ul-children { display: none; width: 100%; } /* Modal "Editar Usuário" (admin/users/view.php) carrega a pagina de edicao inteira via .load(), incluindo seu proprio .content/.panel-body com padding pensado pra pagina cheia - empilhado com o padding normal do .modal-body isso deixava o formulario "espremido" (~64% da largura do modal) mesmo tendo bastante fundo escuro disponivel dos dois lados. Reduzindo os paddings so dentro deste modal (nao mexe na pagina real admin/users/edit/:id quando acessada direto). */ #modal_edit_user .modal-body { padding: 8px; } #modal_edit_user .content { padding: 0; } #modal_edit_user .panel { margin-bottom: 0; } #modal_edit_user .panel-body { padding: 15px 10px; } #modal_edit_user .panel-title { display: none; } /* ADR-76: mesmo ajuste do modal de Editar acima, pro novo modal "Alterar Senha" (admin/users/password.php, carregado via .load() do mesmo jeito). */ #modal_change_password .modal-body { padding: 8px; } #modal_change_password .content { padding: 0; } #modal_change_password .panel { margin-bottom: 0; } #modal_change_password .panel-body { padding: 15px 10px; } #modal_change_password .panel-title { display: none; } /* Paginas curtas (ex.: detalhe de fatura) deixavam ver o cinza claro do body abaixo do rodape do conteudo - so no mobile: no desktop o tema ja estica ".content-wrapper" corretamente (confirmado ao vivo, some qualquer altura de viewport), mas essa regra so existe pra telas >=769px em algum lugar do tema original. Medido ao vivo no aparelho (admin e cliente, layout "topo"): sobram 56px acima do ".content-wrapper" (menu mobile, que fica no fluxo normal da pagina nesse tamanho de tela, nao fixo - ver ADR-43). */ @media (max-width: 768px) { .content-wrapper { min-height: calc(100vh - 56px); } } /* ADR-79: cliente reportou o mesmo vao vazio (fundo cinza claro do body) abaixo do rodape, dessa vez no DESKTOP (print real, pagina de Retirada com o card bloqueado "EM ANDAMENTO" - pouco conteudo) - o ADR-46 tinha "confirmado ao vivo" que o mecanismo de tabela do proprio tema (".page-content{display:table-row}") sempre esticava ".content-wrapper" ate a altura cheia no desktop sem precisar de min-height explicito, mas esse teste claramente nao cobria todo cenario real (o cliente reproduziu o vao numa tela/navegador real; nao foi possivel reproduzir via viewport emulado em varias resolucoes testadas aqui - o mecanismo de tabela e frágil o bastante pra falhar silenciosamente dependendo de zoom/DPI/altura exata do navegador real). Em vez de continuar dependendo desse truque so no desktop, aplicado aqui o mesmo min-height explicito ja usado no mobile acima, so que com o deslocamento certo pro desktop: a navbar aqui e FIXA (nao ocupa espaco no fluxo normal - "body.navbar-top{padding-top:54px}" do ADR-41/43 ja compensa isso), entao ".content-wrapper" comeca logo depois desse padding e so precisa esticar o restante ("calc(100vh - 54px)"; no mobile a navbar fica no fluxo normal, por isso o calculo de la usa 56px e nao tem padding-top no body - os dois casos juntos sempre somam 100vh, sem depender do truque de tabela em nenhum tamanho de tela). */ @media (min-width: 769px) { .content-wrapper { min-height: calc(100vh - 54px); } } /* O rodape (".dpx-panel-footer" abaixo) ficava logo depois do conteudo real da pagina, sobrando um vao escuro vazio embaixo dele em qualquer pagina mais curta que a tela (reportado pelo cliente com print - o rodape "flutuava" no meio da pagina em vez de ficar fixo no fim de verdade). Tentei o truque classico de flex-column primeiro (".content-wrapper{display:flex}" + ".content{flex:1}"), mas quebrou o desktop: ".page-content" (pai de ".content-wrapper") e "display:table-row" (truque antigo do proprio tema pra altura cheia sem flex) - isso so estica automaticamente um filho de altura "auto" via celula de tabela anonima gerada pelo navegador em volta de um filho normal (display:block), e "display:flex" tira o content-wrapper dessa categoria, perdendo o esticamento (confirmado ao vivo: sem flex, content-wrapper ja chega em 846px de altura sozinho num viewport de 900px de teste; com flex, cai pra so 338px). Trocado pra posicionamento absoluto - nao mexe no "display" nem no mecanismo de altura existente (nem o da tabela no desktop nem o "min-height:calc()" no mobile acima), so fixa o rodape na base da caixa de ".content-wrapper" (que ja tem a altura certa nos dois casos), com "padding-bottom" reservando o espaco pra ele nao sobrepor o ultimo conteudo real em paginas longas. */ .content-wrapper { padding-bottom: 90px; } /* ADR-81: pedido do cliente - em paginas com conteudo de verdade (ex: tabela de Pedidos de Saques com linhas), o rodape "position:absolute" acima fica no fim da PAGINA (precisa rolar pra ver), nao no fim da TELA visivel - o cliente queria o rodape sempre visivel, fixo na base da janela do navegador, independente de rolagem ou quantidade de conteudo (como uma barra fixa, nao "fim de pagina"). Trocado de absolute (relativo a ".content-wrapper") pra fixed (relativo a janela do navegador, sempre na mesma posicao na tela) - z-index baixo o suficiente pra nao cobrir modais/dropdowns (que usam valores bem mais altos no Bootstrap), mas acima do conteudo normal da pagina. O "padding-bottom" em ".content-wrapper" acima continua necessario - sem ele, com o rodape agora fixo (fora do fluxo normal), a ultima linha real de conteudo ficaria escondida atras dele. */ .dpx-panel-footer { position: fixed; left: 0; right: 0; bottom: 0; z-index: 100; } /* Rodape do painel (admin e cliente) - mesmo texto de copyright da home (welcome/home.php), mais credito de desenvolvimento pedido pelo cliente. Cor solida (nao o efeito vidro/glass da home, que usa variaveis CSS de home-modern.css - nao carregado aqui) pra combinar com o resto do tema escuro do painel. */ .dpx-panel-footer { background-color: #010031; border-top: 1px solid rgba(255, 255, 255, .08); padding: 16px 20px; text-align: center; margin-top: 20px; } .dpx-panel-footer p { margin: 0 0 4px; font-size: 12px; color: rgba(255, 255, 255, .55); } .dpx-panel-footer p:last-child { margin-bottom: 0; } .dpx-panel-footer span { color: rgba(255, 255, 255, .85); font-weight: 600; } .dpx-panel-footer a { color: rgba(255, 255, 255, .75); text-decoration: none; } .dpx-panel-footer a:hover { color: #FFF; text-decoration: underline; } /* Cliente reportou um vao branco vazio acima da primeira aba em toda tela com abas no mobile (Configuracoes do cliente/admin, Editar Usuario, Notificacoes). Causa: regra do proprio tema base (core.css, @media max-width:768px) - ".nav-tabs::before{content:"Contents"; ...}" - um rotulo decorativo ("Contents", em ingles, nunca usado/traduzido de proposito em nenhuma pagina deste app) que o tema original mostra acima de qualquer lista de abas no mobile. "color:inherit" resolve pra branco dentro do fundo branco do ".panel-heading" aqui (confirmado via getComputedStyle: color real = rgb(255,255,255) sobre fundo branco) - o texto fica invisivel mas o espaco dele (margem+altura da linha) continua reservado, sobrando como vao vazio. Removido em vez de so recolorir, ja que nao faz sentido nenhuma pagina do site ter esse rotulo (nunca foi usado/traduzido de proposito). */ @media (max-width: 768px) { .nav-tabs::before { content: none; } } /* ADR-67: cliente ainda via um vao branco acima da aba "Nao Lidas" na pagina de Notificacoes (admin e cliente), mesmo com o fix acima (::before) ja aplicado - essa pagina tem uma causa ADICIONAL e diferente da do ADR-53: seu ".panel-heading" tem um "
Notificacoes
" ALEM das abas (Configuracoes, unica outra pagina afetada pelo ADR-53, nao tem titulo nenhum no heading, so as abas - por isso nunca teve esse segundo problema). Esse titulo herda "color:#fff" do body (tema escuro, bootstrap.css) mas o ".panel-heading" aqui e simples, sem nenhuma classe "bg-*" (diferente de outros paineis com titulo do app, tipo "Pedidos de Saques" ou "Minhas Faturas", que sempre usam bg-brand+text-white de proposito) - entao fica branco sobre o fundo branco padrao do Bootstrap pra ".panel-heading", invisivel, mas reservando a propria altura como espaco vazio. Corrigido tornando o titulo visivel (cor escura) so quando o panel-heading NAO tem nenhuma classe "bg-*". */ /* ADR-77: cliente reportou que os titulos das listas em Configuracoes > Avisos/Popup/Slides ficaram "apagados" (cinza) - incluindo o icone de "Lista de pop-ups", que ele achou que tivesse sumido (na verdade sempre esteve no HTML, so ficou invisivel pelo mesmo motivo do titulo, ja que o icone herda a mesma cor do texto). Causa: a regra do ADR-67 acima e "cega" a ONDE o panel-heading esta - ela deixa o titulo escuro (#333) sempre que a classe "bg-*" esta ausente, o que so estava correto pros 3 casos originais (Notificacoes/Arvore binaria/FAQ), que usam ".panel-flat"/".panel-default"/".panel-white" (fundo CLARO garantido por essas classes). Esses paineis de lista (Avisos/Popup/Slides, e "Lista de administradores" que tem o mesmo problema, corrigida de brinde) usam so "
" sem nenhum modificador - nao tem fundo claro nenhum garantido, entao o titulo escuro ficava ilegivel sobre o azul-marinho escuro do painel por tras. Reescrito como 2 regras separadas: escuro (#333) só quando HOUVER garantia de fundo claro (.panel-flat/.panel-default/.panel-white); branco nos demais paineis sem "bg-*" (o caso original do ADR-67 pretendia cobrir, mas era grande demais). */ .panel-flat > .panel-heading:not([class*="bg-"]) .panel-title, .panel-default > .panel-heading:not([class*="bg-"]) .panel-title, .panel-white > .panel-heading:not([class*="bg-"]) .panel-title { color: #333 !important; } .panel:not(.panel-flat):not(.panel-default):not(.panel-white) > .panel-heading:not([class*="bg-"]) .panel-title { color: #fff !important; } /* Dropdown de ano/mes do filtro do Extrato/Relatorio (ADR-48/49) - ".dropdown-menu" do Bootstrap tem "min-width:160px" fixo (bootstrap.css), bem mais largo que precisa pra opcoes curtas tipo "Set"/"2026", alargando o menu bem alem do botao que abriu ele (reportado pelo cliente com print). Estreitado pro tamanho do proprio conteudo. */ .dpx-dropdown-narrow { min-width: 0; width: auto; } .dpx-dropdown-narrow > li > a { padding: 3px 14px; white-space: nowrap; } /* Cliente reportou (print em tela bem larga, ~1860px) um vao vazio enorme no menu "topo" (admin e cliente) entre os links (Home/ Clientes/.../Configuracoes, encostados a esquerda) e o sino/perfil (encostados a direita) - a navbar nao tinha nenhum limite de largura (sem ".container", diferente da home publica), entao o vao cresce sem limite conforme a tela fica mais larga. Primeira tentativa (nao ficou boa, corrigida ainda nesta rodada): limitar ".navbar-header"/".navbar-collapse" (os 2 blocos internos) direto - quebrou o menu de verdade. Causa: "#navbar-mobile .navigation-top{width:100% !important}" (ADR-44, sem media query, ou seja ativo tambem no desktop) passou a valer 100% de um ".navbar-collapse" agora mais estreito (1600px em vez da tela toda) - o menu de links (float:left) ocupava esses 1600px inteiros, sem sobrar espaco nenhum pro sino/perfil (float:right) ficarem ao lado - eles "quebravam" pra uma segunda linha por baixo, deixando a navbar fixa bem mais alta (150px, medido ao vivo) do que o "body{padding-top:54px}" (ADR-43) compensava - o excesso ficava por cima da faixa branca e da primeira fileira de cards (exatamente o que o cliente reportou no print seguinte: "engolindo os cards"). Motivo de nao ter aparecido antes: sem limite nenhum, ".navbar-collapse" e ".navigation-top" a 100% sempre bateriam com a tela toda de qualquer forma - o efeito so apareceu ao restringir especificamente esses blocos. Corrigido primeiro limitando a navbar INTEIRA (o wrapper de fora, ".navbar-fixed-top") pra nao arriscar interagir com a regra do ADR-44 - funcionou (altura de volta a 54px, sino/perfil na mesma linha), mas cliente reportou um efeito colateral esperado: a barra de fundo (cor solida) tambem ficou limitada a 1600px, sobrando fundo BRANCO do body (nao a cor do tema) nos dois cantos em telas mais largas que isso - a barra parou de ir de ponta a ponta. Como o ADR-55 (acima) ja corrigiu a causa raiz de verdade (a regra ".navigation-top{width:100%}" sem media query), o proximo passo foi voltar a limitar so o CONTEUDO (".navbar-header"/".navbar-collapse") como na ideia original - a barra em si voltou a ir de ponta a ponta (ADR-56), mas isso trouxe um efeito colateral novo, tambem reportado pelo cliente com print: limitar+centralizar cada bloco (logo E menu+icones) SEPARADAMENTE, dentro da tela inteira (sem limite), empurrava os dois pra dentro, longe das bordas de verdade - sobrava azul vazio tanto a esquerda da logo quanto a direita do sino/perfil, o oposto do que faz sentido (logo e perfil de painel normalmente ficam grudados nos cantos). Solucao final: nao limitar/centralizar NADA (nem a barra, nem os blocos) - a logo e o sino/perfil voltam a ficar exatamente nos cantos de sempre (jamais deveriam ter se movido). O vao vazio no meio (o problema original) e resolvido de outra forma: em vez de encolher o container, o proprio menu de links (".navigation-top") passa a se CENTRALIZAR dentro do espaco sobrando entre a logo e o sino/perfil, via "display:flex" no ".navbar-collapse" + "margin:0 auto" no ".navigation-top" (truque classico de flexbox - com margem automatica nos dois lados, o item consome sozinho todo o espaco livre disponivel, dividido igualmente pra cada lado; o irmao seguinte, ".navbar-right", sem margem nenhuma, cai exatamente coladinho na borda direita do container por definicao matematica do algoritmo de flexbox, sem precisar de nenhum "max-width"). Resultado: logo grudada a esquerda, sino/perfil grudado a direita (nenhum dos dois se move), menu de links centralizado no meio - o vao que antes ficava todo concentrado de um lado agora fica dividido em 2 vaos menores e simetricos, visualmente mais equilibrado. So desktop (min-width:769px) - no mobile o menu ja usa 100% da largura empilhado verticalmente (ADR-44), esse flex e irrelevante la (troquei a media query pra nao interferir). Nao mexe na largura dos cards/paineis abaixo do menu (esses continuam de ponta a ponta de proposito, decisao de design ja existente, fora do escopo deste ajuste). Detalhe tecnico: ".navbar-collapse{display:flex !important}" sozinho (especificidade 0,1,0) nao bastou pra vencer o empate - medido ao vivo que o "display" continuava "block" mesmo com essa regra corretamente carregada e sem nenhuma outra regra rival encontrada via inspecao do CSSOM (nenhum ".navbar-collapse{display:...}" concorrente em nenhuma outra folha de estilo). Confirmado por teste direto que "#navbar-mobile.navbar-collapse" (id+classe, especificidade 1,1,0) vence - trocado pro id "#navbar-mobile" (presente nos dois temas, admin e cliente) pra garantir. */ @media (min-width: 769px) { #navbar-mobile { display: flex !important; align-items: center; } .navigation-top { float: none !important; margin-left: auto; margin-right: auto; } } /* ADR-58: dropdown de notificacoes (sino, preview) + pagina completa de notificacoes - cliente reportou (print) texto ilegivel: o tema original pensa essas cores pra um dropdown de fundo BRANCO (padrao Limitless), mas aqui o fundo e o azul-marinho escuro do resto do painel - titulo "NOTIFICAÇÕES" saia cinza escuro (quase invisivel) e a frase de cada notificacao saia azul (cor de link padrao, tambem baixo contraste sobre o azul-marinho de fundo). Tambem sem nenhum separador entre notificacoes (ficavam grudadas umas nas outras) e o rodape "Ver todas as notificações" tinha fundo branco solido, destoando do resto do dropdown escuro - o efeito de "uma area dentro da outra" que o cliente descreveu. Mesmas classes usadas nos dois temas (admin e cliente) e nas duas paginas (dropdown + pagina completa de notificacoes), corrige os 4 lugares de uma vez. Frase da notificacao em laranja/dourado - mesma cor ja usada nos links da arvore unilevel (".ul-details-toggle a", ADR-33), amostrada diretamente do "$Pi" da logo. */ .dropdown-content-heading { color: rgba(255, 255, 255, .5) !important; font-size: 11px; letter-spacing: .5px; } .media-list .media-heading { color: #FFF !important; } .media-list .media-body p { color: #FFBE00 !important; } .dropdown-content-body .media-list > li.media { padding: 10px 15px; margin: 0; border-bottom: 1px solid rgba(255, 255, 255, .08); } .dropdown-content-body .media-list > li.media:last-child { border-bottom: 0; } .dropdown-content-footer { background-color: transparent !important; border-top: 1px solid rgba(255, 255, 255, .1); } .dropdown-content-footer a { color: rgba(255, 255, 255, .85) !important; } .dropdown-content-footer a:hover { color: #FFBE00 !important; } /* ADR-59: cliente reportou "2 barras de rolagem" no dropdown de notificacoes - era mesmo uma area rolavel dentro da outra, so que a segunda nao estava onde eu primeiro suspeitei. O "
  • " (estilo inline original, max-height:300px) e so METADE da historia - o tema base (core.css) TEM uma segunda regra independente, num seletor bem especifico so pra essa combinacao exata (dropdown de notificacao dentro da navbar): ".navbar-nav > li > .dropdown-menu .media-list{max-height:340px; overflow-y:auto}" - essa mira o "