Widget Logic

Descrição

Este plugin dá para cada widget um campo de controle extra chamado “Lógica de exibição do widget” que permite que você controle as páginas onde o widget aparecerá. O campo de texto permite que você use as Tags condicionais do WP ou qualquer código PHP.

OBSERVAÇÃO: A lógica de exibição dos widgets que você introduz é diretamente passada para a função EVAL. Qualquer um que tenha acesso à edição de widgets terá permissão para adicionar qualquer código, incluindo funções maliciosas ou possivelmente destrutivas. Existe um filtro opcional ‘widget_logic_eval_override’ que você pode usar para ignorar o EVAL com um código próprio, se necessário. (Veja Outras notas).

Também existe uma opção para adicionar um filtro WordPress ‘widget_content’ — isso permite que você ajuste qualquer HTML dos widgets para adequação ao seu tema, sem edição de plugins ou códigos do núcleo.

Doações

Se você gosta e usa o Widget Logic considere fazer uma pequena doação para o Cancer Research UK. Eu tenho um link para doações no JustGiving.com. Até fevereiro de 2017 nós já levantamos 1.048,50 libras esterlinas.

Escrevendo código lógico

O texto no campo ‘Lógica de exibição do widget’ pode ser um código PHP completo e deve retornar ‘true’ quando você precisa que o widget seja exibido. Se não há ‘return’ no texto, um ‘return’ implícito é adicionado no início e um ‘;’ adicionado no fim. (Isto é apenas para tornar declarações únicas como is_home() mais convenientes.)

O básico

Faça bom uso das tags condicionais do próprio WP. Você pode variar e combinar o código usando:

  • ! (NOT) para reverter a lógica, ex.: !is_home() é VERDADEIRO quando esta NÃO é a página de posts.
  • || (OR) para combinar condições. X OR Y é VERDADEIRO tanto quando X é verdadeiro quanto quando Y é verdadeiro.
  • && (AND) para tornar condições mais específicas. X AND Y é VERDADEIRO quando ambos X e Y são verdadeiros.

Existem vários ótimos exemplos de código nos fóruns do WP e nos sites WP pela internet. Porém o Codex WP também está cheio de bons exemplos para adaptar, como em Teste se um post está em uma categoria filha.

Exemplos

  • is_home() — somente na página de posts
  • !is_page('about') — em todo lugar EXCETO nesta ‘página’ WP específica
  • !is_user_logged_in() — exibido quando o usuário não está conectado
  • is_category(array(5,9,10,11)) — página de uma categoria que tenha um dos IDs fornecidos
  • is_single() && in_category('baked-goods') — post que está na categoria que possui este slug
  • current_user_can('level_10') — widget somente para administradores
  • strpos($_SERVER['HTTP_REFERER'], "google.com")!=false — widget para exibir quando clicado através de uma busca do google
  • is_category() && in_array($cat, get_term_children( 5, 'category')) — página da categoria que é filha da categoria 5
  • global $post; return (in_array(77,get_post_ancestors($post))); — Página WP que é filha da página 77
  • global $post; return (is_page('home') || ($post->post_parent=="13")); — página home OU uma página filha da página 13

Note o ‘;’ extra no final, onde há um ‘return’ explícito.

The ‘widget_logic_eval_override’ filter

Antes que o código do Widget Logic seja avaliado por widget, o texto do código do Widget Logic é passado através deste filtro. Se o filtro retornar um resultado BOOLEANO, ele é usado para determinar se o widget é visível. Retorne TRUE para visível.

The ‘widget_content’ filter

Quando esta opção estiver ativa (marque esta opção no rodapé da página de administração de widgets) você pode modificar o texto exibido por QUALQUER widget a partir do arquivo functions.php do seu tema. Utilize o filtro com:

add_filter('widget_content', 'your_filter_function', [priority], 2);

onde [priority] é o parâmetro opcional para a função add_filter. A função do filtro pode receber um segundo parâmetro (se você fornecer aquele último parâmetro ‘2’) dessa forma:

function your_filter_function($content='', $widget_id='')

O segundo parâmetro ($widget_id) pode ser usado para especificar widgets caso necessário.

Uma função de filtro WordPress ‘recebe o dados sem modificação e retorna o dado modificado’ o que significa que os filtros widget_content recebem a saída HTML pura do widget e você então estará livre para retornar qualquer outra coisa:

Exemplos de filtros

