AutoCEP vs FlxWoo

Autocompletar CEP no checkout do WooCommerce e simular frete em tempo real — produto, carrinho e checkout — com múltiplas APIs, cache, fallback automático e compatibilidade com Melhor Envio, Frenet, Fluid Checkout e CartFlows. Descrição AutoCEP resolve dois problemas clássicos de qualquer loja WooCommerce: fazer o cliente preencher o endereço automaticamente ao digitar o CEP e mostrar o valor do frete antes de chegar ao checkout — na página do produto, no carrinho e no próprio checkout. Se você procurou por “autocompletar CEP no checkout WooCommerce”, “simular frete WooCommerce”, “calculadora de frete na página de produto” ou “preencher endereço automático WooCommerce”, é exatamente isso que o AutoCEP faz — e sem travar seu checkout, seja ele o padrão do WooCommerce, o Fluid Checkout, o CartFlows ou um checkout em etapas feito no Elementor Pro. O comportamento clássico do plugin (autocompletar endereço no checkout ao digitar o CEP) continua ativo por padrão assim que você instala — nenhuma configuração é necessária para isso. Todo o resto é opcional e fica no painel AutoCEP do WordPress. Por que instalar o AutoCEP Reduz abandono de carrinho: o cliente vê o valor do frete antes de chegar ao checkout, na própria página do produto ou no carrinho. Agiliza o preenchimento do endereço no checkout, reduzindo erros de digitação e abandono por formulário longo. Funciona com o método de frete que sua loja já usa — Frete Fixo, Frete Grátis, retirada local, Melhor Envio, Frenet ou qualquer outro registrado como Zona de Entrega do WooCommerce — sem precisar reconfigurar nada. Não depende de nenhuma API paga: usa ViaCEP, BrasilAPI e ApiCEP, com cache e fallback automático entre elas. Autocompletar de Endereço por CEP Preenche Rua, Bairro, Cidade e Estado automaticamente a partir do CEP, na Cobrança e/ou na Entrega — cada uma pode ser ligada/desligada separadamente. Consulta em cascata três APIs (ViaCEP, BrasilAPI e ApiCEP): se uma falhar ou não encontrar o CEP, a próxima é consultada automaticamente. Cache de CEPs já consultados, com duração configurável e botão de limpeza manual — menos requisições externas, resposta mais rápida para o cliente. Aviso automático quando o CEP é válido mas não tem rua específica cadastrada (comum em cidades pequenas), em vez de deixar o campo vazio sem explicação. Mensagem de erro visível para CEP inválido ou não encontrado. Sugestões automáticas do navegador (autocomplete) nos campos de endereço, opcional. Compatível com qualquer checkout construído sobre o formulário padrão do WooCommerce — incluindo Fluid Checkout, CartFlows e Elementor Pro — através de detecção automática de mudanças no formulário, sem depender de eventos específicos de cada plugin de checkout. Simulador de Frete: Produto, Carrinho e Checkout Três caixas de simulação de frete independentes, cada uma com posição e título configuráveis: Simular frete na página do produto, considerando (opcionalmente) a quantidade e a variação selecionadas. Simular frete no carrinho de compras, com os itens já adicionados. Simular frete no checkout, cálculo rápido só com o CEP. Todas consultam as Zonas de Entrega do WooCommerce em tempo real, reconhecendo automaticamente qualquer transportadora já configurada — incluindo Melhor Envio e Frenet — sem nenhuma integração adicional. Personalização Visual Cores do campo de CEP e do botão “Calcular” (fundo, borda, texto e hover) personalizáveis com o seletor de cores nativo do WordPress, para combinar com a identidade visual da loja. Diagnóstico e Logs Status em tempo real (online/offline) de cada API de CEP e log das últimas falhas — incluindo falhas de métodos de frete de terceiros, como Melhor Envio ou Frenet, quando não retornam nenhuma taxa. Instalação Faça o upload da pasta autocep para /wp-content/plugins/ (ou envie o .zip diretamente em Plugins > Adicionar Novo > Enviar Plugin). Ative o plugin no menu Plugins do WordPress. Acesse o menu AutoCEP no painel administrativo — o autocompletar de CEP no checkout já estará funcionando; as demais abas permitem ativar o que fizer sentido para a sua loja. Atualizando de uma versão anterior: basta substituir os arquivos do plugin pelos desta versão (ou desativar e reativar depois de sobrescrever). As configurações já salvas são preservadas. Como usar cada aba do painel Geral & Busca de CEP — liga/desliga o autocompletar de Cobrança e Entrega no checkout, escolhe quais APIs de CEP ficam ativas e em qual ordem de prioridade, mapeia o campo de bairro, ativa o foco automático, define a duração do cache e o autocomplete do navegador. Frete na Página de Produto — ativa a caixa de frete no produto, escolhe a posição na página (ou “Manual — via shortcode” para posicionar com [shipping_calculator_on_product_page] dentro da descrição do produto), se deve considerar a quantidade selecionada, e o título da caixa. Frete no Carrinho — mesma ideia, para a página do carrinho de compras. Frete no Checkout — mesma ideia, para o checkout. Mensagens & UX — edita todos os textos exibidos ao cliente e o comportamento do botão “Finalizar Compra”. Aparência — personaliza as cores das caixas de frete. Diagnóstico e Logs — verifica o status das APIs de CEP em tempo real e consulta o histórico de falhas. Como o simulador de frete se relaciona com o frete real do pedido Na página do produto: a caixa é informativa — mostra ao cliente, antecipadamente, quais métodos e valores estariam disponíveis para o CEP digitado. Como o item ainda nem está no carrinho, não há “seleção” possível ali; é só para ajudar na decisão de compra. No carrinho e no checkout: cada opção de frete simulada tem um botão “Selecionar” — clicar nele aplica de verdade aquele método ao pedido, usando o mesmo mecanismo de sessão que o WooCommerce usa nos próprios botões de rádio de frete. Ou seja, não é cosmético: a partir do clique, esse é o frete escolhido para o pedido, e a etapa “Método de Entrega” do checkout (ou os totais do carrinho) refletem essa escolha automaticamente. O CEP e o método enviados no clique de “Selecionar” são sempre revalidados no servidor no momento da seleção — o plugin nunca aplica cegamente o que o navegador envia. Segurança Pontos de segurança implementados no plugin, para quem for avaliar antes de instalar: Nonces em toda ação AJAX: cada requisição (busca de CEP, cálculo de frete, limpeza de cache, verificação de status, limpeza de logs) verifica uma nonce própria (check_ajax_referer) antes de processar qualquer coisa. Verificação de capacidade (current_user_can('manage_options')) em todas as ações administrativas. Sanitização e validação de entrada em todo dado recebido do cliente — CEPs são validados por formato antes de qualquer consulta ou cálculo. Consultas ao banco de dados preparadas ($wpdb->prepare) em toda operação com dados variáveis. Escape de saída (esc_html, esc_attr, esc_url etc.) em todo HTML gerado dinamicamente. Nenhuma execução de código dinâmico (sem eval, sem create_function, sem inclusão de arquivos por caminho vindo do cliente). Requisições externas restritas às APIs de CEP documentadas neste README e aos métodos de frete já configurados pela própria loja — o plugin não envia dados da loja ou dos clientes para nenhum outro destino. Tratamento de falhas de terceiros isolado: se um plugin de frete de terceiros (ex.: Melhor Envio, Frenet) lançar uma exceção ou ficar indisponível, isso é capturado e registrado no log, sem interromper o restante do checkout. Este plugin é desenvolvido e mantido pela equipe da TESW. Como em qualquer software, recomendamos testar em ambiente de homologação antes de colocar em produção, e manter WordPress, WooCommerce e PHP sempre atualizados. Compatibilidade WordPress até a versão 7.0.3 WooCommerce (checkout padrão) Fluid Checkout CartFlows Elementor Pro (checkout em etapas) Métodos de frete: Frete Fixo, Frete Grátis, retirada local, Melhor Envio, Frenet e qualquer outro método registrado como Zona de Entrega do WooCommerce Documentação de Terceiros Este plugin pode consultar as seguintes APIs de CEP, conforme configuração: * ViaCEP — https://viacep.com.br/ * BrasilAPI — https://brasilapi.com.br/ * ApiCEP — https://apicep.com/ O cálculo de frete usa exclusivamente as Zonas de Entrega já configuradas em WooCommerce > Configurações > Entrega — o AutoCEP não se conecta diretamente a nenhuma transportadora; ele lê os métodos que a própria loja já configurou (nativos do WooCommerce ou de plugins como Melhor Envio e Frenet). Perguntas Frequentes O autocompletar de CEP parou de funcionar depois que troquei de tema/checkout? O plugin observa automaticamente mudanças no formulário de checkout, então continua funcionando na maioria dos casos sem configuração extra, inclusive em checkouts de terceiros como Fluid Checkout e CartFlows. Se mesmo assim não funcionar, confira em Diagnóstico e Logs se alguma API está offline, e limpe o cache de CEPs. Por que aparecem duas caixas de frete na página de produto? Provavelmente outro plugin (ex.: Melhor Envio) também insere sua própria caixa automática. O AutoCEP desliga a do Melhor Envio automaticamente quando detecta o plugin instalado; para outras integrações, desative a exibição automática delas nas configurações do próprio plugin, ou desligue o simulador de produto do AutoCEP em vez disso. O simulador de frete não encontra nenhuma opção para um CEP que deveria funcionar Confirme que existe uma Zona de Entrega em WooCommerce > Configurações > Entrega que cubra o estado/CEP testado, com pelo menos um método habilitado. Consulte também a aba Diagnóstico e Logs — falhas de métodos de terceiros ficam registradas ali com a mensagem de erro específica. Apenas algumas transportadoras aparecem, mesmo com várias habilitadas na zona (ex.: Melhor Envio, Frenet) Isso normalmente não é um bug — é a própria transportadora rejeitando a cotação silenciosamente (sem erro, só sem preço) para aquele produto ou destino. A causa mais comum é o produto estar sem peso cadastrado: transportadoras via API (Melhor Envio, Frenet) costumam exigir peso mínimo para calcular a caixa/embalagem; Correios costuma ser mais tolerante e retornar preço mesmo sem peso definido, enquanto transportadoras privadas (Jadlog, Azul Ecommerce etc.) geralmente não. Como resolver: Vá em Produtos, abra o produto testado e confira a aba Entrega — preencha peso e, se possível, dimensões (comprimento, largura, altura). Repita a simulação de frete. Se ainda faltar alguma transportadora, veja a aba AutoCEP > Diagnóstico e Logs — a partir da versão 2.3.0, o plugin registra ali exatamente quais transportadoras habilitadas na zona não retornaram taxa, e aponta produtos sem peso cadastrado como possível causa. Aparece “CEP não encontrado” mesmo digitando um CEP que parece válido Confira se o CEP foi digitado corretamente (é comum trocar um dígito, ex. 58264-000 por 58265-000). Se o CEP realmente não existir na base dos Correios, nenhuma das três APIs consultadas (ViaCEP, BrasilAPI, ApiCEP) vai encontrá-lo — isso é esperado, não é uma falha do plugin. A aba Diagnóstico e Logs mostra uma linha “CEP não encontrado nesta API” para cada uma das três quando isso acontece, confirmando que o problema é o CEP em si. Clicar em uma opção de frete simulada aplica esse frete ao pedido? No carrinho e no checkout, sim — clicar em “Selecionar” aplica de verdade aquele método ao pedido. Na página do produto, a simulação é apenas informativa, já que o item ainda não está no carrinho. Veja a seção “Como o simulador de frete se relaciona com o frete real do pedido” acima. Ajuda e Suporte Em caso de dúvidas ou problemas: * Verifique se o CEP é válido. * Confirme se o plugin e as APIs desejadas estão ativos em AutoCEP > Geral & Busca de CEP. * Consulte a aba “Diagnóstico e Logs” para verificar falhas recentes. * Teste possíveis conflitos com outros plugins. Créditos Versão 2.0: criada pela equipe TESW, com desenvolvimento principal de Wanderson Cesar. Contribuição pontual na versão 1.5: Samuel Canale. Licença GPLv2 ou posterior. Desenvolvedor Empresa: TESW Site: https://tesw.com.br/plugins/

