Ich erhalte einen seltsamen Fehler - weißer Bildschirm in der Liste der Beiträge
für einen bestimmten benutzerdefinierten Beitragstyp (nur für diesen)
- habe versucht, alle Plugins zu deaktivieren
- habe versucht, auf Fehler zu prüfen (Debugging = true)
Immer noch nichts,
die Seite gibt einfach nichts wieder ... (auch nichts in der Quelle)
Ich spreche über eine solche URL im Administrator:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt
Hier ist der Teil register_post_type, den ich verwende:
function register_submodelcpt() {
$labels = array(
'name' => __('Sub Models', THEME_NAME),
'singular_name' => __('Sub Models', THEME_NAME),
'add_new' => __('New Model', THEME_NAME),
'add_new_item' => __('Add new Model', THEME_NAME),
'edit_item' => __('Edit Model', THEME_NAME),
'new_item' => __('New Model', THEME_NAME),
'all_items' => __('All Sub Models', THEME_NAME),
'view_item' => __('Watch Model', THEME_NAME),
'search_items' => __('Search Models', THEME_NAME),
'not_found' => __('No Models found', THEME_NAME),
'not_found_in_trash' => __('No Models found in trash', THEME_NAME),
'parent_item_colon' => '',
'menu_name' => __('Sub Models', THEME_NAME),
);
$args = array(
'labels' => $labels,
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array('slug' => 'submodels'),
'capability_type' => 'post',
'has_archive' => true,
'hierarchical' => true,
'menu_position' => 5,
'menu_icon' => get_stylesheet_directory_uri().'/images/cpt/subcars.png',
'supports' => array('title', 'thumbnail', 'revisions', 'page-attributes')
);
register_post_type('submodelscpt',$args);
}
add_action('init', 'register_submodelcpt');
Ist jemand auf eine solche Angelegenheit gestoßen?
Können Sie sich einen Grund vorstellen, warum dies passieren könnte?
Eine andere seltsame Sache,
wenn ich dies ändere:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt
Dazu:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt&orderby=date&order=desc
Die Liste der Beiträge wird korrekt geladen ...
quelle
pre_get_posts
, dass Sie nichts haben, was Abfragen , Abfragefilter usw. stört .pre_get_posts
. Wenn Ihr Debug jedoch aktiv ist und Sie einen weißen Bildschirm ohne Fehler erhalten, denke ich, dass es einenexit
oder einen geben mussdie
, versuchen Sie, nach ihnen zu suchen.Antworten:
Dies ist, um Ihre eigene Antwort zu erweitern:
Folgendes sagt der Kodex über den
hierarchical
ParameterWenn ein benutzerdefinierter Beitragstyp als hierarchisch festgelegt ist, entspricht sein Verhalten dem des eingebauten Beitragstyps
page
. Wie Seiten versucht Wordpress, einen Baum zu erstellen, um den richtigen hierarchischen Baum mit Eltern-Kind-Beziehungen im Back-End anzuzeigen. Wie Sie vielleicht bemerkt haben, werden Seiten im Back-End nicht nach Datum sortiert, sondern nach dieser Eltern-Kind-Beziehung. Dieses Verhalten können Sie leicht erkennen, wenn Sie diePage
Seite im Backend besuchen .Dieser Vorgang ist sehr teuer, da Wordpress beim Laden jeder Seite jede Seite (oder jeden Beitrag aus einem hierarchischen Beitragstyp) abrufen und dann nach den übergeordneten und untergeordneten Seiten dieser bestimmten Seite / des jeweiligen Beitrags suchen muss, um den richtigen Baum für diese bestimmte Seite / diesen bestimmten Beitrag zu erstellen . Wenn Ihr hierarchischer benutzerdefinierter Beitragstyp eine große Anzahl von Seiten oder Posts enthält, wird die Abfrage einfach zu groß und überschreitet die Speichergrenzen oder das Zeitlimit, was zu einem schwerwiegenden Fehler führt, daher das WSOD.
Nicht hierarchische Beitragstypen wie der eingebaute Beitragstyp
post
haben keine solche Hierarchie, da nicht hierarchische Beitragstypen keine untergeordneten Beiträge haben können. Da es aus offensichtlichen Gründen nicht erforderlich ist, einen Eltern-Kind-Beziehungsbaum zu erstellen, fragt Wordpress im Back-End einfach 20 ( IIRC ) Posts pro Seite ab, die nach Datum sortiert sind, und zeigt sie im Gegensatz zu hierarchischen Posts vom Post-Typ an, bei denen Wordpress dies tun muss Fragen Sie alle Beiträge gleichzeitig ab, erstellen Sie einen Baum und zeigen Sie dann nur einen x-Betrag für Beiträge an, die nach ihrer Eltern-Kind-Beziehung gruppiert sind. Sie können dieses Verhalten auf derPost
Seite im Backend überprüfenWenn Sie also einen benutzerdefinierten Beitragstyp auf hierarchisch setzen, wird Wordpress angewiesen, eine Liste / einen Baum von Beiträgen zu erstellen, die nach ihrer Eltern-Kind-Beziehung gruppiert sind, und diese Beiträge in dieser Konfiguration zurückzugeben. Wenn Sie einen benutzerdefinierten Beitragstyp auf nicht hierarchisch setzen, weisen Sie Wordpress an, die gesamte Beziehungssache zu überspringen und nur eine x Anzahl von Beiträgen pro Seite zurückzugeben, die nach dem Veröffentlichungsdatum sortiert sind
Ich hoffe, dass dies für Sie etwas sinnvoller ist, warum Sie es vermeiden sollten, benutzerdefinierte Beitragstypen hierarchisch zu gestalten, und warum dies auch im Kodex angegeben ist
quelle
Ich möchte nur die Antworten von @SagiveSEO und @PieterGoosen ergänzen.
Es gibt auch einen potenziellen Leistungskiller in Bezug auf die hierarchischen Beitragstypen:
Nämlich das Dropdown- Feld der übergeordneten Seite , das verwendet wird
wp_dropdown_pages()
.Es ist derzeit sehr ineffizient, da (fast) alle Seiten in das Auswahl-Dropdown-Feld geladen werden.
Wenn wir also eine Website mit vielen Seiten haben, kann dies die Leistung beeinträchtigen.
Stellen Sie sich eine Seite mit 1 Million Seiten vor ;-)
Dies wurde vor 6 Jahren mit dem Ticket # 9864 gemeldet . Es ist noch offen, sodass Sie weiterhin zur vorgeschlagenen Lösung für die automatische Vervollständigung beitragen können.
Aktualisieren:
Ich wollte nur einige hilfreiche Filter erwähnen:
wp_dropdown_pages
- ein Ausgangsfilter für diewp_dropdown_pages()
Funktion. Kann verwendet werden, um bei Bedarf zusätzliches HTML anzuhängen oder wiederzugeben.get_pages
- weilwp_dropdown_pages()
ruft dieget_pages()
Funktion auf.page_attributes_dropdown_pages_args
- Ein Filter für die Argumentewp_dropdown_pages()
auf denpost.php/post-new.php
Bildschirmen für hierarchische Beitragstypen.quick_edit_dropdown_pages_args
- Ein Filter für das Argumentwp_dropdown_pages()
auf denedit.php
Bildschirmen für hierararchische Beitragstypen.das könnte verwendet werden, um das Problem anzugehen.
Es ist möglich, die Ausgabe
wp_dropdown_pages()
auf dempost.php
Bildschirm zu ändern mit:und ähnlich für den
edit.php
Bildschirm für Seiten :Beachten Sie, dass das zweite Eingabeargument (
$post
) für diesen Filterrückruf nicht verfügbar ist.Es ist natürlich möglich, einfach die Unterstützung für Seitenattribute zu entfernen:
aber dann könnten wir genauso gut stattdessen einen nicht hierarchischen Beitragstyp verwenden ;-)
Eltern mit Ajax-Paginierung auflisten?
Mit Hilfe der oben genannten Filter sollte es möglich sein, eine paginierte (nicht hierarchische) Liste von Eltern zu erstellen, die über Ajax aktualisiert wird. Möglicherweise könnten die Auswahlfeldoptionen aktualisiert werden, um das aktuelle Layout beizubehalten. Das würde wohl? ein anderer Ansatz als das vorgeschlagene übergeordnete Suchfeld (auf Core Trac) mit automatischer Vervollständigung sein.
quelle
edit.php
Bildschirm @PieterGoosenwp_dropdown_pages()
Problem besteht darin, ein Suchtextfeld mit einer automatischen Ajax-Vervollständigung anstelle des zu verwenden aktuelles Dropdown-Feld, wenn die Anzahl der Seiten "groß" ist. @PieterGoosenOk ... für jeden, der diesen Beitrag besucht - ich habe die Lösung gefunden ... ich bin
tatsächlich wieder auf dieses Problem gestoßen (wenn eine Site viele Seiten hat)
Das Problem ist diese Zeile bei der Registrierung eines benutzerdefinierten Beitragstyps:
Alles was Sie tun müssen, ist es in false zu ändern!
Erklärung:
Wenn "hierarchisch" auf "wahr" gesetzt ist, verhält sich jeder Beitrag wie eine Seite. Ich zitiere hier, damit ich nicht wirklich verstehe, warum es wichtig ist, aber wenn ich diese Zeile ändere, wird das Problem behoben.
quelle
Hier ist ein vollständiges Beispiel aus dem WordPress-Codex
quelle