add_filter('widget_content', 'basic_widget_content_filter');
function basic_widget_content_filter($content='')
{   return $content."<PRE>THIS APPEARS AFTER EVERY WIDGET</PRE>";
}

Fui motivado a fazer este filtro para exibir todos os títulos de widgets com o excelente plugin ttftitles dessa forma:

add_filter('widget_content', 'ttftext_widget_title');
function ttftext_widget_title($content='')
{   preg_match("/<h2[^>]*>([^<]+)/",$content, $matches);
    $heading=$matches[1];
    $insert_img=the_ttftext( $heading, false );
    $content=preg_replace("/(<h2[^>]*>)[^<]+/","$1$insert_img",$content,1);
    return $content;
}

As pessoas normalmente perguntam por um modo de aplicar estilos diferentes nos widgets. Este filtro insere widget_style_a/widget_style_b na class=”widget …” usualmente encontrado na definição principal de um widget:

add_filter('widget_content', 'make_alternating_widget_styles');
function make_alternating_widget_styles($content='')
{   global $wl_make_alt_ws;
    $wl_make_alt_ws=($wl_make_alt_ws=="style_a")?"style_b":"style_a";
    return preg_replace('/(class="widget )/', "$1 widget_${wl_make_alt_ws} ", $content);
}

Imagens de tela

  • O campo 'Lógica de exibição do Widget' em ação em widgets padrão.
  • As opções do plugin estão no rodapé da página de administração de widgets... filtro widget_content, opção wp_reset_query, 'ponto de lógica de carregamento' e 'avaliar mais de uma vez'. Você também pode exportar e importar as opções WL do seu site como um arquivo de texto para um rápido bakcup/restauração e ajudar com resolução de problemas.

Instalação

  1. Faça upload de widget-logic.php para o diretório /wp-content/plugins/
  2. Ative o plugin por meio do menu “Plugins” no WordPress
  3. É isso aí. A configuração e opções estão na interface de administração de widgets como de costume.

Configuração

À parte da lógica de exibição dos seus widgets, foram adicionadas três novas opções no rodapé da página de administração dos widgets (veja as imagens de tela).

  • Adicione o filtro ‘widget_content’ — Isso permite que você modifique a saída de texto de todos os widgets. Você precisa saber como escrever um filtro WP, apesar de alguns pontos básicos serem explicados em Outras notas.

  • Use a solução ‘wp_reset_query’ — Muitos recursos do WP, bem como os de muitos temas e plugins por aí, podem bagunçar as tags condicionais, como fazer is_home NÃO ser verdadeiro na página de posts. Isso pode frequentemente ser resolvido com uma declaração rápida da função wp_reset_query() logo antes dos widgets serem chamados e essa opção resolve tudo melhor do que ter que editar o código fazendo uma reordenação

  • Lógica de carregamento — Esta opção permite que você configure o ponto no carregamento da página onde a lógica de exibição dos widgets deve ser avaliada. Antes da versão .50 isso acontecia quando o gatilho ‘wp_head’ era acionado, isto é, durante a criação do HEAD do HTML. Muitos temas não chamavam a função wp_head, o que era um problema. A partir da versão .50 isso acontece, por padrão, tão cedo quanto possível, que é logo que o plugin é carregado. Você agora pode especificar estes pontos de ‘carregamento tardio’ (em ordem cronológica):

    • depois do carregamento do tema (gatilho after_setup_theme)
    • quando todo o PHP for carregado (gatilho do wp_loaded)
    • depois que as variáveis da query forem estabelecidas (parse_query) – este é o padrão
    • durante o cabeçalho da página (gatilho do wp_head)

    Você pode precisar atrasar o carregamento se a sua lógica depende da definição de outras funções, como por exemplo, no arquivo functions.php do tema. Inversamente você pode querer antecipar o carregamento para que a contagem de widgets seja calculada corretamente, por exemplo, para mostrar um layout ou conteúdo alternativo quando uma barra lateral não tem widgets.

  • Não faça cache dos resultados das lógicas de exibição dos widgets — A partir da versão .58 o código da lógica de exibição dos widgets só deveria ser executado uma vez, mas isso pode causar resultados inesperados em alguns temas, então esta opção está aqui para desabilitar esse comportamento. (O verdadeiro/falso do código será avaliado toda vez que o filtro sidebars_widgets for chamado.)

FAQ

Installation Instructions
  1. Faça upload de widget-logic.php para o diretório /wp-content/plugins/
  2. Ative o plugin por meio do menu “Plugins” no WordPress
  3. É isso aí. A configuração e opções estão na interface de administração de widgets como de costume.

