Benutzerdefinierter Beitragstyp - Liste der Beiträge - weißer Bildschirm des Todes

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 ...

Dies ist, um Ihre eigene Antwort zu erweitern:

Es scheint, dass sich jeder Beitrag wie eine Seite verhält, wenn "hierarchisch" auf "wahr" gesetzt ist. Ich zitiere hier, damit ich nicht wirklich verstehe, warum es wichtig ist, aber wenn ich diese Zeile ändere, wird das Problem behoben.

Folgendes sagt der Kodex über den hierarchicalParameter

hierarchisch

(boolean) (optional) Gibt an, ob der Beitragstyp hierarchisch ist (z. B. Seite). Ermöglicht die Angabe von Parent. Der Parameter 'unterstützt' sollte 'Seitenattribute' enthalten, um das übergeordnete Auswahlfeld auf der Editorseite anzuzeigen.

Standard: false

Hinweis:  Dieser Parameter wurde für Pages geplant. Seien Sie vorsichtig, wenn Sie es für Ihren benutzerdefinierten Beitragstyp auswählen. Wenn Sie viele Einträge planen (z. B. über 100), treten Speicherprobleme auf. Wenn dieser Parameter auf true gesetzt ist, ruft WordPress alle Einträge dieses bestimmten Beitragstyps zusammen mit allen Metadaten auf jeder Verwaltungsseite ab, die für Ihren Beitragstyp geladen wird.

Wenn 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 die PageSeite 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 posthaben 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 der PostSeite im Backend überprüfen

Wenn 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

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 die wp_dropdown_pages()Funktion. Kann verwendet werden, um bei Bedarf zusätzliches HTML anzuhängen oder wiederzugeben.
• get_pages- weil wp_dropdown_pages()ruft die get_pages()Funktion auf.
• page_attributes_dropdown_pages_args- Ein Filter für die Argumente wp_dropdown_pages()auf den post.php/post-new.phpBildschirmen für hierarchische Beitragstypen.
• quick_edit_dropdown_pages_args- Ein Filter für das Argument wp_dropdown_pages()auf den edit.phpBildschirmen für hierararchische Beitragstypen.

das könnte verwendet werden, um das Problem anzugehen.

Es ist möglich, die Ausgabe wp_dropdown_pages()auf dem post.phpBildschirm zu ändern mit:

add_filter( 'page_attributes_dropdown_pages_args', function( $dropdown_args, $post )
{
    if( 'page' === $post->post_type )
    {
        $dropdown_args['number']       = 10; // Limit the number of pages
        $dropdown_args['hierarchical'] = 0;  // Keep it non-hierarchical 
        $dropdown_args['offset']       = 1;  // Ideal for pagination
    }
    return $dropdown_args;
}, 10, 2 );

und ähnlich für den edit.phpBildschirm für Seiten :

add_filter( 'quick_edit_dropdown_pages_args', function( $dropdown_args )
{
    $screen = get_current_screen();
    if( 'edit-page' === $screen->id )
    {
        $dropdown_args['number']       = 10; // Limit the number of pages
        $dropdown_args['hierarchical'] = 0;  // Keep it non-hierarchical
        $dropdown_args['offset']        = 1;  // Suitable for pagination
    }
    return $dropdown_args;
} );

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:

add_action( 'init', function()
{
    remove_post_type_support( $post_type = 'page', 'page-attributes' );

} );

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.

Ok ... 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:

'hierarchical'          => true,

Alles was Sie tun müssen, ist es in false zu ändern!

'hierarchical'          => false,

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.

Hier ist ein vollständiges Beispiel aus dem WordPress-Codex

add_action( 'init', 'codex_book_init' );
function codex_book_init() {
$labels = array(
    'name'               => _x( 'Books', 'post type general name', 'your-plugin-textdomain' ),
    'singular_name'      => _x( 'Book', 'post type singular name', 'your-plugin-textdomain' ),
    'menu_name'          => _x( 'Books', 'admin menu', 'your-plugin-textdomain' ),
    'name_admin_bar'     => _x( 'Book', 'add new on admin bar', 'your-plugin-textdomain' ),
    'add_new'            => _x( 'Add New', 'book', 'your-plugin-textdomain' ),
    'add_new_item'       => __( 'Add New Book', 'your-plugin-textdomain' ),
    'new_item'           => __( 'New Book', 'your-plugin-textdomain' ),
    'edit_item'          => __( 'Edit Book', 'your-plugin-textdomain' ),
    'view_item'          => __( 'View Book', 'your-plugin-textdomain' ),
    'all_items'          => __( 'All Books', 'your-plugin-textdomain' ),
    'search_items'       => __( 'Search Books', 'your-plugin-textdomain' ),
    'parent_item_colon'  => __( 'Parent Books:', 'your-plugin-textdomain' ),
    'not_found'          => __( 'No books found.', 'your-plugin-textdomain' ),
    'not_found_in_trash' => __( 'No books found in Trash.', 'your-plugin-textdomain' )
);

$args = array(
    'labels'             => $labels,
    'public'             => true,
    'publicly_queryable' => true,
    'show_ui'            => true,
    'show_in_menu'       => true,
    'query_var'          => true,
    'rewrite'            => array( 'slug' => 'book' ),
    'capability_type'    => 'post',
    'has_archive'        => true,
    'hierarchical'       => false,
    'menu_position'      => null,
    'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
);

register_post_type( 'book', $args );
}