apply_filters ('the_content', $ content) vs do_shortcode ($ content)


21

Disons que j'ai une option de thème ou une zone de texte postmeta personnalisée. Maintenant, je veux exécuter plusieurs shortcodes, textes généraux, images, etc.

Quelle sera la meilleure pratique et pourquoi?

Option 1:

$content = //my text area data;
echo apply_filters('the_content', $content);

Option 2:

$content = //my text area data;
echo do_shortcode($content);

Veuillez m'expliquer laquelle sera la meilleure pratique et pourquoi.

ÉDITER

Permettez-moi de décrire le scénario en détail. Je développe des thèmes pour les clients avec leurs exigences. Parfois, je dois ajouter des méta-messages sur les messages / pages / types de messages personnalisés, afin qu'ils puissent ajouter des codes courts (curseur, formulaire de contact, etc.) ou simplement un texte simple. C'est un texte déposé.

Pour que le shortcode fonctionne, j'utilise l' option 1 . Maintenant, j'ai entendu quelqu'un dire que c'était une mauvaise façon, et je devrais l'utiliser do_shortcode. Mais ils ne m'ont pas expliqué pourquoi c'était mal. C'est pourquoi je demande.

L'ensemble de ce processus peut être effectué dans l'éditeur de texte par défaut de wp. Mais je dois créer ces options pour une utilisation spécifique du modèle, c'est ce que veulent mes clients.

Réponses:


16

QUESTION ET RÉPONSE REVISITÉES

Il y a parfois ces questions qui vous harcèlent et vous traquent plus tard dans la vie, et c'est une de ces questions.

Cette question m'a fait réfléchir à une solution alternative au problème. Comme je l'ai déjà dit, les champs personnalisés et les métadonnées sont là pour stocker de petits morceaux de métadonnées, et non pour servir d'extension pour publier du contenu où vous pouvez exécuter des shortcodes et des fonctions. De plus, comme je l'ai déjà dit, votre méthode est incorrecte et ne doit pas être utilisée

Ce que j'ai trouvé intéressant dans votre message, c'est que vous avez utilisé des champs personnalisés et des métadonnées pour afficher par inadvertance du contenu personnalisé à partir de la saisie de l'utilisateur. Je me suis donc assis et j'ai réfléchi à un moyen possible de faire fonctionner cela et d'utiliser correctement les données de champ personnalisées et les données de la méta-boîte

Voici mon idée:

LE SCÉNARIO:

REMARQUE: cela peut être modifié pour répondre à tout besoin

Sur une seule publication, un utilisateur souhaite / doit afficher dynamiquement du contenu personnalisé après la publication pour répondre à ses besoins. Cela devrait être dynamique. Le contenu doit être une requête personnalisée, et l'utilisateur doit choisir ce qu'il veut montrer quand il veut et ce qu'il veut

LA SOLUTION POSSIBLE:

Les shortcodes ne fonctionneront pas ici, car les shortcodes ne peuvent pas être exécutés dans les champs personnalisés. Aucun ne do_shortcodefonctionnera, car il n'est pas dynamique et est codé en dur, ce que nous ne voulons pas. Comme dans votre question, nous allons utiliser des champs personnalisés. Encore une fois, je souligne, n'utilisez pas le champ personnalisé pour exécuter une requête personnalisée ou des shortcodes

LE PLAN:

Nous utiliserons le champ personnalisé pour enregistrer uniquement nos arguments de requête, c'est tout. Donc, ce que nous faisons, nous créons un champ personnalisé appelé custom_query_arguments. Dans l'écran de votre éditeur de messages, vous verrez maintenant votre champ personnalisé, prêt à l'emploi

La prochaine étape sera d'ajouter nos arguments de requête personnalisés à notre champ. Disons que nous devons afficher 3 messages de la catégorie 1 triés par titre. Donc, nos arguments de requête devraient ressembler à ceci: ( Au format chaîne )

'posts_per_page=3&cat=1&orderby=title'

C'est ce que vous devez maintenant saisir dans votre champ personnalisé. Une fois entré, enregistrez la valeur de votre champ personnalisé

La prochaine étape consistera à construire la requête personnalisée dans votre single.php. Ce qui est nécessaire ici, nous devons obtenir la valeur de notre champ personnalisé, qui est en fait nos arguments de requête, et le nourrir dans une nouvelle instance de WP_Querypour récupérer les publications. Nous devons également vérifier si nous avons réellement une valeur enregistrée dans ce champ personnalisé, si le champ personnalisé est vide, ne rien afficher

LE CODE:

Vous pouvez essayer quelque chose comme ça dans single.php juste après la publication unique.

$args = get_post_meta( get_queried_object_id(), 'custom_query_arguments', true );
// check if the custom field has a value
if( ! empty( $args ) ) {

    $q = new WP_Query( $args );

    if( $q->have_posts() ) {
        while( $q->have_posts() ) {
            $q->the_post();

            the_title();

        }
        wp_reset_postdata();
    }

} 

Si l'utilisateur souhaite supprimer la requête personnalisée, il peut simplement supprimer la valeur du champ personnalisé et laisser le champ personnalisé vide. S'il doit afficher la même requête mais de la catégorie 10 et un total de 5 messages, il peut simplement remplacer la valeur d'origine par ce qui suit

