Estamos usando campos personalizados avanzados en nuestra empresa y, a veces, necesitamos usar shortcode en nuestros campos personalizados. En el código php usamos el do_shortcode funciones para estos campos. No hay razón para no usarlo para la mayoría de los campos, ya que podría ser que queramos agregar códigos cortos a un campo más adelante.
Nosotros » También está utilizando PHP CodeSniffer con la regla de estándares de codificación de WordPress. Siempre que usamos echo do_shortcode, la advertencia de escape desaparece. Entonces, ¿es seguro usar do_shortcode o necesitamos usar, por ejemplo, wp_kses_post adicionalmente?
¿Existe alguna práctica recomendada al respecto?
Gracias por cualquier consejo
Comentarios
- do_shortcode no es para escapar.
- Mmmm bien, pero ¿por qué codesniffer no muestra ninguna advertencia?
- Quizás no muestra una advertencia porque la función de renderizado de shortcode debería ser responsable de desinfectar su salida. Pero cualquier cadena puede pasarse a la función y si no contiene códigos cortos registrados, entonces estoy ' bastante seguro de que la cadena no se modificará en absoluto. Definitivamente no es un método de saneamiento genérico. El sniffer de código solo puede hacer mucho. Lea aquí sobre cómo desinfectar los datos correctamente. Hay muchas funciones, las que uso mucho son esc_attr, sanitize_text_field, esc_url. codex.wordpress.org/…
Responder
Los sniffs de los estándares de codificación de WordPress tratan do_shortcode() como una «función de escape automático». Esto parece haber sido discutido en 2015 en estos problemas de GitHub:
https://github.com/WordPress/WordPress-Coding-Standards/issues/167 https://github.com/WordPress/WordPress-Coding-Standards/issues/428
La explicación utilizada cuando se agregó a la lista fue:
Discutí esto con el soporte VIP (# 44195). David, después de consultar con otro miembro del equipo, dijo que es innecesario, ya que hacemos el escape donde se emite el HTML (en el código corto).
Pero no estoy seguro de estar de acuerdo con el razonamiento. Si lo usó así:
<?php echo do_shortcode( "[liveperson]" ); ?> Donde el código abreviado está codificado, tiene sentido, porque lo único que se puede escapar es la salida del shortcode, que debería ser escapado por la devolución de llamada del shortcode.
Sin embargo, en su situación, está usando do_shortcode() para permitir la ejecución de códigos cortos dentro del texto proporcionado por el usuario, desde un campo personalizado. Ese texto sí debe ser escapado, pero do_shortcode() no hace ningún escape real.
Así que la forma segura de manejar campos como este sería pasar el texto a través de wp_kses() o wp_kses_post(), para eliminar las etiquetas no permitidas, y luego póngalo a través de do_shortcode() para que los códigos cortos puedan ser ex ecuadrado sin escapar de nuevo.
$text = get_field( "field_name" ); echo do_shortcode( wp_kses_post( $text ) ); No hará ninguna diferencia con lo que el sniffer de código hace / no informa, pero al menos el texto proporcionado por el usuario está desinfectado.
Una limitación es que no funcionará si usa esc_html(), porque eso interferirá con los atributos del shortcode. Esta desinfección tampoco evitará que los usuarios ingresen etiquetas desequilibradas que podrían afectar el diseño, que es algo con lo que el escape normalmente ayuda. Para solucionar ese problema, puede agregar force_balance_tags():
$text = get_field( "field_name" ); echo do_shortcode( force_balance_tags( wp_kses_post( $text ) ) );