Estamos usando campos personalizados avançados em nossa empresa e às vezes precisamos usar shortcode em nossos campos personalizados. No código php, usamos o do_shortcode funções para esses campos. Não há razão para não usá-lo para a maioria dos campos, pois pode ser que queiramos adicionar códigos de acesso a um campo posteriormente.
Nós ” também está usando PHP CodeSniffer com a regra dos Padrões de Codificação do WordPress. Sempre que usamos echo do_shortcode, o aviso de escape desaparece. Portanto, é seguro apenas usar do_shortcode ou precisamos usar, por exemplo, wp_kses_post além disso?
Existe alguma prática recomendada para isso?
Obrigado por qualquer conselho
Comentários
- do_shortcode não é para escape.
- Hm, tudo bem, mas por que codesniffer não mostra nenhum aviso?
- Talvez não mostram um aviso porque a função de renderização de shortcode deve ser responsável por higienizar sua saída. Mas qualquer string pode ser passada para a função e se não contiver shortcodes registrados, então eu ' tenho certeza de que a string não será modificada. Definitivamente, não é um método de saneamento genérico. O sniffer de código não pode fazer muito. Leia aqui como higienizar dados corretamente. Existem muitas funções, as que eu uso muito são esc_attr, sanitize_text_field, esc_url. codex.wordpress.org/…
Resposta
Os padrões de codificação do WordPress tratam do_shortcode() como uma “função de escape automático”. Isso parece ter sido discutido em 2015 nestes problemas do GitHub:
https://github.com/WordPress/WordPress-Coding-Standards/issues/167 https://github.com/WordPress/WordPress-Coding-Standards/issues/428
A explicação usada quando foi adicionado à lista foi:
Discuti isso com o suporte VIP (# 44195). David, após conferenciar com outro membro da equipe, disse que não é necessário, pois fazemos o escape de onde o HTML é emitido (no código do shortcode).
Mas não tenho certeza se concordo com o raciocínio. Se você o usou assim:
<?php echo do_shortcode( "[liveperson]" ); ?> Onde o shortcode está codificado, faz sentido, porque a única coisa a escapar é a saída do shortcode, que deve ser escapada pelo callback do shortcode.
No entanto, em sua situação, você está usando do_shortcode() para permitir a execução de códigos de acesso em um texto fornecido pelo usuário, a partir de um campo personalizado. Esse texto não precisa de escape, mas do_shortcode() não faz nenhum escape real.
Portanto, a maneira segura de lidar com campos como este seria colocar o texto por meio de wp_kses() ou wp_kses_post(), para remover tags não permitidas e então passar por do_shortcode() para que os códigos de acesso possam ser ex executado sem ser escapado novamente.
$text = get_field( "field_name" ); echo do_shortcode( wp_kses_post( $text ) ); Não fará nenhuma diferença para o que o codificador faz / não relata, mas pelo menos o texto fornecido pelo usuário é higienizado.
Uma limitação é que não funcionará se você usar esc_html(), porque isso interferirá nos atributos do shortcode. Essa limpeza também não impedirá que os usuários insiram tags desequilibradas que podem afetar o layout, o que normalmente ajuda a escapar. Para resolver esse problema, você pode adicionar force_balance_tags():
$text = get_field( "field_name" ); echo do_shortcode( force_balance_tags( wp_kses_post( $text ) ) );