Benutzerdefinierte Taxonomie-Abfrage nach Upgrade auf 4.4 unterbrochen


9

Ich habe gerade ein Upgrade von 4.2 auf 4.4 durchgeführt und jetzt ist meine Taxonomie-Abfrage leer. Es hat vor dem Upgrade einwandfrei funktioniert.

Ich habe eine benutzerdefinierte Taxonomie mit dem Namen registriert 'title', die von meinem benutzerdefinierten Beitragstyp verwendet wird 'sg-publications'. In Anlehnung an die WP-Vorlagenhierarchie habe ich eine Vorlage mit dem Namen erstellt, taxonomy-title.phpdie die Standardabfrage-Argumente verwendet und bis jetzt jede Veröffentlichung anhand ihres Titels korrekt angezeigt hat.

Hier ist die Ausgabe von $ queried_object und $ wp_query-> request in dieser Vorlage:

[queried_object] => WP_Term Object
    (
        [term_id] => 1256
        [name] => Stroupe Scoop
        [slug] => stroupe-scoop
        [term_group] => 0
        [term_taxonomy_id] => 1374
        [taxonomy] => title
        [description] => 
        [parent] => 0
        [count] => 30
        [filter] => raw
    )

[queried_object_id] => 1256

[request] => 
SELECT wp_posts.* 
FROM wp_posts 
INNER JOIN wp_term_relationships 
ON (wp_posts.ID = wp_term_relationships.object_id) 
WHERE 1=1 
AND wp_posts.post_title = 'stroupe-scoop' 
AND ( 
    wp_term_relationships.term_taxonomy_id 
    IN (1374)
    ) 
AND wp_posts.post_type = 'sg-publications' 
AND (wp_posts.post_status = 'publish' 
    OR wp_posts.post_status = 'private'
    ) 
GROUP BY wp_posts.ID 
ORDER BY wp_posts.post_date 
DESC 

Das Problem, das ich in der obigen Abfrage sehe, ist direkt danach WHERE 1=1, aus irgendeinem Grund sucht es post_title = 'stroupe-scoop'. Dies ist nicht korrekt - das ist der Taxonomiebegriff slug, nicht der Titel des Beitrags. Wenn ich diese Zeile auskommentiere und sie für die Datenbank ausführe, erhalte ich die richtigen Rückgaben. Was veranlasst WP also, diese Bedingung hinzuzufügen, wenn (ich nehme an) es nicht hinzugefügt wurde, bevor ich auf 4.4 aktualisiert habe?

Hier ist taxonomy-title.php:

<?php
/**
 * @package WordPress
 * @subpackage Chocolate
 */
  global $wp_query;

  $quer_object = get_queried_object();
  $tax_desc    = $quer_object->description;
  $tax_name    = $quer_object->name;
  $tax_slug    = $quer_object->slug;

get_header();
get_sidebar();

$title = get_the_title( $ID );
$args  = array(
    'menu'            => 'new-publications',
    'container'       => 'div',
    'container_id'    => $tax_slug . '-menu',
    'menu_class'      => 'menu-top-style nav nav-tab',
    'menu_id'         => '',
    'echo'            => true,
    'fallback_cb'     => false,
    'before'          => '',
    'after'           => '',
    'link_before'     => '<i class="fa fa-chevron-circle-right fa-fw fa-2x"></i>',
    'link_after'      => '',
    'items_wrap'      => '<ul id="%1$s" class="%2$s">%3$s</ul>',
    'depth'           => 0,
    'walker'          => ''
);

?>

<div id="page-title">
  <h1><?php _e( 'Publications - ' . $tax_name, LANGUAGE_ZONE ); ?></h1>
  <p><?php _e( 'View our monthly newsletter and stay informed on the latest real estate news.', LANGUAGE_ZONE ); ?></p>

<?php wp_nav_menu($args); ?>

</div>

<div id="multicol">

<?php
if ( have_posts() ) : while ( have_posts() ) : the_post();

get_template_part( 'loop' , 'title' );

endwhile;
endif;
?>

</div><!-- end #multicol -->
<section class="page-text well"><?php _e( $tax_desc, LANGUAGE_ZONE ); ?></section>

<?php
get_footer();

Und in functions.php habe ich diesen Abfragefilter:

// use pre_get_posts to remove pagination from publications
function gd_publications_pagination( $query ) {
  if ( is_admin() || ! $query->is_main_query() )
    return;

  if ( is_tax('title') ) {
    // Display all posts for the taxonomy called 'title'
    $query->set( 'posts_per_page', -1 );
    return;
  }
}
add_action( 'pre_get_posts', 'gd_publications_pagination', 1 );

Wo ist der Abfragecode? Wenn es in Ihrer Vorlage enthalten ist, warum entfernen Sie dann nicht einfach das Teil, das es beschädigt? Wenn nicht - womit haben Sie die Abfrage generiert?
Montrealist

Es gibt keinen benutzerdefinierten Abfragecode. Ich verwende die WP-Standardschleife. Da ich der Vorlagenhierarchie folge, sollte (und muss) WP vor dem Upgrade die richtigen Abfrageparameter für meine Taxonomie generieren.
Gary D

2
Was ist der Inhalt von dir taxonomy-title.php? Haben Sie in den Themen functions.phpnachgesehen, ob die Hauptabfrage Filter enthält?
montrealistischer

Antworten:


5

Ich würde nicht empfehlen, einen Taxonomie-Slug zu verwenden, der mit den öffentlichen Abfragevariablen übereinstimmt, wie z title.

Die title Abfragevariable wurde in 4.4 eingeführt, daher denke ich, dass dies Ihre Probleme erklären könnte.

Schauen Sie sich diesen Teil der WP_QueryKlasse an:

    if ( '' !== $q['title'] ) {
        $where .= $wpdb->prepare( 
            " AND $wpdb->posts.post_title = %s", 
            stripslashes( $q['title'] ) 
        );
    }

Also, wenn wir zum Beispiel verwenden:

example.tld/?title=test

Was soll WordPress hier tun? Handelt es sich um eine Taxonomieabfrage oder eine Titelsuche?

Also ich würde empfehlen prefixing die benutzerdefinierte Taxonomie Slug, zB

gary_title

um mögliche Namenskollisionen zu vermeiden.

Aktualisieren:

Vielen Dank an @ ocean90 für den Hinweis, dass dies ein Fehler ist, der in 4.4.1 behoben wird


2
Vielen Dank für die Hinweise zur Änderung in 4.4 - ich hatte den Verdacht, dass es sich um einen Namenskonflikt handeln könnte. Ich werde folgen, sobald ich ein paar Tests durchgeführt habe.
Gary D

Bis vor einigen Versionen konnten Sie keinen Beitragstyp registrieren code, da das gesamte Admin-Backend dadurch monospaced wurde. Generische Namen sind immer Kollisionskandidaten. Auf der anderen Seite sollte WordPress seine eigenen Interna voranstellen.
Fuxia

Ja, das war es. Nachdem ich den Taxonomiebegriff und die zugehörigen Dateinamen in ein nicht widersprüchliches Schema geändert hatte, wurden alle wieder angezeigt. Nochmals vielen Dank, dass Sie mich auf den aktualisierten WP-Code hingewiesen haben.
Gary D

Ich
bin

cool, ich muss das testen, wenn ich eine alte Installation in die Hände bekomme ;-) Ich würde dieses Präfix-Ticket definitiv unterstützen, aber ich sehe das nicht in naher Zukunft, leider @toscho
birgire
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.