WordPress : Content.php et content-single.php sont-ils identiques ?

Je comprends que lors de son utilisation get_template_part('content', get_post_format());, cela aidera à choisir une post formatpage spécifique en fonction du format de publication.

Et s’il n’y a pas de format de publication « c’est-à-dire que c’est standard », alors il reviendra àcontent.php

Mais que se passe-t-il si j’utilise content-single.phpune logique comme celle-ci :

if (get_post_format() == false) {
    get_template_part('content', 'single');
    } else {
        get_template_part('content', get_post_format());
}

Ai-je encore besoin d’ content.phpune page ? y a-t-il d’autres fonctionnalités que je ne connais pas ?

Solution n°1 trouvée

Vous pourriez vous débrouiller avec un seul modèle (content.php). C’est généralement loin d’être idéal.

Du blog de teamtreehouse devrait effacer votre question.

Pour moi, cette approche est une solution de repli.

Solution n°2 trouvée

Non, content.phpet content-single.phpce n’est pas la même chose.

Dans votre exemple CODE :

if (get_post_format() == false) {
    get_template_part('content', 'single');
} else {
    get_template_part('content', get_post_format());
}

WordPress se chargera content-single.phpquand get_post_format()est false. Cependant, get_template_part( $slug, $name )peut toujours essayer de charger content.phplorsque vous l’appelez avec get_template_part('content', get_post_format());dans l’exemple suivant :

1. get_post_format()renvoie (par exemple) video.

2. Mais vous n’avez pas de content-video.phpfichier de pièce de modèle.

Donc, fondamentalement, même lorsque get_post_format()n’est pas false, content.phpvous fournira toujours la partie de modèle par défaut si la partie de modèle liée au format de publication correspondante n’a pas été créée.

Conclusion : quel que soit le principal$slug, il est toujours judicieux de conserver le fichier de pièce de modèle par défaut comme pièce de modèle de secours finale (dans votre cas, ilcontent.phps’agit du fichier de pièce de modèle de secours par défaut). Alors OUI, vous en aurez peut-être encore besoin . Alors ne le supprimez pas, laissez-le tranquille.

Ce qui suit est la partie du CODE de la fonction principale get_template_part. Vous verrez que le noyau se charge toujours $templates[] = "{$slug}.php";en tant que fichier de modèle de secours final :

function get_template_part( $slug, $name = null ) {
    // ... more CODE from WP core
    $templates = array();
    $name = (string) $name;
    if ( '' !== $name )
        $templates[] = "{$slug}-{$name}.php";

    $templates[] = "{$slug}.php";
    locate_template($templates, true, false);
}

Ensuite, en locate_templatefonction, il parcourt le $templatestableau jusqu’à ce qu’il trouve le fichier correspondant, avec le CODE suivant :

function locate_template($template_names, $load = false, $require_once = true ) {
    $located = '';
    foreach ( (array) $template_names as $template_name ) {
        if ( !$template_name )
            continue;
        if ( file_exists(STYLESHEETPATH . '/' . $template_name)) {
            $located = STYLESHEETPATH . '/' . $template_name;
            break;
        } elseif ( file_exists(TEMPLATEPATH . '/' . $template_name) ) {
            $located = TEMPLATEPATH . '/' . $template_name;
            break;
        } elseif ( file_exists( ABSPATH . WPINC . '/theme-compat/' . $template_name ) ) {
            $located = ABSPATH . WPINC . '/theme-compat/' . $template_name;
            break;
        }
    }
    if ( $load && '' != $located )
        load_template( $located, $require_once );

    return $located;
}

Ainsi, comme vous pouvez le voir dans le CODE ci-dessus, si vous supprimez content.php, et si l’utilisateur du thème a un format de publication pour lequel vous n’avez pas de fichier de partie de modèle, WordPress ne trouvera pas de fichier de modèle vers lequel se rabattre, il chargera donc simplement rien dans ce cas. Dans une dernière tentative, WordPress essaie de charger un fichier de partie de modèle à partir wp-includes/theme-compat/du répertoire principal, mais il n’y a pas content.phpde fichier de partie de modèle dans le noyau WP.

Remarque : Cependant, si vous construisez un thème enfant et que le thème parent contient déjà lecontent.phpfichier, alors vous n’avez pas besoincontent.phpde fichier dans le thème enfant (si vous n’y faites aucune modification), car dans ce cas, WordPress utilisez le fichier du thème parentcontent.phpcomme fichier de pièce de modèle de secours.