Instalação
O MevvBlocks precisa do WordPress 6.0 ou mais recente e do PHP 8.1 ou mais recente. Não há outra dependência: nenhuma biblioteca externa, nenhuma fonte no servidor de outra pessoa, nenhuma etapa de build.
- Envie e ative o plugin.
- Abra uma página no editor de blocos e adicione o bloco Contêiner.
- Coloque dentro dele os blocos que quiser. Você os encontra na categoria Design.
- Gerencie o resto pelo menu MevvBlocks na barra lateral do admin.
- O WooCommerce é opcional. Instalá-lo acrescenta dois blocos.
- O MevvBridge é opcional. Se você veio do Elementor, o MevvBlocks é o que torna aquelas páginas editáveis de novo.
- O MevvLegal é opcional. Se ele estiver presente, o bloco de mapa entrega o embed ao MevvLegal para que o mapa não seja carregado antes de o visitante consentir.
O Pro é um plugin separado instalado ao lado do gratuito, e declara o plugin gratuito como requisito obrigatório. Sua chave de licença é inserida na tela Lisans (Licença). Sem o Pro, o MevvBlocks não faz nenhuma requisição aos nossos servidores.
Estilo por tamanho de tela — a lacuna que isso fecha
Os blocos do núcleo aceitam um valor de espaçamento interno, uma altura mínima, uma contagem de colunas. Esse valor vale em todas as telas. Se uma seção precisa de 100 pixels de espaçamento no desktop e 40 no celular, o núcleo não consegue expressar isso — e essa única lacuna é o motivo técnico mais comum para instalar um construtor de páginas.
O MevvBlocks guarda três valores em vez de um — desktop, tablet, celular. Os limites são fixos:
- Desktop
- Sem media query — o valor base.
- Tablet
- Vale de 1024 pixels para baixo.
- Celular
- Vale de 767 pixels para baixo.
Os mesmos dois números são usados em todo o resto do plugin — o limite do menu hambúrguer, as contagens de colunas da grade. Um campo livre de pixels foi deliberadamente não oferecido: quem escolhesse 900 teria o hambúrguer em 900 enquanto o espaçamento continuaria mudando em 1024, e dois sistemas de breakpoints significam layouts que discordam de si mesmos.
Os valores vivem nos próprios atributos do bloco, dentro de post_content — não em uma tabela personalizada nem em post meta. O CSS é produzido no servidor, no momento da requisição, e impresso como um pequeno bloco de estilo junto ao elemento a que pertence.
Por que não salvar o CSS junto com a página? Porque o HTML salvo só consegue carregar um breakpoint. Renderizar na requisição é o que torna os três valores possíveis — e é por isso que uma licença vencida nunca pode apagar uma página publicada: não existe uma única verificação de licença nesse caminho.
A pré-visualização do editor — o que ela mostra e o que ainda não consegue
Esta página costumava dizer que a pré-visualização era uma aproximação. Não é mais, no que toca ao layout. A tela de edição agora pede ao servidor o mesmo CSS que a página vai imprimir e o aplica às mesmas classes de invólucro que o front-end usa.
O que é exato na tela de edição hoje: layout do container (direção, colunas, espaçamento, alinhamento), espaçamento interno, margem, fundo, borda, raio, sombra, altura mínima, tipografia, transformações, máscaras e posicionamento — com os valores de tablet e celular valendo conforme você redimensiona, porque a tela é um iframe e as media queries funcionam dentro dele.
Por que o CSS vem do servidor em vez de ser reconstruído em JavaScript: existe um único motor de estilos, e uma segunda cópia sairia do compasso da primeira. No dia em que alguém acrescentasse uma configuração a um e esquecesse o outro, o editor estaria errado enquanto afirma ser exato — pior do que a antiga aproximação honesta.
O que ainda não é exato: regras que miram a marcação dentro de um bloco. Na tela de edição um bloco desenha seus próprios recursos de edição, então um seletor escrito contra a estrutura de front-end não tem com o que casar. Fechar isso significa deixar a marcação de edição idêntica à marcação publicada em cada um dos cento e um blocos; é trabalho real e não está feito.
Medido, não afirmado: a mesma seção foi renderizada duas vezes sob a mesma folha de estilos — uma como o front-end a imprime, outra como a tela de edição a constrói — e dezesseis propriedades de layout foram comparadas em cada elemento. A tela antiga diferia em vinte e quatro delas. Agora são zero de sessenta e quatro. A ferramenta que mede isso está no código-fonte do plugin (tools/onizleme-esitlik.js), e ela foi primeiro apontada para a marcação antiga para provar que não estava cega.
Os blocos
Cento e um blocos, ou setenta e oito sem o WooCommerce. Todos estão na edição gratuita; nenhum bloco é exclusivo do Pro. Eles ficam na categoria Design do inseridor.
- Layout e texto
- Container, Título, Texto, Botão, Divisor, Espaçador, Âncora, Imagem, Shortcode, Citação, Lista de verificação, Tabela, Código
- Apresentação
- Depoimento, Ícone, Caixa de ícone, Lista de ícones, Caixa de imagem, Ícones sociais, Direitos autorais, Membro da equipe, Avaliação por estrelas, Tabela de preços, Lista de preços, Selo, Banner, Faixa de logotipos, Caixa de número, Alerta
- Interação
- Slider, Slides, Abas, Acordeão, Menu de navegação, Formulário de busca, Formulário, Formulário de login, Formulário de cadastro, Sumário, Compartilhamento social, Perguntas frequentes, Linha do tempo, Etapas
- Conversão
- Flip box, Chamada para ação, Título animado, Antes / Depois, Ponto interativo, Painel lateral, Botões de contato, Barra de aviso, Comparação, Barra de dados, Progresso de leitura, Tempo de leitura, Voltar ao topo, Texto em um traçado
- Mídia
- Vídeo, Áudio, Galeria
- Dados e tempo
- Grade de conteúdo, Contagem regressiva, Contador, Barra de progresso, Mapa
- Modelos de site e de tema
- Logotipo do site, Título do site, Descrição do site, Título da página, Trilha de navegação, Informações do post, Caixa do autor, Comentários, Anterior / Próximo, Título do arquivo, Descrição do arquivo, Mapa do site
- WooCommerce (20)
- Produtos, Categorias de produto, Galeria do produto, Título do produto, Preço do produto, Avaliação do produto, Descrição curta, Descrição do produto, Metadados do produto, Informações adicionais, Abas do produto, Adicionar ao carrinho, Situação do estoque, Produtos relacionados, Upsells, Vendas cruzadas, Minicarrinho, Carrinho, Checkout, Minha conta, Rastreamento do pedido, Ordenação de produtos, Contagem de resultados — adicionados apenas quando o WooCommerce está ativo
Efeitos de movimento não são um bloco: um painel Movimento é adicionado a cada bloco do MevvBlocks.
Nada aqui fica escondido quando o JavaScript não carrega. As abas mostram todos os painéis, o acordeão é um elemento details nativo, o slider rola, e as setas são impressas ocultas até o script poder controlá-las — mostrar um botão que não faz nada é mostrar uma interface quebrada. Conteúdo escondido é conteúdo inacessível.
Grade de conteúdo e construtor de loop
O bloco Grade de conteúdo consulta posts, páginas ou produtos e os organiza. A paginação são links simples, então funciona com o JavaScript desligado.
- A ordenação é uma lista fixa — data, modificação, título, ordem de menu, aleatório — porque o valor chega ao banco de dados.
- Os títulos dos cartões vão de h2 a h6. O h1 não é oferecido: uma grade de cartões em uma página que já tem um h1 quebraria a ordem dos títulos.
- Um link por cartão. Fazer da imagem, do título e do “leia mais” três links significa que um leitor de tela anuncia o mesmo destino três vezes.
- A grade guarda em cache os ids dos posts que encontrou, nunca o HTML renderizado, e o cache é invalidado quando qualquer post é salvo — então “publiquei um post e ele não aparece” não pode acontecer.
O construtor de loop deixa você desenhar o cartão em vez de usar o embutido. Você cria um modelo do tipo Cartão de loop, monta-o com blocos comuns e vínculos dinâmicos, e o escolhe nas configurações da grade.
Enquanto você edita um modelo de cartão não há contexto de post, então os vínculos dinâmicos mostram seus valores estáticos de reserva. E se o modelo estiver vazio, apagado, em rascunho ou apontar para si mesmo, a grade recorre ao cartão embutido em vez de não imprimir nada. O aninhamento de loops é limitado a dois níveis.
O motor de formulários
Dezesseis tipos de campo, com validação no servidor. O formulário é a única parte de uma página que realmente faz alguma coisa, então ele funciona sem JavaScript: um envio POST simples recebe a mesma validação e as mesmas mensagens de um envio com script.
- Tipos de campo
- Texto, E-mail, Telefone, Endereço (URL), Número, Data, Hora, Oculto, Texto longo, Lista suspensa, Lista de múltipla escolha, Escolha única, Múltiplas caixas de seleção, Caixa de seleção, Texto do consentimento (KVKK) e Subtítulo. O Pro acrescenta um campo de envio de arquivo.
- Para onde vão os envios
- Para uma tabela própria e também para o e-mail. O registro é gravado primeiro e o e-mail enviado depois, porque a entrega de e-mail falha muito mais do que uma gravação no banco de dados.
- Lendo os envios
- MevvBlocks → Envios de formulário. O Pro acrescenta ali uma exportação em CSV.
- E-mail de notificação
- O remetente é o seu site, nunca o visitante. Usar o endereço do visitante como remetente é o motivo mais comum de o e-mail de formulário nunca chegar — SPF e DMARC o rejeitam. O endereço dele vira o Reply-To.
O spam é tratado por três camadas e nenhum CAPTCHA: uma assinatura que não depende de sessão, um tempo mínimo de preenchimento e um campo honeypot. Um envio que preenche o honeypot é aceito em silêncio e descartado — mostrar um erro diria ao bot que ele foi pego, e a próxima tentativa pularia aquele campo.
Por que uma assinatura em vez de um nonce do WordPress? Um nonce está preso a uma sessão e a uma janela de doze horas. Em um site com cache, o mesmo HTML é servido por horas ou dias, o nonce dentro dele já expirou faz tempo, e o formulário para de funcionar em silêncio. Essa é a falha de campo mais comum dos plugins de formulário. A assinatura usada aqui vale sete dias e não depende de quem está navegando.
O endereço IP de um envio nunca é armazenado em forma legível — apenas um resumo criptográfico, salgado com a chave do seu próprio site, de modo que registros de dois sites diferentes não podem ser cruzados.
O armazenamento dos envios não está preso à licença. Se estivesse, o dia em que um pagamento vencesse seria o dia em que o cliente começaria a perder dados.
Modelos de tema
Sete tipos de modelo, construídos no editor do WordPress que você já usa — Cabeçalho, Rodapé, Conteúdo individual, Arquivo, Resultados da busca, Não encontrado (404) e Cartão de loop. Um segundo editor seria mais uma coisa a manter em passo com o núcleo do WordPress.
O tipo e as condições ficam em uma caixa lateral simples, não em um painel React — uma caixa clássica também salva com o JavaScript desligado, e não quebra quando a API do editor muda.
- Condições
- Site inteiro, página inicial, tipo de post, categoria ou um conteúdo específico. Deixe-as vazias para o site inteiro.
- Quando várias correspondem
- Vence a condição mais estreita.
- Condições malformadas
- Descartadas ao salvar e armazenadas vazias, em vez de mantidas como texto inválido que faria o modelo nunca aparecer em silêncio.
Os modelos de cabeçalho e rodapé só são aplicados no Astra e no GeneratePress. Se o seu tema não tem receita, eles não são impressos e a tela avisa — acoplar um cabeçalho a um tema que não conseguimos levantar significa dois cabeçalhos, garantido. Os modelos de conteúdo individual, arquivo, busca e 404 continuam funcionando em qualquer tema, porque substituem o loop e deixam o cabeçalho e o rodapé do próprio tema no lugar.
Um modelo de Cartão de loop nunca se coloca em lugar nenhum sozinho. Quem o escolhe é um bloco de grade.
Biblioteca de padrões e predefinições de bloco
Vinte padrões prontos: dezesseis seções e quatro páginas completas. Eles são registrados como padrões comuns do WordPress, então você os insere do jeito que já conhece — o botão +, a aba Padrões e depois a categoria Seções do MevvBlocks ou Páginas do MevvBlocks.
Nenhum modal personalizado foi escrito para isso. O inseridor do núcleo já dá pré-visualização, busca, navegação por teclado e tradução de graça, e o que ele insere é marcação de blocos comum — nada a que ficar preso.
Os padrões vêm sem imagens. Puxar imagens de outro lugar é uma questão de direitos autorais, uma questão de privacidade, e amarra a aparência da sua página ao servidor de outra pessoa continuar no ar. Os blocos de imagem estão no lugar com o texto alternativo preenchido; escolha as suas.
As predefinições de bloco salvam sob um nome as configurações de aparência de um bloco e as aplicam a outro bloco do mesmo tipo. O conteúdo deliberadamente não é salvo — texto, links, imagens e itens de lista são removidos, então aplicar uma predefinição nunca sobrescreve o que você escreveu.
Os padrões não são registrados no front-end. Gerar a marcação deles a cada visualização de página foi medido em 109 KB e 3,59 ms — pagos por nada, já que ninguém insere um padrão enquanto lê.
Pop-ups
Construídos no editor de blocos como qualquer outra coisa; os gatilhos, as condições e a frequência ficam na barra lateral da mesma tela. Gerenciados em MevvBlocks → Pop-ups.
- Gatilhos
- No carregamento da página com atraso, a uma porcentagem de rolagem, na intenção de saída, em um clique que casa com um seletor CSS, ou após um período de tempo ativo. O cronômetro de atividade para enquanto a aba está em segundo plano.
- Condições
- Site inteiro, página inicial, páginas específicas, tipo de post ou categoria; logado, deslogado ou todo mundo; e por dispositivo.
- Frequência
- Toda vez, uma vez por sessão, ou uma vez a cada N dias.
- Aparência
- Posição, largura, se o título aparece, se clicar fora fecha, e a animação de abertura.
O contador de “não mostrar de novo” fica no próprio navegador do visitante, não no servidor. Contá-lo no servidor significaria cunhar uma identidade duradoura para cada visitante só para não lhe mostrar uma caixa duas vezes.
A segmentação por dispositivo é decidida pelo navegador, não por farejar o user agent. Um user agent não distingue com confiança um tablet de um celular, e atrás de um cache de página inteira serviria o dispositivo do primeiro visitante a todo mundo. Se nenhum gatilho for selecionado, o pop-up recai no carregamento da página; se nenhum dispositivo for selecionado, recai nos três — um pop-up que silenciosamente nunca aparece é pior do que um que aparece demais.
A paleta do site
Uma única tela para cores e tipografia, acessível tanto pelo menu do MevvBlocks quanto por Aparência, porque é ali que as pessoas procuram. Cada entrada mostra o próprio nome de variável, e os blocos se referem a esses nomes em vez de a valores literais.
É isso que permite a uma página construída antes da mudança adotar uma nova paleta em vez de perder suas referências — os nomes de variável continuam sendo os mesmos que as suas páginas já usam.
Não existe excluir. Uma cor ou um conjunto tipográfico pode ser deixado vazio, mas removê-lo deixaria todos os blocos que se referiam a ele apontando para nada. Esvaziar é reversível; apagar uma referência não é.
A auditoria de acessibilidade
MevvBlocks → Acessibilidade examina as suas páginas, posts e modelos publicados e relata o que cada bloco deixou de fora: uma imagem sem texto alternativo, um título vazio, um botão sem nome ou sem destino, uma ordem de títulos quebrada, um contraste baixo demais.
A mesma auditoria está disponível como painel lateral enquanto você ainda edita, que é onde um achado é mais barato de corrigir.
Isto deliberadamente não é uma camada sobreposta. Camadas que acoplam um “menu de acessibilidade” a uma página não consertam nada: uma imagem sem texto alternativo continua sem ele, e um texto de baixo contraste continua ilegível. Sustentar a afirmação “este site é acessível” sem que seja verdade é uma posição pior do que não afirmar nada — sites que usam overlays já foram processados exatamente por isso. Esta ferramenta mede e conta a você; a correção é sua.
O contraste só é relatado quando as duas cores são de fato conhecidas. Chutar uma cor herdada geraria avisos sobre os quais você não pode agir.
Velocidade — cache de elementos e imagens
Duas coisas distintas, ambas na edição gratuita.
Cache de elementos. A saída dos blocos é armazenada em vez de reconstruída a cada requisição. Medido: tempo de renderização dos blocos 33–72% menor. Usa um cache de objetos persistente (Redis, Memcached) quando existe, e transients quando não.
Um bloco cuja saída varia por visitante, por consulta ou por momento nunca é armazenado: formulários, login, cadastro, minicarrinho, grade de produtos, busca, carrinho, checkout, minha conta, shortcode. O shortcode está nessa lista porque não sabemos o que há dentro dele — uma vez congelamos um token do WPForms em um site real, e desde então a regra é aplicada a partir do código.
Otimização de imagens. Uma cópia WebP (opcionalmente AVIF) de cada imagem enviada é gravada ao lado da original; a original nunca é tocada. Medido: 39–78% menores. Um arquivo que não encolhe não é mantido — PNGs pequenos e chapados normalmente crescem em WebP.
As imagens são servidas dentro de um elemento <picture>: o endereço de cada formato está no HTML e o navegador escolhe. Decidir no servidor a partir do cabeçalho Accept foi deliberadamente descartado — quando o mesmo endereço varia por visitante, qualquer cache no caminho pode entregar o arquivo errado à pessoa errada.
Se outro plugin realmente está fazendo esse trabalho (LiteSpeed, ShortPixel, Imagify, Smush, EWWW, Optimole, Converter for Media), o MevvBlocks se afasta sozinho e explica por quê. A pergunta não é “está instalado?”, mas “ele consegue de fato rodar?”: o LiteSpeed com a otimização de imagens ligada mas sem chave de nuvem não faz nada.
Core Web Vitals — medidos nos seus visitantes
Core Web Vitals são dados de campo por definição: medidos nos navegadores de visitantes reais e reportados como o percentil 75 numa janela de 28 dias. Uma execução do Lighthouse é outra coisa — uma máquina, uma rede, um momento. Saber qual é qual é o que resolve a confusão do “o PageSpeed diz 98, o Search Console diz vermelho”.
A tela Web Vitals mostra três números por classe de dispositivo:
- LCP
- Quanto tempo o conteúdo principal leva para aparecer. Bom é 2,5 segundos ou menos.
- CLS
- Quanto a página se move enquanto se assenta. Bom é 0,1 ou menos.
- INP
- Quanto tempo a página leva para responder a um toque ou clique. Bom é 200 ms ou menos.
O script de medição ocupa cerca de um kilobyte e não carrega biblioteca alguma — o trabalho é feito pelo próprio PerformanceObserver do navegador. A amostragem é de 10% das visitas por padrão e quem decide é o navegador, não o servidor: se o servidor decidisse, a mesma URL produziria dois documentos HTML diferentes e um cache de página inteira serviria a todos aquele que visse primeiro.
Nada pessoal é coletado: nenhum IP, nenhum cookie, nenhum identificador. Três valores, uma classe de dispositivo e o caminho da página, armazenados no seu próprio servidor como contagens agrupadas. Nada é enviado a lugar nenhum.
Abaixo de cem amostras a tela não mostra número nenhum — ela diz quantas tem. Um percentil tirado de uma dúzia de medições é ruído, e um número errado é pior do que nenhum número, porque alguém vai agir com base nele. O percentil é lido de um histograma, então é aproximado à largura do intervalo, e a tela diz isso.
Transformações e máscaras
Qualquer bloco pode ser deslocado, escalado, rotacionado (em Z e 3D X/Y), inclinado e invertido — cada um com valores separados para desktop, tablet e celular. É possível definir uma transformação de hover separada e uma duração de transição.
As máscaras podem ser um círculo, triângulo, hexágono, mancha, flor, forma livre ou a sua própria imagem, com controles de tamanho, posição e repetição.
As formas são embutidas no CSS, não distribuídas como arquivos SVG separados. Um caminho de arquivo errado faz uma máscara sumir em silêncio e ninguém vê o 404; atrás de um CDN, o endereço da pasta do plugin também pode mudar.
Código personalizado para o site inteiro
HTML, CSS e JavaScript podem ser colocados no head, no início do body ou no final: tags de verificação, trechos de medição, pequenos ajustes de estilo. Posição, prioridade e uma condição de sessão são configuráveis.
Ele não roda PHP. Colocar um executor de PHP dentro de um construtor de páginas transformaria a permissão de um designer em permissão para rodar código no servidor.
A capacidade exigida é unfiltered_html: quem não pode colocar um script bruto em um post também não pode colocá-lo no site inteiro. Com o MevvLegal instalado, os scripts de rastreamento colocados aqui também ficam retidos até o consentimento de cookies ser dado.
Blocos do WooCommerce
Vinte blocos: título do produto, imagens, preço, adicionar ao carrinho, avaliação, estoque, metadados, descrição curta, descrição, abas de dados, informações adicionais, produtos relacionados, upsells, vendas cruzadas, carrinho, checkout, minha conta, rastreamento do pedido, ordenação e contagem de resultados.
Nenhum deles redesenha o WooCommerce. Todos chamam as próprias funções de modelo e shortcodes dele. Seu tema altera esses modelos e seus plugins se engancham neles — frete, parcelamento, avisos de estoque, tabelas de tamanho. Desenhar nossa própria marcação derrubaria tudo isso em silêncio.
Carrinho, checkout, minha conta e rastreamento do pedido são específicos de cada visitante: o cache de página inteira é desligado e eles nunca vão para o cache de elementos. Se o WooCommerce não estiver ativo, esses blocos não são registrados nem no servidor nem no editor.
Notas do editor
Você pode fixar uma nota em qualquer bloco: quem escreveu, quando, e se está resolvida.
As notas NUNCA são impressas na página. Naquele arquivo não existe um único hook de front-end e um teste garante isso. Notas são conversa interna; um visitante vê-las seria pior do que um layout quebrado.
Uma nota está ligada à identidade do bloco. Duplicar um bloco dá à cópia uma identidade NOVA, então ela não herda a nota — e, como benefício adicional, ganha o próprio escopo de CSS.
As notas vivem nos próprios dados do post: apague o post e as notas vão junto, sem deixar linhas órfãs.
IA no editor — com a sua própria chave
Escrever, reescrever, encurtar, gerar texto alternativo de imagens e traduzir. Anthropic e OpenAI são suportados.
Você insere a SUA PRÓPRIA chave de API e a requisição vai do seu site DIRETAMENTE ao provedor. Seu texto nunca chega até nós; a cota e a conta continuam sendo suas. Não construímos um serviço de nuvem próprio: nesse caso o seu texto passaria pelos nossos servidores e a responsabilidade sobre os dados passaria a ser nossa.
A chave nunca chega ao navegador — a requisição é feita a partir do servidor. Ela também não é devolvida por nenhum endpoint; nem o formulário de configurações imprime o valor de volta.
NÃO criptografamos a chave, e dizemos isso com clareza: no WordPress a chave de criptografia precisa ficar no mesmo servidor, então um atacante com acesso ao banco de dados obtém as duas. Chamá-la de “criptografada” prometeria uma proteção que não existe.
O resultado não é escrito direto no bloco; ele chega como sugestão e você o aplica. Essa é a nossa defesa real contra uma frase enterrada no seu conteúdo ser lida como instrução — um humano aprova.
Free e Pro
A edição gratuita é o produto inteiro: todos os cento e um blocos, os modelos de tema, a grade e o construtor de loop, o motor de formulários com seu repositório de envios, o menu, a busca, os pop-ups, a biblioteca de padrões, as predefinições de bloco, a paleta global, a otimização de imagens, o cache de blocos, o código personalizado para o site inteiro, as notas do editor, a tela de Core Web Vitals e a auditoria de acessibilidade.
O Pro acrescenta capacidades de edição, não de saída:
- Pontos de interrupção — as abas desktop / tablet / celular, com altura mínima, largura do conteúdo, largura e os quatro valores de espaçamento interno por ponto de interrupção.
- CSS personalizado por bloco, onde o token
selectorrepresenta o próprio bloco. - Extras de formulário — campos condicionais, uma resposta automática ao remetente, um webhook e um campo de envio de arquivo.
- Exportação em CSV dos envios de formulário.
Os painéis de pontos de interrupção e de CSS personalizado aparecem hoje nos blocos principais — Contêiner, Título, Texto, Botão, Separador, Imagem, Depoimento, Ícone, Caixa de ícone, Lista de ícones, Shortcode, Formulário, Produtos e Categorias de produtos. Vários controles por ponto de interrupção são gratuitos onde quer que existam: o número de colunas da grade em tablet e celular, o limite do menu hambúrguer, a posição da caixa de imagem no celular e a escolha de dispositivo da posição fixa.
Quando uma licença expira ou está ausente:
- Seu site fica exatamente igual. Cada valor salvo para tablet e celular continua sendo impresso, e cada regra de CSS personalizado por bloco também. Isso não é uma promessa, é uma regra arquitetural: nenhum arquivo do caminho de renderização pergunta pela licença, e um teste verifica isso a cada versão.
- Os formulários continuam sendo enviados, continuam salvando e continuam mandando e-mail.
- Os pop-ups existentes continuam aparecendo.
- O que você perde são os painéis Pro no editor — e só isso.
Se os nossos servidores estiverem inacessíveis, uma licença ativa continua funcionando por sete dias. Uma instalação que nunca se verificou com sucesso não ganha carência nenhuma: bloquear o nosso endereço não é um jeito de conseguir o Pro.
Quando algo não funciona
- “A sessão do formulário expirou.”
- A cópia em cache daquela página tem mais de sete dias, ou as chaves de segurança do seu site foram rotacionadas. Limpe o cache de páginas.
- O formulário não manda e-mail
- Olhe primeiro a lista de envios — o registro é gravado antes do e-mail, então se ele está lá, o formulário funcionou e a entrega é que não. Depois confira o endereço do destinatário e a configuração de e-mail do seu site.
- A página parece certa no editor e errada no front-end
- A pré-visualização do editor é aproximada por design; veja acima. O front-end é a verdade. Se um bloco carrega valores de tablet ou celular, o editor imprime um aviso dizendo isso.
- Um bloco diz que é inválido quando tento editá-lo
- Historicamente isso acontecia com blocos registrados no servidor mas ausentes do script do editor — eles eram impressos perfeitamente e só falhavam quando abertos para edição. Agora um teste protege contra isso; se você ainda vir, informe o nome do bloco.
- A contagem regressiva mostra a hora errada
- A marcação carrega um instante-alvo absoluto, nunca “faltam X segundos”, então uma página em cache não consegue congelá-la. O bloco se corrige pelo relógio do servidor; se essa requisição estiver bloqueada, ele recai no próprio relógio do visitante em vez de falhar.
- O modelo de cabeçalho ou de rodapé não aparece
- Seu tema não tem receita. Só o Astra e o GeneratePress podem ser levantados; a tela avisa. Os outros tipos de modelo funcionam em qualquer tema.
- Apareceram dois cabeçalhos
- O MevvBlocks e o MevvBridge estão produzindo um cada. O MevvBlocks assume o espaço primeiro, de propósito — deixe o cabeçalho a cargo de apenas um dos dois.
- Os containers estão mais largos ou mais estreitos do que o definido
- Uma regra do tema está vencendo na especificidade. O Astra em particular estiliza os descendentes com muita força. Isso foi corrigido nos casos medidos aumentando a especificidade em vez de usar
!important; se você encontrar um caso novo, diga qual é o tema. - Um post publicado não aparece em uma grade
- Deveria aparecer. A grade guarda em cache apenas os ids dos posts, e salvar qualquer post invalida o cache. Se persistir, verifique se o tipo de post e a ordenação são os que você espera.
Limites
- A pré-visualização do editor é aproximada. Estrutura e conteúdo são mostrados; a aparência exata é o front-end.
- Os modelos de cabeçalho e rodapé só funcionam no Astra e no GeneratePress. Qualquer outro tema não recebe nada, mais um aviso — o silêncio seriam dois cabeçalhos.
- O mapa é um embed do OpenStreetMap. Um marcador, sem imagem de marcador personalizada, sem estilização do mapa, sem rotas. Sem chave de API, sem conta de faturamento e sem nenhuma chave no código-fonte da sua página.
- Sem camada de acessibilidade sobreposta. Apenas medir e relatar.
- Sem CAPTCHA.
- Sem busca ao vivo. Uma requisição por tecla digitada é uma dependência e uma superfície de limite de taxa.
- A contagem regressiva usa o fuso horário do site, não o do visitante. Uma campanha termina em um único instante no mundo todo.
- O menu oferece dois breakpoints, não um valor livre em pixels, e não tem modo fly-out nem off-canvas — um painel deslizante com gerenciamento de foco é justamente para o que serve o bloco de pop-up.
- Os cartões da grade não podem ser h1, e o aninhamento de loops para em dois níveis.
- O conteúdo dinâmico vem de uma lista fixa de fontes. Não existe um campo do tipo “execute esta expressão”: isso entregaria execução de código a qualquer um que possa editar uma página.
- Os conjuntos globais de cor e tipografia não podem ser apagados, apenas esvaziados.
- Os cartões de produto são desenhados pelo WooCommerce, não por nós, então o seu tema e quaisquer hooks de terceiros continuam funcionando.
- A interface é distribuída em onze idiomas. Turco, inglês, espanhol, alemão, francês, português, italiano, neerlandês, japonês, russo e polonês, além de variantes de país como es_MX e pt_PT. Qualquer outro idioma recai no inglês.
- A janela dos Web Vitals reinicia a cada 28 dias; ela não desliza. Uma janela deslizante exigiria intervalos diários e vinte e oito vezes mais armazenamento. A tela mostra quando a janela atual começou.
- Desinstalar não remove a tabela de envios nem as configurações. O conteúdo dos seus blocos continua legível de qualquer forma — é marcação padrão em
post_content.
Nenhuma biblioteca de JavaScript ou CSS de terceiros é carregada, em lugar nenhum. Nem para o slider, nem para o acordeão, nem para o movimento, nem para o mapa. Cada uma delas teria custado entre quarenta e cem kilobytes em toda página que a usasse.