web-dev-qa-db-ja.com

カスタム投稿タイプ - 投稿リスト - 死の白い画面

投稿の一覧に白い画面 - 私は奇妙なエラーを得ています
特定のカスタム投稿タイプの場合（その場合のみ）

  • すべてのプラグインを無効にしてみた
  • エラーチェックを試みた（debugging = true）

まだ何も
このページはエコーを何もしません...（ソースにも何もありません）

私は管理者でそのようなURLについて話しています：
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

これは私が使っているregister_post_typeの一部です：

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

誰かがそのような発行に遭遇しましたか？
あなたはこれが起こるかもしれない理由を考えることができますか？

もう一つの奇妙なこと
私がこれを変えると：
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt

これに：
http://www.example.co.il/wp-admin/edit.php?post_type=submodelscpt&orderby=date&order=desc

投稿リストは正しく読み込まれます...

custom-post-typeswhite-screen-of-death
8
Sagive SEO

わかりました...この記事を訪れた人は誰でも - 解決策を見つけました...
私は実際にこの問題に再び遭遇しました（サイトにたくさんのページがあるとき）

カスタム投稿タイプを登録するときの問題です。 

'hierarchical'          => true,

あなたがする必要があるのはそれをfalseに変更することだけです！ 

'hierarchical'          => false,

説明：
"hierarchy"がtrueに設定されているとき、各投稿はページのように振る舞うようです。ここで引用しているので、なぜそれが問題になるのか実際にはわかりませんが、この行を変更すると問題が解決します。

2
Sagive SEO

これはあなた自身の答えを拡張することです：

"hierarchy"がtrueに設定されていると、各投稿はページのように動作します。ここで引用しているので、なぜそれが問題になるのか実際にはわかりませんが、この行を変更すると問題が解決します。

これがhierarchicalパラメータについてコーデックスが言うことです

階層的

（ブール値）（オプション）投稿タイプが階層型かどうか（ページなど）。 Parentを指定できるようにします。 'supports'パラメータには、エディタページに親の選択ボックスを表示するための 'page-attributes'を含める必要があります。

デフォルト：false

注： このパラメータはPages用に計画されていました。あなたのカスタム投稿タイプのためにそれを選ぶとき、注意してください - あなたが多くのエントリを持つことを計画しているなら（例えば - 100以上）、あなたはメモリ問題にぶつかるでしょう。このパラメータをtrueに設定すると、WordPressはあなたの投稿タイプの各管理ページの読み込みで、その特定の投稿タイプのすべてのエントリをすべてのメタデータとともに取得します。

カスタム投稿タイプがhierarchyichalに設定されている場合、その振る舞いは投稿タイプpageでのビルドと同じになります。ページと同様に、Wordpressはバックエンドに親子関係を持つ正しい階層ツリーを表示するためのツリーを構築しようとします。お気付きかもしれませんが、ページはバックエンドの日付順ではなく、この親子関係によって並べ替えられています。この振る舞いは、バックエンドのPageページにアクセスすると簡単にわかります。

Wordpressは各ページ（または階層型投稿タイプからの投稿）を すべてのページを読み込む そしてその特定のページ/投稿の親ページと子ページを探して正しいツリーを構築する必要があるため、この操作は非常に高価です。特定のページ/投稿。階層型のカスタム投稿タイプに大量のページまたは投稿がある場合、クエリは単純に大きくなり、メモリ制限を超えたりタイムアウトしたりするため、致命的なエラー、つまりWSODが発生します。

非投稿タイプpostのビルドのような非階層投稿タイプは、非階層投稿タイプの投稿が子投稿を持つことができないような階層を持ちません。親子関係ツリーを構築する必要はないので（明らかな理由で）、Wordpressはページごとに20（ _ iirc _ ）件の投稿を日付順にバックエンドに照会して表示します。 Wordpressが all postsを一度に照会しなければならない階層型の投稿タイプの投稿では、ツリーを作成してから、親子関係に従ってグループ化された投稿にxの金額だけを表示します。この振る舞いはバックエンドのPostページで確認できます。

そのため、カスタムの投稿タイプを階層に設定すると、その親子関係でグループ化された投稿のリスト/ツリーを作成し、その設定でそれらの投稿を返すようにWordpressに指示します。カスタム投稿タイプを非階層に設定すると、関係全体をスキップし、1ページあたりx個の投稿を投稿日順に返すようにWordpressに指示します。

カスタム投稿タイプを階層的にするのを避けなければならない理由、そしてそれがコーデックスにも記載されているのはなぜだろう。

7
Pieter Goosen

@SagiveSEOと@PieterGoosenによる回答に追加したいだけです。

階層型投稿タイプに関しては、潜在的なパフォーマンスキラーもあります。

つまり、wp_dropdown_pages()を使う 親ページのドロップダウン ボックスです。

それは（ほとんど）すべてのページを選択ドロップダウンボックスにロードするので、現在のところ非常に意味がありません。

そのため、多数のページがあるサイトがあると、パフォーマンスが低下する可能性があります。

100万ページのサイトを想像してみてください;-)

これは6年前のチケット ＃9864 で報告されています。まだオープンなので、提案されているオートコンプリートソリューションに引き続き貢献できます。

更新：

私はちょうどいくつかの有用なフィルタに言及したいと思いました：

  • wp_dropdown_pages - wp_dropdown_pages()関数の出力フィルタ必要に応じて、追加のHTMLを追加またはエコーするために使用されることがあります。
  • get_pages - wp_dropdown_pages()はget_pages()関数を呼び出すからです。
  • page_attributes_dropdown_pages_args - 階層型投稿タイプ用のpost.php/post-new.phpスクリーン上のwp_dropdown_pages()への引数のためのフィルター。
  • quick_edit_dropdown_pages_args - 階層型投稿タイプ用のedit.php画面上のwp_dropdown_pages()への引数に対するフィルタ。

それは問題を解決するために使用することができます。

post.php画面上のwp_dropdown_pages()の出力を以下のように修正することが可能です。

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

pagesのedit.php画面も同様です。

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

2番目の入力引数（$post）はこのフィルターコールバックには使用できないことに注意してください。

もちろんページ属性のサポートを削除するだけでも可能です。

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

} );

しかし、その場合は、代わりに非階層型の投稿タイプを使用することもできます。

Ajaxによるページ区切りの親を一覧表示する

上記のフィルタの助けを借りて、親のページ付けされた（非階層的な）リストを作成することが可能であるはずです。現在のレイアウトを維持するために、選択ボックスのオプションを更新することもできます。これでしょうか。自動補完を使用して、推奨されている（コアTrac上の）親検索ボックスとは異なるアプローチをとる。

6
birgire