Configuração

À parte da lógica de exibição dos seus widgets, foram adicionadas três novas opções no rodapé da página de administração dos widgets (veja as imagens de tela).

  • Adicione o filtro ‘widget_content’ — Isso permite que você modifique a saída de texto de todos os widgets. Você precisa saber como escrever um filtro WP, apesar de alguns pontos básicos serem explicados em Outras notas.

  • Use a solução ‘wp_reset_query’ — Muitos recursos do WP, bem como os de muitos temas e plugins por aí, podem bagunçar as tags condicionais, como fazer is_home NÃO ser verdadeiro na página de posts. Isso pode frequentemente ser resolvido com uma declaração rápida da função wp_reset_query() logo antes dos widgets serem chamados e essa opção resolve tudo melhor do que ter que editar o código fazendo uma reordenação

  • Lógica de carregamento — Esta opção permite que você configure o ponto no carregamento da página onde a lógica de exibição dos widgets deve ser avaliada. Antes da versão .50 isso acontecia quando o gatilho ‘wp_head’ era acionado, isto é, durante a criação do HEAD do HTML. Muitos temas não chamavam a função wp_head, o que era um problema. A partir da versão .50 isso acontece, por padrão, tão cedo quanto possível, que é logo que o plugin é carregado. Você agora pode especificar estes pontos de ‘carregamento tardio’ (em ordem cronológica):

    • depois do carregamento do tema (gatilho after_setup_theme)
    • quando todo o PHP for carregado (gatilho do wp_loaded)
    • depois que as variáveis da query forem estabelecidas (parse_query) – este é o padrão
    • durante o cabeçalho da página (gatilho do wp_head)

    Você pode precisar atrasar o carregamento se a sua lógica depende da definição de outras funções, como por exemplo, no arquivo functions.php do tema. Inversamente você pode querer antecipar o carregamento para que a contagem de widgets seja calculada corretamente, por exemplo, para mostrar um layout ou conteúdo alternativo quando uma barra lateral não tem widgets.

  • Não faça cache dos resultados das lógicas de exibição dos widgets — A partir da versão .58 o código da lógica de exibição dos widgets só deveria ser executado uma vez, mas isso pode causar resultados inesperados em alguns temas, então esta opção está aqui para desabilitar esse comportamento. (O verdadeiro/falso do código será avaliado toda vez que o filtro sidebars_widgets for chamado.)

Atualizei para a versão .58 e os widgets do meu site agora se comportam de maneira diferente

Houve uma mudança importante na forma como o código do Widget Logic é avaliado. Existe um novo padrão de ‘Lógica de carregamento’ que é ‘depois que as variáveis da query forem estabelecidas’. Para a maioria das pessoas ela deveria ser melhor, mas você pode tentar revertê-la para o antigo padrão ‘quando o plugin inicia’.

O que eu posso tentar se isso não está funcionando?
  • Troque para o tema padrão. Se o problema desaparecer, seu tema pode estar interferindo nas tags condicionais do WP ou na forma como os widgets funcionam
  • Tente a opção wp_reset_query. Se seu tema executa queries personalizadas antes de chamar a barra lateral isso deve ajudar.
  • Tente uma nova opção de ‘Lógica de carregamento’. A maioria das tags condicionais do WordPress só funcionam ‘depois que as variáveis da query forem estabelecidas’, mas alguns plugins podem exigir sua avaliação antes ou depois.
  • A opção ‘Avaliar a lógica de exibição do widget mais de uma vez’ pode ser necessária se você tem que usar um ponto de ‘Lógica de carregamento’ executado mais cedo.
Estou recebendo erros como “PHP Parse error… … eval()’d code on line 1”

Você tem um erro de sintaxe PHP em um dos campos de lógica de exibição dos seus widgets. Reveja-os procurando por erros. Você pode achar mais fácil de procurar usando ‘Opções de expotação’ e lendo o código lá. (Esteja ciente que aspas simples e duplas são escapadas com múltiplas barras invertidas.)

Se você está tendo problemas para encontrar o erro de sintaxe, um método simples de resolução é usar as ‘Opções de exportação’ para manter uma cópia e então deixar em branco cada campo de lógica de exibição do widget e ir acrescentando o código até que o problema apareça. Uma vez que você tenha identificado o código problemático, você pode restaurar o restante com ‘Opções de importação’.

