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

9

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

Sagive SEO
quelle
1
Es gibt nichts in Ihrem enthaltenen Code, das dies verursachen würde. Stellen Sie sicher pre_get_posts, dass Sie nichts haben, was Abfragen , Abfragefilter usw. stört .
Milo
danke milo ... habe nach dateienübergreifenden pre_get_posts gesucht und konnte nichts finden - das ist komisch! ; <(danke für den Versuch zu helfen.
Sagive SEO
Stimmen Sie mit @Milo überein, muss etwas auf Abfrage wirken. Beachten Sie, dass es Tonnen von Filtern gibt, die nicht nur auf Abfragen wirken pre_get_posts. Wenn Ihr Debug jedoch aktiv ist und Sie einen weißen Bildschirm ohne Fehler erhalten, denke ich, dass es einen exitoder einen geben muss die, versuchen Sie, nach ihnen zu suchen.
gmazzap
das ist eine gr8 idee!
Ich
Irgendwelche Fortschritte in diesem Bereich? Das gleiche Problem haben.
Nic

Antworten:

8

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

Pieter Goosen
quelle
sehr cool @pietergoosen vielen Dank für das Teilen - ich hasse es, nur auf das Warum zu verzichten;)
Sagive SEO
Gern geschehen. Ejoy :-)
Pieter Goosen
6

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.

Birgire
quelle
Danke für diese Info. In naher Zukunft etwas zu
Pieter Goosen
Ich habe dies erst vor einigen Wochen entdeckt, als ich an einer Installation mit einigen tausend Seiten arbeiten musste. Ich war überrascht zu sehen, dass das Dropdown-Feld für die übergeordnete Seite Tausende von Optionen hatte ;-) Dies ist auch Teil der Schnellbearbeitung auf dem edit.phpBildschirm @PieterGoosen
birgire
1
ja und mit dem aktuellen Kernzustand würde ich nicht empfehlen, mehr als ~ 100 Seiten zu verwenden, es sei denn, Sie haben einen guten Server => wir müssen nur einen Weg finden, nicht hierarchische Beiträge anstelle von Seiten für eine große Anzahl von Elementen zu verwenden ;-)
Birgire
2
Vielleicht, wenn das Backend alle Objekte im Speicher behalten und nur über ein cleveres "Diff" mit der Datenbank synchronisieren würde ;-) Ich denke, eine vorgeschlagene Lösung für das wp_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. @PieterGoosen
Birgire
1
@ialocin alles informative wird geschätzt, auch philosophische Ansichten ;-)
Pieter Goosen
3

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.

Sagive SEO
quelle
-1

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 );
}
Emilushi
quelle
Was ist los mit dem Kopieren und Einfügen? Warum haben Sie diesen Code hier eingefügt?
Sagive SEO
Tut mir leid, ich sehe deinen Code nicht. Ich habe ihn in der Android App überprüft, aber ich weiß nicht, warum er den Inhalt irgendwann verbirgt und manchmal sehr anoing
Emilushi