Jenis posting khusus - daftar posting - layar putih kematian

saya mendapatkan kesalahan aneh - layar putih dalam daftar posting
untuk jenis posting kustom tertentu (hanya untuk yang itu)

• mencoba menonaktifkan semua plugin
• mencoba memeriksa kesalahan (debugging = true)

Masih tidak ada
halaman yang tidak menggemakan apa pun ... (tidak ada sumber juga)

Saya berbicara tentang url di admin:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

Inilah bagian register_post_type yang saya gunakan:

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');

Apakah ada yang menemukan masalah seperti itu?
dapatkah Anda memikirkan alasan mengapa hal ini mungkin terjadi?

Hal aneh lain
ketika saya mengubah ini:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

Untuk ini:
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt&orderby=date&order=desc

Daftar posting dimuat dengan benar ...

Ini untuk memperluas jawaban Anda sendiri:

Tampaknya ketika "hierarkis" disetel ke true, setiap posting berperilaku seperti halaman. Saya mengutip di sini jadi saya tidak begitu mengerti mengapa itu penting tetapi mengubah baris ini menghilangkan masalah.

Berikut adalah apa kata codex tentang hierarchicalparameter

hierarkis

(boolean) (opsional) Apakah jenis posting hirarkis (misalnya halaman). Mengizinkan Orang Tua untuk ditentukan. Parameter 'pendukung' harus berisi 'atribut halaman' untuk memperlihatkan kotak pilih induk di halaman editor.

Default: false

Catatan:  parameter ini direncanakan untuk Halaman. Hati-hati, ketika memilihnya untuk jenis posting kustom Anda - jika Anda berencana memiliki banyak entri (katakanlah - lebih dari 100), Anda akan mengalami masalah memori. Dengan parameter ini disetel ke WordPress sejati akan mengambil semua entri dari jenis posting tertentu, bersama dengan semua data meta, pada setiap halaman administrasi memuat untuk jenis posting Anda.

Ketika jenis posting khusus ditetapkan sebagai hierarki, perilakunya akan sama dengan jenis posting dalam-bangunan page. Seperti halaman, Wordpress mencoba membangun pohon untuk menampilkan pohon hierarki yang benar dengan hubungan orangtua-anak di bagian belakang. Seperti yang mungkin Anda perhatikan, halaman tidak diurutkan berdasarkan tanggal di bagian belakang, tetapi oleh hubungan orangtua-anak ini. Perilaku ini dapat Anda lihat dengan mudah saat mengunjungi Pagehalaman di bagian belakang.

Operasi ini sangat mahal karena Wordpress perlu mendapatkan setiap halaman (atau posting dari jenis posting hirarkis) pada setiap halaman memuat dan kemudian mencari halaman induk / anak halaman / posting tertentu untuk membangun pohon yang benar untuk halaman / posting tertentu . Jika Anda memiliki sejumlah besar halaman atau posting dalam jenis posting kustom hierarkis Anda, kueri hanya menjadi besar dan melebihi batas memori atau waktu habis, yang mengarah ke kesalahan fatal, karenanya WSOD.

Jenis posting non-hierarkis seperti build dalam jenis posting posttidak memiliki hierarki seperti posting jenis posting non-hirarkis tidak dapat memiliki posting anak. Karena tidak perlu membangun pohon hubungan orangtua-anak (untuk alasan yang jelas), Wordpress hanya meminta 20 posting ( IIRC ) per halaman yang dipesan berdasarkan tanggal di bagian belakang dan menampilkannya berbeda dengan posting jenis posting hirarkis di mana Wordpress harus query semua posting sekaligus, buat pohon dan kemudian hanya tampilkan jumlah x pada posting yang dikelompokkan berdasarkan hubungan orangtua-anak mereka. Anda dapat memeriksa perilaku ini di Posthalaman di bagian belakang