Estou tendo problemas com WooCommerce / outro plugin popular

Isto é frequentemente, mas nem sempre, resolvido tentando a opção diferente em ‘Lógica de carregamento’. A opção ‘depois que as variáveis da query forem estabelecidas’ parece um padrão melhor, tente-a.

O que é isso na minha barra lateral quando não há widgets?

Desde a versão .50 o código lógico do widget é executado de forma que, quando dynamic_sidebar é chamada no código de um tema, ela retornará falso se nenhum widget estiver presente. Nestes casos muitos temas são feitos de modo a colocar algum texto padrão no lugar dos widgets, que é o que você está vendo.

Suas opções, se você quer que esse conteúdo padrão na barra lateral desapareça, são ou editar o tema ou, como forma alternativa, adicionar um widget de texto vazio (sem título nem conteúdo) no fim da lista de widgets da barra lateral.

Como eu faço para que o widget X só apareça na minha página ‘inicial’? (Ou em qualquer outra exceto essa.)

Existe certa confusão entre a página inicial e a página de posts. Se você quer um widget na sua ‘página inicial’ quer ela seja uma página estática ou uma lista de posts, use is_front_page(). Se é uma página, usar is_page(x) não funciona. Se a sua ‘página inicial’ é uma página e não uma lista de posts, você ainda pode usar is_home() para exibir widgets na página principal de posts (como definido no Painel > Configurações > Leitura).

Lógica usando is_page() não funciona

Acredito que isto foi ajustado na versão 0.58. Avise-me se não foi o caso.

Se o seu tema chama a barra lateral depois do loop você poderá verificar que a opção wp_reset_query conserta as coisas. Este problema é explicado na página da is_page no codex .

Como eu faço para que um widget apareça tanto em uma página de categoria quanto em posts daquela categoria?

Cuidado com suas tags condicionais. Existe tanto uma tag in_category quanto uma is_category. Uma é usada para dizer se o post ‘atual’ está em uma categoria N e o outro é usado para dizer se a página sendo exibida É de uma categoria (o mesmo para tags e etc.). O que você quer quando:

(this page IS category X) OR (this is a single post AND this post is IN category X)

que em PHP é:

is_category(X) || (is_single() && in_category(X))
Como eu faço para que um widget apareça quando X, Y e Z forem verdade?

Tente você mesmo primeiro. Verifique a seção ‘Escrevendo código lógico’ em Outras notas.

Por que o Widget Logic é tão pouco amigável, você precisa ser uma fera nos códigos para usá-lo?

Isso é meio de propósito. Eu originalmente escrevi isso para ser tão flexível quanto possível com o pensamento de escrever uma interface de arrastar em algum momento. Nunca cheguei a fazer isso porque (sou preguiçoso e) eu não pude fazê-lo com um visual legal e permitir uma solução reserva em ‘código puro’ (para as possibilidades mais difíceis de prever em uma UI).

O plugin Widget Context apresenta uma boa UI e possui uma função de ‘correspondência de URL’ bem legal também.

Widgets aparecem quando não deveriam

Pode ser que seu tema execute queries personalizadas antes de chamar a barra lateral. Tente a opção wp_reset_query.

Alternativamente você pode não ter refinado sua lógica o suficiente. Por exemplo, quando uma barra lateral está sendo processada, in_category(‘cheese’) será verdadeiro se o último post em uma página de arquivo for da categoria ‘cheese’.

Refine suas definições com o ‘E lógico’ do PHP &&,por exemplo:

is_single() && in_category('cheese')

Avaliações

Free Page Level Targeting without Bloat

What an amazing little plugin which saves me a fortune and tons of time. Now this is featherlight and if you only know a bit of PHP it can do magic. If you don’t know PHP you should anyway learn it after CSS and HTML and before JavaScript.

I tested it to use it for Page Level Targeting of Subscription Widgets and Email magnets and it works without adding tons of bloat to my site.

I love these open source developers who build small but useful plugins without bloat opposed to massive and expensive plugins where I won’t need most of the features and which try to hook me to annual plans.

out of my league for now but what I’ve been looking for

Just learning the ropes of WP and php for that matter. This is the first I’ve seen that helps but doesn’t just give. Makes you work a little which makes you learn. Just enough to show the way but not too much to where you’re not thinking. Code behind it is enough, saying that as a novice of course to the language, but the delivery is equally important.

Thanks!

Leia todas as 166 avaliações

Contribuidores e desenvolvedores

