(私はこれを通常のスタック交換に投稿しましたが、ここにも置くことをお勧めします。この場所が存在することを喜んで... :))
それで、私は私が持っている2、3のサイトで何が起こっているのかを解明しようとしている間、インターネットの至るところにいました、そして私はついにそれを追跡することができたと思います...
しかし
私はWordpressに行く前に私がすべてを正しくやっていることを最初に確かめて、そして私に、そしておそらく他のものの束にいろいろな種類の煩わしさを引き起こしている小さなバグがあることを示唆したい。
問題の核心は、私がカスタム投稿タイプ "products"を持つWordpress(WP 3.5.1)サイトを複数持っていることです。カスタム投稿タイプを次のように定義しました。
/* Create custom Products taxonomy */
function create_custom_products_taxonomies() {
register_post_type( 'products',
array(
'labels' => array(
'name' => __( 'Products' ),
'singular_name' => __( 'Product' ),
'add_new' => __( 'Add New' ),
'add_new_item' => __( 'Add New Product' ),
'edit' => __( 'Edit' ),
'edit_item' => __( 'Edit Product' ),
'new_item' => __( 'New Product' ),
'view' => __( 'View Product' ),
'view_item' => __( 'View Product' ),
'search_items' => __( 'Search Products' ),
'not_found' => __( 'No products found' ),
'not_found_in_trash' => __( 'No products found in Trash' ),
'parent' => __( 'Parent Product' )
),
'public' => true,
'hierarchical' => true,
'menu_position' => 20,
'publicly_queryable' => true,
'query_var' => true,
'rewrite' => array("slug" => "/products", "with_front" => false),
'supports' => array('title', 'author', 'thumbnail', 'editor', 'excerpt', 'comments', 'page-attributes', 'common', 'custom-fields', 'revisions'),
'register_meta_box_cb' => 'products_meta_box',
'taxonomies' => array('products')
)
);
register_taxonomy(
'products',
'products',
array(
'hierarchical' => true,
'label' => __(ucfirst('products')),
'show_in_nav_menus' => true,
'rewrite' => array('slug' => 'categories')
)
);
}
add_action('init', 'create_custom_products_taxonomies'); // Create the necessary custom taxonomies for products
問題は、そのカスタム投稿タイプのリスティングページにアクセスしようとしているところにあります。投稿の類似ページは、管理ページの左側の管理サイドバーにある「投稿」です。カスタム投稿タイプのリストに使用するページの名前は、「商品」です。そのページにアクセスするとき、それはロードするためにリテラルAGEを取ります。さて、それで、ロードからロードまでの間に8-12秒のようなもので、管理者側の他のページは1〜2秒でロードされます。また、ページが頻繁にタイムアウトし、「サービスが一時的に利用できない」という一般的なエラーをスローします。 (このエラーがどこから来たのかわからない。Apache、Wordpressなど)
この異常な動作により、私は自分のサイトの管理者側を試してデバッグすることになりました。私はプラグイン "Debug Bar"と "Debug Bar Extender"を見つけました。これらのプラグインを直列に使用して適切なページをロードした後、そのページのクエリを表示できますが、この場合はクエリ引数がより重要な比較になります。
- 投稿一覧ページ -
post_type = post&posts_per_page = 400
- 商品一覧ページへ -
order = asc&orderby = menu_order + title&post_type = products& posts_per_page = -1 &posts_per_archive_page = -1
この場合、「投稿」ページ(ページ上部の[画面オプション]タブで設定)に表示される投稿数は400に設定されています。
ただし、表示する商品の数(同じ方法で、[商品]ページに設定)は25に設定されています。この事実に関係なく、[商品]ページのposts_per_pageクエリ引数(上に表示)は-1に設定されています。これはWordpressが私のカスタム投稿タイプ "products"ですべての投稿を取得しているのに、必要な25だけが表示されることを意味します。これは私の商品リストに関連付けられた複数ページ(ページネーション)に対しても同じです。
これは私には偽物のようです。私の質問です:私は間違ってカスタム投稿タイプを設定(登録)しましたか?自分のサイトで他のすべてのプラグインを無効にしても同じ動作が見られます。このカスタム投稿タイプを設定するにはregister_post_type関数のみを使用します。ここで何か問題が発生している場合は(私にはそう思われるように)、それをWordpressに報告します。そうでない場合...私は不必要にそれらを "バグ"にしたくありませんでした。 :)
私はこの振る舞いを複数のサイトで見たことがありますが、このサイトでadminページの読み込み時間が長くなる理由は、このカスタム投稿タイプで3k以上の投稿があるためです。それらに〜300-400の製品しかありません。
手助けやコメントをしてくれる人に感謝します。
Vancoderの提案どおり、register_post_type
関数呼び出しからhierarchical
パラメーターを削除することでうまくいきました。バックエンドで、階層型オプションが何をするのか(新しい投稿タイプをpage
投稿タイプのように振る舞うように設定する)を見ると、おそらくそもそも設定されるべきではないことがわかります。