J'ai un type d'article personnalisé avec une taxonomie d'étiquettes standard ajoutée comme ceci: 'taxonomies' => array('post_tag')
. J'ai ajouté quelques balises à certains messages de ce CPT qui sont affichées sur le front-end avec la balise de modèle the_tags()
et les liens qu'il génère ont ce format http://local.mysite.dev/tag/tag1/
. Lorsque je clique sur un tel lien, une page sans publication est générée à l'aide du modèle tag.php
, mais si j'ajoute ?post_type=seron_mycpt
à la fin de l'URL, de la même manière que http://local.mysite.dev/tag/tag1/?post_type=seron_mycpt
, une page contenant les publications pertinentes est générée à l'aide du même modèle, mais cette fois, je reçois également. ces lignes ajoutées à debug.log
:
PHP Notice: Undefined property: stdClass::$labels in /...sitepath.../wp-includes/general-template.php on line 665
PHP Notice: Trying to get property of non-object in /...sitepath.../wp-includes/general-template.php on line 665
Ces notifications sont générées lorsque wp_title()
est appelé dans le modèle header.php
. Selon les règles de réécriture, la demande est transformée en requête tag=tag1&post_type=seron_mycpt
.
Pour le débogage, j'ai mis print_r(get_queried_object());
dans header.php
et j'ai obtenu ceci:
MYSITEstdClass Object
(
[term_id] => 27
[name] => tag1
[slug] => tag1
[term_group] => 0
[term_taxonomy_id] => 27
[taxonomy] => post_tag
[description] =>
[parent] => 0
[count] => 2
)
Je pense que WP attend un objet CPT avec une propriété labels
mais récupère à la place cet objet qui ne possède pas cette propriété.
Si j'étiquette une variable post
ordinaire avec la même balise, les mêmes modèles header.php
et tag.php
sont utilisés et cette publication est affichée lors de l'utilisation de l'URL http://local.mysite.dev/tag/tag1/
. Dans ce cas, aucun avis PHP n'est généré dans debug.log
, bien que print_r(get_queried_object())
montre un objet très similaire. Peut-être que WP n'atteint jamais la ligne de production d'avis dans general-template.php
.
Je ne comprends pas ce qu'est cet objet et pourquoi il est passé à la place d'un objet CPT. Quelqu'un pourrait-il expliquer?
C'est un bug (que j'ai déjà rencontré auparavant) et que je pourrais faire avec un ticket dans trac (puisque je n'ai jamais pris le temps de le soumettre!)
Le problème commence par les demandes qui définissent plusieurs indicateurs de requête is_*
sur true (en particulier des indicateurs représentant des objets, tels que des publications uniques, des pages et des archives de type et de terme de publication).
En effet, il ne peut y avoir qu’un seul "objet interrogé" (dans votre cas, c’est le terme).
Maintenant, la raison pour laquelle wp_title()
semble jeter un vacillement est attribuée à une autre fonction qu’elle appelle:
function post_type_archive_title( $prefix = '', $display = true ) {
if ( ! is_post_type_archive() )
return;
$post_type_obj = get_queried_object();
$title = apply_filters('post_type_archive_title', $post_type_obj->labels->name );
if ( $display )
echo $prefix . $title;
else
return $title;
}
Étant donné que l'indicateur is_post_type_archive
est true, il suppose que l'objet demandé est un type de publication et tente d'accéder à une propriété non définie de ce qui est en réalité un objet terme.
Que le correctif soit d'ouvrir la possibilité de plusieurs objets interrogés, ou de les mettre en œuvre plus rigoureusement, je ne suis pas sûr, mais je vais l'avoir sur trac et nous verrons ce qui suit.
Mise à jour: Pour supprimer l'erreur (et les autres éventuelles), "éteindre" l'un des drapeaux:
add_action( 'parse_query', 'wpse_71157_parse_query' );
function wpse_71157_parse_query( $wp_query )
{
if ( $wp_query->is_post_type_archive && $wp_query->is_tax )
$wp_query->is_post_type_archive = false;
}
Voici ce que j'ai fait. Dans mon modèle d'archive de taxonomie, je m'appuyais sur is_post_type_archive () pour générer des balises div supplémentaires.
add_action( 'parse_query', 'orb_parse_query' );
function orb_parse_query( $wp_query ) {
global $post_type_obj;
if ( $wp_query->is_post_type_archive && $wp_query->is_tax ) {
$post_type_obj = get_queried_object();
if (empty($post_type_obj->labels)) {
$post_type_obj->labels = new stdClass();
$post_type_obj->labels->name = 'dev/hack to fix WordPress Bug';
}
}
}
Merci à tous pour l'aide. J'ai utilisé la solution de lordspace et je l’ai peu modifié pour afficher le nom du type de message personnalisé actuel.
add_action( 'parse_query', 'orb_parse_query' );
function orb_parse_query( $wp_query ) {
global $post_type_obj;
if ( $wp_query->is_post_type_archive && $wp_query->is_tax ) {
$post_type_obj = get_queried_object();
if (empty($post_type_obj->labels)) {
$currentPostType = $wp_query->query['post_type'];
$currentPostTypeName = get_post_type_object($currentPostType)->labels->name;
$post_type_obj->labels = new stdClass();
$post_type_obj->labels->name = $currentPostTypeName;
}
}
}