“Widget Logic” é um software com código aberto. As seguintes pessoas contribuíram para este plugin.

Contribuidores

“Widget Logic” foi traduzido para 9 localidades. Obrigado aos tradutores por suas contribuições.

Traduzir “Widget Logic” para o seu idioma.

Interessado no desenvolvimento?

Navegue pelo código, dê uma olhada no repositório SVN ou assine o registro de desenvolvimento via RSS.

Registro de alterações

5.9.0

wp_reset_query works better under certain conditions.

5.8.2

The code has been adapted to work on the servers with restricted <?=

Fixed support for the wp_register_sidebar_widget widgets.

Some content was prepared for translation.

5.8.1

Fixed the issue of displaying errors under certain conditions.

5.8.0

Added full support for WP customizer.

In case of a fatal error in logic, the widget will not be displayed.

5.7.4

Fixed the “Warning: Attempt to assign property of non-object” bug.
https://wordpress.org/support/topic/latest-update-seems-break-my-installation/

5.7.3

Fixed the issue when in some cases the plugin displayed user logic errors in the Widgets section and this didn’t allow to save the widgets.
https://wordpress.org/support/topic/an-error-has-occurred-please-reload-the-page-and-try-again-3/

Fixed ini_set() related warnings for some rare hosting configurations.
https://wordpress.org/support/topic/ini_set-diabled-warning/

5.7.2

Removed conflicts with outdated WP versions.

5.7.1

Fixed the settings form not being saved settings under some circumstances.

Added a setting to show logic code errors for admins (turned off by default).

Fixed the issue with quotes in error messages on some WP installations.

5.7.0

Fixed PHP 7 compatibility issue.

Fixed a conflict with the latest WPML plugin.

A new default load logic point attached to the action ‘parse_query’. By default the widget logic is only evaluated once.

Translation added: Ukrainian by Roman Sulym

0.57

Small fixes to satisfy some define(‘WP_DEBUG’, true) errors

0.56

Small fix to the original WP3.5 fix in 0.54 that had the side effect of failing to save logic text on newly added widgets.

0.55

Restored a striplashes that vanished in 0.54 causing much grief.

Translation: Spanish by Eduardo Larequi https://wordpress.org/support/profile/elarequi

0.54

Removed a WP 3.1+ function call, hopefully making it 2.8 compatible again.

A little ‘trim’ of WL code to stop “syntax error, unexpected ‘)'” errors, which could occur if your WL was just a single space. Thanks to https://twitter.com/chrisjean for pointing this out.

Translation support! Thanks to Foe Services Labs https://wordpress.org/support/profile/cfoellmann for the work on this and the German Social Translation

Added a ‘widget_logic_eval_override’ filter. This allows advanced users to bypass EVAL with a function of their own.

0.53

Accidentally released code with a terrible bug in it 🙁

0.52

Two new features: optional delayed loading of logic (see Configuration under Installation), and the ability to save out and reload all your site’s widget logic into a config file

0.51

One important bug fix (fairly major and fairly stupid of me too)

0.50

For the first time since this started on WP 2.3, I’ve rewritten how the core widget logic function works, so there may be ‘bumps ahead’.

It now uses the ‘sidebars_widgets’ filter (as it should have done when that was
introduced in WP2.8 by the look of it). The upshot is that is_active_sidebar should behave properly.

Widget callbacks only get intercepted if the ‘widget_content’ filter is activated, and much more briefly. (A widget’s ‘callback’ is rewired within the ‘dynamic_sidebar’ function just before the widget is called, by the ‘dynamic_sidebar_param’ filter, and is restored when the callback function is invoked.)

0.48

Kill some poor coding practices that throws debug notices – thanks to John James Jacoby.

0.47

FINALLY tracked down the elusive ‘wp_reset_query’ option resetting bug.

0.46

Fix to work with new WP2.8 admin ajax. With bonus fixes.

0.44

Officially works with 2.7 now. Documentation changes and minor bug fixes.

0.43

simple bug fix (form data was being lost when ‘Cancel’ing widgets)

0.42

WP 2.5+ only now. WP’s widget admin has changed so much and I was getting tied up in knots trying to make it work with them both.

0.4

Brings WP 2.5 compatibility. I am trying to make it back compatible. If you have trouble using WL with WP 2.1–2.3 let me know the issue. Thanks to Kjetil Flekkoy for reporting and helping to diagnose errors in this version

0.31

Last WP 2.3 only version