Contém Menus De Acordo Com As Tarefas Relacionadas

Como configurar menus dinâmicos baseados em tarefas no WordPress

Quando você trabalha com sites que têm múltiplos perfis de usuário ou fluxos de trabalho divididos, chegar na hora de montar a navegação pode ser uma dor de cabeça. A solução mais comum é criar sistemas de menu que se adaptam automaticamente ao contexto da tarefa que o usuário está executando no momento. Isso é o que chamamos de menus condicionais por tarefa, e basicamente o sistema contém menus de acordo com as tarefas relacionadas ao perfil e à ação que está sendo realizada. Vou explicar como isso funciona na prática, porque a teoria publicada em forums técnicos raramente aborda os problemas reais que aparecem quando você coloca isso em produção.

Entendendo o funcionamento básico

O conceito é simples: em vez de um menu fixo para todos os visitantes, você define regras que mostram itens de navegação diferentes dependendo de variáveis como tipo de usuário, página atual, capability ou status de uma tarefa específica. No WordPress, isso pode ser feito de três formas principais: usando filtros nativos como wp_nav_menu_items, plugins como MB Views ou Advanced Custom Fields com Conditional Logic, ou código customizado no functions.php. A abordagem nativa com filtros é a mais limpa tecnicamente, mas também a mais trabalhosa. Você capta o menu via filtro, percorre os itens, e remove ou adiciona conforme suas condições. Funciona bem para cenários previsíveis. O problema é que cada condição nova exige uma linha extra de código, e o arquivo function cresce rápido. Já a abordagem com plugins de campos personalizados tende a ser mais rápida para prototipar. A maior parte dos desenvolvedores que vejo usar essa estratégia começa com o ACF porque tem uma interface visual para as regras condicionais. Mas há um detalhe importante: o ACF por si só não controla menus de navegação. Você precisa combinar com um plugin como o Custom Menu Plus ou escrever um pequeno filtro que leia os campos do ACF e aplique a lógica de exibição.

Método prático: filtro manual no functions.php

Se você quer controle total sem depender de plugins pesados, o caminho é usar o filtro wp_nav_menu_items. Aqui está um exemplo concreto de como eu configuro isso nos projetos: Você começa capturando o menu pelo seu location ou ID. Em seguida, verifica a condição desejada — por exemplo, se o usuário atual é editor, se está na tela de edição de postagem, ou se uma meta_field indica que uma tarefa foi concluída. Aí você itera sobre $items e faz um unset nos itens que não se aplicam. Um ponto que muita gente perde: o filtro wp_nav_menu_items roda para TODOS os menus na página. Se você não filtrar por $args->theme_location, vai acabar aplicando a lógica em menusLaterais e rodapés sem querer. Isso já causou um problema real pra mim num projeto de intranet corporativa. O menu principal estava escondendo itens corretamente, mas o menu do footer, que usava o mesmo loop de navegação, também passava pelo filtro e ficava vazio. O workaround foi adicionar uma verificação de local antes de qualquer lógica condicional.

Outro detalhe técnico importante é a prioridade do filtro. Por padrão, ele roda com prioridade 10. Se você tem múltiplas funções que modificam o mesmo menu, a ordem de execução importa. Sempre defina uma prioridade explícita e Documente ela. Sem isso, debugar menus que aparecem e desaparecem aleatoriamente vira um pesadelo.

contém menus de acordo com as tarefas relacionadas

Para um cenário real onde o menu deve exibir opções diferentes conforme a etapa de um workflow, a lógica geral funciona assim. Primeiro, você identifica qual tarefa o usuário está atualmente realizando. Isso pode vir de um post meta, de um user meta, ou de uma query string. Depois, você mapeia quais itens do menu correspondem àquela tarefa. Finalmente, você aplica o filtro removendo o que não se encaixa. Por exemplo, num sistema de gestão de pedidos, você teria etapas como "recebido", "em processamento", "enviado". Cada etapa mostra um subconjunto diferente de ações no menu. O item "Marcar como enviado" só aparece quando o pedido está na fase "em processamento". A estrutura de dados fica mais clara se você usar um array de mapeamento do que if/elseif encadeados.

Problemas comuns e armadilhas

A primeira armadilha é performance. Filtros de menu rodam a cada requisição. Se sua lógica de condicionais envolve queries personalizadas dentro do loop de itens, você vai multiplicar o número de queries proporcionalmente ao número de itens de menu e de menus na página. Num site com 8 itens de menu e 3 locations de menu, isso pode significar 24 queries extras por página. Sempre use transients ou cache de objeto para resultados que não mudam a cada request. A segunda armadilha é mais sutil e é onde a maioria dos desenvolvedores amadores erra: os menus são renderizados em cache. Se você usa qualquer plugin de cache de página — WP Rocket, W3 Total Cache, ou o cache nativo do servidor — o menu condicional vai servir a versão cacheada para todos os usuários, independente do perfil. A solução não é desativar o cache, mas sim implementar cache fragmentado ou exclua especificamente a região do menu do cache. No WP Rocket, isso se faz através da configuração de "Never Cache Pages" com exclusões de cookies ou via API de purga seletiva. A terceira armadilha envolve menus gerados dinamicamente por plugins de membership ou LMS. Plugins como MemberPress, LearnDash e BuddyBoss criam seus próprios itens de menu e muitas vezes não respeitam filtros padrão do WordPress. Eu perdi meio dia num projeto porque o menu condicional funcionava perfeitamente até ativar o LearnDash, que redefine completamente a estrutura de navegação após o filtro original já ter sido aplicado. A solução foi encontrar o hook específico do plugin e acoplar minha lógica lá.

Limitações que ninguém comenta

Menus condicionais por tarefa têm um limite prático claro: eles funcionam bem quando o número de perfis e tarefas é restrito. Se você tem mais de cinco perfis de usuário com conjuntos de menu completamente diferentes, a manutenibilidade do código cai drasticamente. Nesse cenário, vale a pena considerar uma abordagem alternativa baseada em menus separados por localização, onde cada perfil recebe uma localização de menu distinta via register_nav_menus e a seleção é feita no theme template, não via filtro. Outra limitação séria é acessibilidade. Menus que mudam dinamicamente sem feedback visual claro podem confundir usuários que dependem de leitores de tela. Se um item some porque a tarefa mudou, o leitor de tela pode não anunciar a alteração adequadamente. Sempre inclua aria-live regions ou notificações visuais quando o menu for modificado via JavaScript.

Alternativas quando o filtro manual não basta

Existem plugins que resolvem parte desse problema sem exigir código customizado. O Conditional Menu Items é um dos mais populares e permite definir regras visuais sem tocar no PHP. Ele suporta condições por usuário, página, data e custom fields. O problema é que ele usa sua própria engine de regras, que às vezes conflita com temas que também implementam lógica de menu. Para projetos mais complexos, eu recomendo considerar o MB Frontend Submission em conjunto com o Meta Box. Ambos são gratuitos e oferecem um sistema de condicionais muito mais robusto que o ACF padrão. A curva de aprendizado é maior, mas o resultado é mais previsível em produção. Se nenhuma dessas soluções se encaixa, o caminho mais seguro continua sendo o filtro nativo com cache adequado e testes em múltiplos perfis de usuário antes de ir para o ar. A regra número um: nunca confie que o menu vai se comportar igual no front-end e no back-end. Sempre teste em ambos os contextos com o mesmo perfil de acesso que o usuário final terá.