FlxWoo is a WooCommerce infrastructure plugin. It adds a REST API layer, server-side checkout rendering, and Stripe Checkout integration on top of standard WooCommerce — without replacing WooCommerce’s core order, payment, or inventory systems. It is designed for agencies and developers who need full control over checkout presentation while continuing to rely on WooCommerce for order management, tax calculation, coupon handling, and payment record-keeping. What FlxWoo Is A REST API layer for WooCommerce checkout state (namespace: flxwoo/v1) A server-side rendering layer for checkout and product page templates A Stripe Checkout integration with server-side session management and webhook handling A fallback-safe product page rendering layer: falls back to native WordPress/WooCommerce templates when the Render service is unavailable or the product type is not supported An admin dashboard for operational monitoring: Overview, Settings, and System Status pages An infrastructure layer that extends WooCommerce without replacing it What FlxWoo Is Not Not a WooCommerce fork or replacement Not a page builder or visual checkout designer Not a payment processor — payment remains in WooCommerce and Stripe Not a headless CMS Not a replacement for WooCommerce’s admin, order management, or product system Who FlxWoo Is For Agencies building custom checkout experiences on WooCommerce Developers who need REST access to WooCommerce checkout state Projects requiring server-side rendered checkout templates Teams integrating Stripe Checkout while keeping WooCommerce as the order system Architecture FlxWoo registers a REST namespace (flxwoo/v1). Checkout state endpoints (cart, order, coupon, customer) return JSON. Render endpoints (/render/checkout, /render/thank-you) return server-side rendered HTML. Product pages are intercepted at the template layer and rendered through the external Render service, with automatic fallback to native WordPress/WooCommerce templates if the service is unavailable or the product type is not supported. WooCommerce remains authoritative for all order, cart, tax, and payment data. FlxWoo reads and writes through WooCommerce’s standard APIs without modifying its data structures or core behavior. Features REST API under the flxwoo/v1 namespace Cart and checkout state endpoints returning JSON Stripe Checkout integration — server-side session creation and webhook handling Duplicate order prevention at the checkout session level Concurrent submission guard Session-independent Stripe return flow (order identity carried via URL, not session state) Server-side HTML rendering for checkout and thank-you templates Product page rendering via external Render service, with automatic fallback to native WordPress/WooCommerce templates Product type gate: only simple products (including virtual) are routed to the Render service; variable, external, and unrecognized types use native templates Structured logging for checkout and payment events Operational event store tracking webhook failures, Stripe connectivity issues, and auth denials Health endpoint at GET /wp-json/flxwoo/v1/health for uptime monitoring Admin Overview page with operational health summary and last-payment/last-webhook signals System Status page with diagnostics across environment, Stripe, cache, webhooks, checkout failures, and database Automated data retention: scheduled cleanup for idempotency records, Stripe events, checkout sessions, and operational events with defined retention windows Preserve-by-default uninstall policy: data is retained unless explicitly opted out in Settings Cache and CDN Configuration FlxWoo endpoints are session-sensitive and stateful. They must not be served from a cache layer under any circumstances. Why This Matters FlxWoo checkout endpoints read and write live session, cart, and payment state on every request. If a caching layer returns a stale or shared response, the result is incorrect behavior — not a gracefully degraded experience. Common symptoms include stale cart totals, duplicate checkout attempts, broken Stripe sessions, and session data surfacing to the wrong customer. Any FlxWoo endpoint returning a cache HIT response header is a production defect. What Must Bypass Cache Three route groups must bypass cache at every layer — page cache, CDN, reverse proxy, and any optimization plugin that operates on HTTP responses: /wp-json/flxwoo/* — all FlxWoo REST API endpoints (cart, checkout, payment, webhook, health) /checkout* — the WordPress checkout page and all trailing-slash or query-string variants /thank-you* — the order confirmation page and all variants FlxWoo emits Cache-Control: no-store headers via PHP on both the REST API and the HTML pages. However, CDN-level rules such as Cloudflare’s “Cache Everything” can override PHP headers at the edge before they reach the browser. PHP-level headers alone are not sufficient — explicit CDN bypass rules targeting these paths are required. Common Systems That Require Configuration WP Rocket — Add /wp-json/flxwoo/, /checkout, and /thank-you to “Never Cache URL(s)” in the Cache settings tab. WP Rocket uses substring prefix matching, so these entries cover /checkout* and /thank-you* including trailing-slash and query-string variants. LiteSpeed Cache — Add /wp-json/flxwoo/, /checkout, and /thank-you to the “Do Not Cache URIs” list under Cache > Excludes. LiteSpeed URI exclusions also use prefix matching, covering /checkout* and /thank-you*. Cloudflare — Use Cache Rules to bypass cache for paths matching /checkout*, /thank-you*, and /wp-json/flxwoo/*. If using Automatic Platform Optimization (APO), verify that checkout and thank-you URLs are in the APO exclusion list. Cloudflare’s “Cache Everything” page rule must not apply to these paths. Nginx / FastCGI — Add fastcgi_cache_bypass map entries for /wp-json/flxwoo/, /checkout*, and /thank-you* at the server or location block level. Varnish — Add pass conditions in vcl_recv for /wp-json/flxwoo/*, /checkout*, and /thank-you*. Aggressive optimization plugins — Verify that no plugin is buffering, combining, or caching REST API responses or HTML responses for FlxWoo routes or page wrappers. What Is Safe to Cache Static assets (CSS, JS, images), non-dynamic pages, and REST endpoints that explicitly return Cache-Control: public. FlxWoo’s own endpoints never set public cache headers. Full Configuration Reference Detailed per-system instructions, verification commands, and symptom diagnostics are in docs/cache-configuration.md. Requirements WordPress 6.0 or later PHP 8.0 or later WooCommerce (active; declared as a required plugin) Stripe account with Checkout enabled (for payment features) MySQL 5.7+ or MariaDB 10.3+ Operational Notes Health endpoint: GET /wp-json/flxwoo/v1/health always returns HTTP 200 when the plugin is active. Suitable for uptime monitoring and deployment verification. Logging: Structured logging for checkout and payment events. Useful for incident response and debugging in production environments. Database setup: Required tables are created automatically on activation. Schema migrations run silently on upgrade — no manual steps required. Data on uninstall: Data is preserved by default when the plugin is deleted. To remove all FlxWoo data, enable Delete all data on uninstall in FlxWoo Settings > Data before deleting the plugin. Idempotency: Checkout idempotency is database-backed, making the system safe for concurrent requests and browser retries. Stripe return flow: Order identity is carried via URL parameters after Stripe redirect, not session state. This makes the return path resilient to session loss between payment and confirmation. Security All REST endpoints enforce WordPress capability checks before processing requests. Input is validated and sanitized at the API boundary and within the service layer. All PHP files include an ABSPATH guard to prevent direct execution. Database queries use prepared statements throughout. PHP CodeSniffer with WordPress Coding Standards and security sniffs is enforced as a release gate. Limitations Requires WooCommerce to be active. FlxWoo will not initialize without it. Stripe integration requires an active Stripe account with Checkout enabled. Server-side rendering requires a live PHP execution environment. Fully static deployments are not supported. All FlxWoo REST endpoints must not be behind a full-page or CDN cache layer. Product page rendering via the Render service is currently limited to simple products (including virtual). Variable, external, and other product types fall back to native WordPress/WooCommerce templates.