J'ai trouvé que wp_update_post()
échappe à toutes les esperluettes fournies dans le post_content
de l'article. J'essaie de mettre à jour un message sans convertir les esperluettes en &
. (Je dois ajouter des URL en texte clair ( et non des liens ) au champ post_content
des publications). Donc, j'essaie de trouver un moyen d'utiliser wp_update_post()
avec l'échappement désactivé, ou peut-être une autre fonction à sa place.
Une approche serait d’exercer $wpdb
directement, mais je préférerais ne pas le faire, car cela me semble être un dernier recours.
Une observation que j’ai faite est que si vous utilisez la vue "Texte" pour éditer une publication via l’interface administrateur, vous pouvez ajouter des esperluettes au contenu de post_content sans qu’elles soient converties en &
. Cependant, il me faut du temps pour parcourir le code et découvrir comment Wordpress accomplit cela. Est-ce que quelqu'un sait comment WP accomplit cela?
En fin de compte, ma question est la suivante: , quel est le meilleur moyen de mettre à jour un message avec l'esperluette échappée "désactivée"?
C’est correct, la mise à jour dans la section Admin ne change pas le &
en &
tandis que la fonction wp_update_post () (qui se trouve sous /wp-includes/post.php à la ligne 3772) ne le fait que si l'utilisateur n'a pas la capacité unfiltered_html , laissez-moi vous expliquer comment je l'ai découvert et ce que je recommande.
J'ai parcouru le problème et découvert que wp_update_post () appelle wp_insert_post () en interne, comme indiqué à la ligne 3820.
return wp_insert_post( $postarr, $wp_error );
wp_insert_post () appelle sanitize_post () à la ligne 3227
$postarr = sanitize_post( $postarr, 'db' );
Puis, à la ligne 2176, ce filtre modifie le &
en &
$value = apply_filters( "{$field_no_prefix}_save_pre", $value );
En particulier, il existe un filtre appelé content_save_pre
ou, dans mon cas, title_save_pre
, car je suis confronté au même problème avec le titre.
Maintenant, sur la page Admin qui utilise /wp-admin/post.php
Vous pouvez voir que la sauvegarde actuelle est à la ligne 205
$post_id = edit_post();
Et la fonction edit_post()
peut être trouvée sous /wp-admin/includes/post.php à la ligne 208
function edit_post( $post_data = null ) {
La mise à jour proprement dite est effectuée à la ligne 382
$success = wp_update_post( $post_data );
Ce qui montre que Wordpress utilise la même fonction wp_update_post () en interne.
Il s'avère qu'il existe un filtre nommé 'wp_filter_kses' qui n'est pas utilisé par Wordpress Admin et qui fait toute la différence. Bien que vous puissiez le supprimer en utilisant:
remove_filter('content_save_pre', 'wp_filter_kses');
ou dans mon cas
remove_filter('title_save_pre', 'wp_filter_kses');
Ou, comme @rinogo l'a mentionné, vous pouvez utiliser kses_remove_filters () pour supprimer tous les filtres kses.
Cependant, ces filtres sont définis par /wp-includes/kses.php à la ligne 1934 après vérification de la capacité de l'utilisateur à "unfiltered_html"
if ( ! current_user_can( 'unfiltered_html' ) ) {
kses_init_filters();
}
Si kses_init_filters()
est appelé, l’utilisateur qui tente de mettre à jour la publication n’est pas assez fiable et n’a pas les capacités adéquates.
Je recommanderais que l'authentification soit gérée correctement plutôt que de supprimer les filtres.
Je ne sais pas comment l'interface d'administration de WP gère cela (par exemple, le scénario que j'ai référencé dans la question), mais j'ai trouvé un moyen de le faire:
//Disable KSES
kses_remove_filters();
$update_rval = wp_update_post($updates);
//Reenable KSES
kses_init_filters();
Notez que les fonctions "kses" font partie de la défense de Wordpress contre le code malveillant. Alors, utilisez cette approche à vos risques et périls. KSES fait un lot plus que simplement échapper à des esperluettes. Si $updates
contient des données de confiance (comme dans mon cas), vous utilisez probablement cette approche en toute sécurité.