'posts_per_page=5&cat=10&orderby=title'

QUELQUES REMARQUES:

Il est important d'utiliser le bon synatx et le bon format lors de la saisie d'informations dans ces champs personnalisés et métadonnées. Des erreurs de syntaxe ou des informations incorrectes entraîneront une sortie indésirable ou même des erreurs fatales. Il est important de faire connaître ces informations à vos clients

RÉPONSE ORIGINALE

Je ne comprends pas ce que vous essayez d'accomplir, mais d'après ce que je peux vous dire, ce sont deux choses distinctes

OPTION 1

apply_filters('the_content', $content);est utilisé pour appliquer les filtres de contenu au contenu de publication brut non filtré, qui provient généralement de l'utilisation de $post->post_content. Ces filtres incluent le célèbre filtre wp_autopqui ajoute des balises p àthe_content()

apply_filters('the_content', $content); est généralement utilisé en conjonction avec get_postsoù l'on travaille directement avec les WP_Postobjets sans utiliser setup_postdata( $post )ce qui rend les balises de modèle comme the_content() disponibles pour utilisation

OPTION 2

do_shortcode est utilisé pour ajouter un shortcode n'importe où dans les fichiers de modèle en dehors de l'éditeur de texte dans l'arrière-plan de l'écran de l'éditeur de page, filtrant essentiellement les shortcodes à travers leurs crochets.

L'utilisation correcte est la suivante

Exemple: ajout du shortcode de la galerie dans un fichier modèle

echo do_shortcode( '[gallery]' )

EDIT 1

D'après vos commentaires, je n'utiliserais pas du tout de shortcode.

Si vous n'allez pas ajouter un shortcode via l'éditeur de texte et l'ajouter directement (hardcode) via do_shortcodedans un fichier de modèle, je préfère alors simplement ajouter la fonction au modèle

Exemple:

Si vous avez la fonction de shortcode suivante

function footag_func( $atts ) {
    return "foo = {$atts['foo']}";
}
add_shortcode( 'footag', 'footag_func' );

Vous pouvez simplement appeler la fonction directement dans un modèle comme

echo footag_func();

C'est beaucoup plus rapide de cette façon car le shortcode n'a pas besoin d'être analysé

EDIT 2

Pour être honnête ici, vous faites complètement cela à partir de votre modification. Voilà pourquoi je ne pouvais pas comprendre votre question initiale

Parfois, je dois ajouter des méta-messages sur les messages / pages / types de messages personnalisés, afin qu'ils puissent ajouter des codes courts (curseur, formulaire de contact, etc.) ou simplement un texte simple. C'est un texte déposé.

Pour que le shortcode fonctionne, j'utilise l'option 1 .....

Les champs personnalisés ne sont pas des champs de texte et ne sont certainement pas destinés à être utilisés pour exécuter des shortcodes et d'ailleurs des curseurs ou des formulaires de contact. Les champs personnalisés ne doivent jamais être utilisés pour remplacer l'éditeur de texte dans les articles et les pages.

Comme je l'ai dit précédemment, apply_filters('the_content', $content);est destiné à être utilisé pour appliquer une mise en forme au contenu de publication brut.

Vous avez deux choix ici

  • Utiliser do_shortcodedirectement dans les fichiers modèles, ce que je ne recommanderais pas car l'utilisation de la fonction est plus rapide car le shortcode n'a pas besoin d'être analysé

  • Utilisez le shortcode directement dans l'éditeur de texte pour la page / publication particulière

Je vous recommande sérieusement de jeter un nouveau regard sur vos structures et ce que vous souhaitez réaliser. Les champs personnalisés ne sont pas des éditeurs de texte et ne peuvent pas exécuter de shortcodes ou de curseurs.

Ma recommandation serait d'étudier peut-être des widgets personnalisés ou un système que vous pouvez utiliser avec des champs personnalisés


1
Pieter remercie pour l'explication. Je le sais déjà. Mais je demandais quelle option serait plus précise si la cible est uniquement de sortir des shortcodes à partir de la zone de texte des options post meta / theme. J'utilise l'option1 pour obtenir le contenu filtré, et c'est devenu une habitude pour moi. Et en utilisant l'option 1 même pour imprimer simplement un shortcode à partir d'un fichier texte. Alors, je demandais.
тнє Sufi

J'ai vu le montage. Je comprends ton point de vue. Mais mon scénario est différent. C'est comme, il y a un texte déposé / zone, et plusieurs shortcodes. L'utilisateur peut maintenant mettre n'importe quel / les shortcode dans cette zone. Je ne peux donc pas utiliser directement une fonction. Je dois garder cette partie dynamique.
тнє Sufi

Où est ce champ de texte, est-ce le même que dans l'écran de l'éditeur de page arrière
Pieter Goosen

Il peut s'agir d'une méta post. Ou cela peut être une option de thème. J'utilise le filtre the_content pour les deux.
тнє Sufi

Désolé, mais rien de tout cela n'a de sens. Pourquoi voudriez-vous utiliser des shortcodes dans des champs personnalisés? Pourquoi voudriez-vous même utiliser des shortcodes alors?
Pieter Goosen
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.