Jadi pengaturan jenis posting khusus ke hierarki memberitahu Wordpress bahwa itu harus membangun daftar / pohon posting yang dikelompokkan berdasarkan hubungan orangtua-anak mereka dan mengembalikan posting tersebut dalam konfigurasi itu. Mengatur jenis posting khusus ke non-hierarkis, Anda mengatakan kepada Wordpress untuk melewati semua hubungan dan hanya mengembalikan jumlah x posting per halaman yang dipesan berdasarkan tanggal posting

Saya harap ini lebih masuk akal bagi Anda mengapa Anda harus menghindari membuat tipe posting khusus secara hierarkis, dan mengapa hal itu juga dinyatakan dalam kodeks

Saya hanya ingin menambahkan jawaban dengan @SagiveSEO dan @PieterGoosen.

Ada juga pembunuh kinerja potensial terkait jenis posting hierarki :

Yaitu kotak dropdown halaman induk yang digunakan wp_dropdown_pages().

Saat ini sangat tidak efisien karena memuat (hampir) semua halaman ke dalam kotak dropdown pilih.

Jadi jika kita memiliki situs dengan banyak halaman, maka ini dapat mengganggu kinerja.

Bayangkan saja sebuah situs dengan 1 juta halaman ;-)

Ini dilaporkan 6 tahun yang lalu dengan tiket # 9864 . Itu masih terbuka sehingga Anda masih dapat berkontribusi pada solusi pelengkapan otomatis yang diajukan.

Memperbarui:

Saya hanya ingin menyebutkan beberapa filter bermanfaat:

• wp_dropdown_pages- filter keluaran untuk wp_dropdown_pages()fungsi. Dapat digunakan untuk menambahkan atau menggemakan beberapa HTML tambahan jika diperlukan.
• get_pages- karena wp_dropdown_pages()memanggil get_pages()fungsi.
• page_attributes_dropdown_pages_args- filter untuk argumen wp_dropdown_pages()di post.php/post-new.phplayar untuk jenis posting hirarkis.
• quick_edit_dropdown_pages_args- filter untuk argumen wp_dropdown_pages()di edit.phplayar untuk jenis posting hirarkis.

yang dapat digunakan untuk mengatasi masalah tersebut.

Dimungkinkan untuk memodifikasi output wp_dropdown_pages()pada post.phplayar dengan:

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 );

dan juga untuk edit.phplayar untuk halaman :

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;
} );

Perhatikan bahwa argumen input kedua ( $post) tidak tersedia untuk panggilan balik filter ini.

Tentu saja mungkin untuk hanya menghapus dukungan atribut halaman:

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

} );

tapi kemudian kita mungkin hanya menggunakan tipe posting non-hierarkis sebagai gantinya ;-)

Daftar orang tua dengan pagination ajax?

Seharusnya dimungkinkan, dengan bantuan filter di atas, untuk membuat daftar orang tua yang diberi nomor (non-hierarki), yang akan diperbarui melalui ajax. Mungkin opsi kotak pilih bisa diperbarui, untuk menjaga tata letak saat ini. Ini mungkin? menjadi pendekatan yang berbeda dari kotak pencarian induk yang disarankan (pada core trac), dengan penyelesaian otomatis.

Oke ... bagi siapa pun yang mengunjungi pos ini - saya telah menemukan solusinya ...
saya benar-benar mengalami masalah ini lagi (ketika sebuah situs memiliki banyak halaman)

Masalahnya adalah baris ini saat mendaftarkan jenis posting khusus:

'hierarchical'          => true,

Yang perlu Anda lakukan adalah mengubahnya menjadi false!

'hierarchical'          => false,

Penjelasan:
Tampaknya ketika "hierarkis" disetel ke true, setiap posting berperilaku seperti halaman. Saya mengutip di sini jadi saya tidak begitu mengerti mengapa itu penting tetapi mengubah baris ini menghilangkan masalah.

Ini adalah contoh lengkap dari kodeks wordpress

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 );
}