現在のテストはすべて、次の設定で4.4.1の新規インストールで行われています。Plain permalinks
Twentysixteen Theme
No plugins activated
投稿に1ページしかない(つまり<!--nextpage-->
が投稿に表示されない)場合、extraページは正常に追加されます(複数の追加ページを追加した場合でも¹)。
Welcome to WordPress. This is your first post. Edit or delete it, then start writing!
投稿に2+ページがある場合、余分なページ404と標準的なが投稿の1ページ目にリダイレクトされます。
Welcome to WordPress. This is your first post. Edit or delete it, then start writing!
<!--nextpage-->
This is page 2
2番目のケースでは、余分なページにアクセスすると$wp_query->queried_object
は空になります。このremove_filter('template_redirect', 'redirect_canonical');
を見るには、正規リダイレクトを無効にする必要があります。
以下の両方のコアフィックスは、動作に変更を加えることなく、別々におよび一緒に試みられました: https://core.trac.wordpress.org/ticket/35344#comment:16
https://core.trac.wordpress.org/ticket/35344#comment:34
使いやすさのために、これは私が現在テストしているコードです:
add_action('template_redirect', 'custom_content_one');
function custom_content_one() {
global $post;
$content = "\n<!--nextpage-->\nThis is the extra page v1";
$post->post_content .= $content;
}
add_filter('content_pagination', 'custom_content_two', 10, 2);
function custom_content_two($pages, $post) {
if ( in_the_loop() && 'post' === $post->post_type ) {
$content = "This is the extra page v2";
$pages[] = $content;
}
return $pages;
}
add_action('the_post', 'custom_content_three');
function custom_content_three() {
global $multipage, $numpages, $pages;
$content = "This is the extra page v3";
$multipage = 1;
$numpages++;
$pages[] = $content;
}
¹これは、1ページの投稿に複数の余分なページをテストするために使用したコードです。
add_action('template_redirect', 'custom_content_one');
function custom_content_one() {
global $post;
$content = "\n<!--nextpage-->\nThis is the extra page v1-1\n<!--nextpage-->\nThis is the extra page v1-2\n<!--nextpage-->\nThis is the extra page v1-3";
$post->post_content .= $content;
}
4.4より前では、私は次のような追加のページをmutlipageの投稿に追加することができました。
add_action('template_redirect', 'custom_content');
function custom_content() {
global $post;
$content = html_entity_decode(stripslashes(get_option('custom_content')));
$post->post_content .= $content;
}
Get_option( 'custom_content')は次のようになります。
<!--nextpage-->
Hello World
4.4にアップグレードしてからコードは機能しませんでした。追加のページに移動すると404エラーが発生し、 redirect_canonical が投稿のパーマリンクに返送されます。 redirect_canonicalを無効にすると追加ページを見ることができ、追加コンテンツがそこにありますが、それでも404エラーを引き起こします。
私はいくつかの回避策を試みましたが、どれも404エラーを解決しませんでした。
add_action('the_post', 'custom_content');
function custom_content() {
global $multipage, $numpages, $pages;
$content = html_entity_decode(stripslashes(get_option('custom_content')));
$multipage = 1; // ensure post is considered multipage: needed for single page posts
$numpages++; // increment number of pages
$pages[] = $content;
}
4.4で追加された新しい content_pagination フィルタも利用してみました。
add_filter('content_pagination', 'custom_content', 10, 2);
function custom_content($pages, $post) {
$content = html_entity_decode(stripslashes(get_option('custom_content')));
$pages[] = $content;
return $pages;
}
現時点で私はこの機能性を元通りにする方法についての考えからあり、あらゆる援助は認められます。
私はついにバグを見つけました。前回の更新で述べたように、失敗は$post_content
がコンテンツに<!--nextpage-->
タグを持っているときにのみ起こります。私はそれをテストし、そして<!--nextpage-->
の後のページの後の他のページが404を返し、そしてそのページが最初のページにリダイレクトされることを確認しました。
これは、WordPress 4.4の WP
クラス に導入されたhandle_404()
メソッドの 以下のコード のためです。
// check for paged content that exceeds the max number of pages
$next = '<!--nextpage-->';
if ( $p && false !== strpos( $p->post_content, $next ) && ! empty( $this->query_vars['page'] ) ) {
$page = trim( $this->query_vars['page'], '/' );
$success = (int) $page <= ( substr_count( $p->post_content, $next ) + 1 );
}
このコードが行うことは、<!--nextpage-->
タグがpost_content
に設定されているときはいつでも、content_pagination
フィルタを介してコンテンツの後に追加されたページがアクセスされると404を返します。 404が設定されているため、redirect_canonical()
は追加されたページを最初のページにリダイレクトします。
私はあなたがここでチェックアウトすることができるこの問題についてのTracチケットを提出しました
この記事を書いている時点では、まだフィードバックはありませんでした。定期的にチケットの状況を確認してください。
今のところ、将来のリリースでフィードバックや修正が見込まれるまで、それ以上の通知があるまでWP
クラスからそれらの行を削除します。
私はこれを完全にテストする時間がありました。私はあなたのコードを取り、それをテストしました:
私のv4.3のローカルインストール
私のv4.4.0ローカルインストール
私のv4.4.1ローカルインストール
Hello World
投稿とSample Page
ページのみを使用して、新しいv4.4.1ローカルインストールを完了します。
私のパーマリンクを
default
と
Post Name
これが私のテスト記事の中に4ページを作成するための私のテストコードです。
add_filter('content_pagination', 'custom_content', 10, 2);
function custom_content($pages, $post) {
$pages_to_add = [
'Hello World Page 2',
'Hello World Page 3',
'Hello World Page 4',
];
foreach ( $pages_to_add as $page_to_add ){
$pages[] = html_entity_decode(
stripslashes(
$page_to_add
)
);
}
return $pages;
}
私もテストした
add_filter('content_pagination', 'custom_content', 10, 2);
function custom_content($pages, $post) {
$pages_to_add = [
'<!--nextpage--> Hello World Page 2',
'<!--nextpage--> Hello World Page 3',
'<!--nextpage--> Hello World Page 4',
];
foreach ( $pages_to_add as $page_to_add ){
$pages[] = html_entity_decode(
stripslashes(
$page_to_add
)
);
}
return $pages;
}
良い測定のために
すべてのインストールおよびパーマリンク構造で、すべてのコードが動作します(v4.3のcontent_pagination
は除く)。
私はSample Page
を静的フロントページとしても設定しましたが、私の ORIGINAL ANSWERと** EDIT で説明されているようにバグの確認として2ページ目で失敗しました。
だから結論はこれはコアのバグやコアの他のバグとは関係がないということです。コメントから、ページングされた投稿ページでクエリされたオブジェクトの設定が解除されているため、デバッグする必要があります。残念ながら、この問題は局所化されているので、正確な解決策を示すことはできません。
問題をデバッグするには、次のような作業フローを使用する必要があります。
たくさんの砂糖と一緒に大量の高カフェインコーヒーを飲みましょう
あなたのバックアップを取ってくださいdb
以下のプラグインをダウンロードしてインストールします(どのプラグインにも所属していません)
通常のデバッグ用の Debug Objects 。インストールとセットアップが完了したら、プラグインによって強調されている可能性がある明らかなバグをすべて修復します。明らかなバグがある場合は、次の主な箇条書きに進んではいけません。最初に修正してください
次の箇条書きに進む前に、DBの修復とクリーンアップに使用する DBマネージャ
すべてのキャッシュ、ブラウザ、プラグインをクリアする
すべてのプラグインを無効にして、すべてのキャッシュをもう一度クリアしてください。この問題はリダイレクトの問題のように見えるので、リダイレクトと関係がある可能性があるすべてのプラグインをまず無効にします。 1つのプラグインがまだv4.4と互換性がない可能性があります。問題が解決しないかどうかを確認し、解決しない場合は次の箇条書きに進みます。それ以外の場合は、これをより詳細に見てみましょう。
すべてのプラグインを無効にすることから始めます。問題の原因となっている可能性があるプラグインを無効にすることから始めることもできます。すべてのプラグインをアクティブにした後にインストールを正しくテストしてください。問題を引き起こした最初に起動されたプラグインが原因になります。その場合は、デバッグの詳細をプラグイン作成者に連絡してください。ちょうどよい対策のために、それぞれのプラグインをアクティブにした後は必ずキャッシュをクリアしてください。
あなたがこの点に達したならば、前の箇条書きの点はあなたの問題を解決しませんでした。次のステップは、問題としてあなたのテーマを排除するためにバンドルされたテーマに切り替えることです。もう一度、キャッシュをクリアしてください。
すべてが失敗した場合は、もう2つの選択肢があります。
.htaccess
を削除し、WordPressに新しいものを作成させる
WordPressを再インストールする
これで問題は解決するはずです。そうでない場合、あなたは問題を引き起こしているかもしれないWordPressコアのバグを考慮する必要があります。
これがバグの発見に役立つことを願っています
私は実際にもっと詳細にすべてを説明しているように思われている次のTracチケットにリンクしているべきです
上記のtracチケットからの興味深く、非常に関連性のあるパッチ
現時点では、そのようなものとして具体的にテストすることはできませんが、提案されたパッチを調べてテストする必要があります。私が拾うことができるのは、静的フロントページのページ割り付けを担当する redirect_canonical()
内の同じコードが単一ページのページ割り付けも担当するということです。
単一ページ(静的フロントページのように)は、ページ付けにget_query_var( 'page' )
を使います。 WordPress 4.4(およびv4.4.1)では、get_query_var( 'page' )
をページネーションに使用するとページネーションに問題が生じるバグがありました。
tracチケット#35365 のような現在のバグレポートは、ページ割り付けに問題がある静的フロントページのみに言及していますが、バグはget_query_var( 'page' )
に関連しているのでget_query_var( 'page' )
。
あなたはtracチケットに記述されているようにパッチを試すべきです。これでうまくいく場合は、パッチを適用してv4.4.2を待つと、このバグが修正されます。
これら3つの例すべてに構文エラーがあることに注意してください。
add_filter('content_pagination', 'custom_content'), 10, 2);
add_action('the_post', 'custom_content'));
add_action('template_redirect', 'custom_content'));
追加の)
が追加されている場所。
これらの行を次のように置き換えます。
add_filter( 'content_pagination', 'custom_content', 10, 2);
add_action( 'the_post', 'custom_content' );
add_action( 'template_redirect', 'custom_content' );
一般的にグローバルオブジェクトをいじるのはお勧めしません。そのため、content_pagination
フィルタを使用した最後の例がここに行く方法だと思います。
空のページを次のように追加しないようにすることもできます。
if( ! empty( $content ) )
$pages[] = $content;
ここに)
がありません。
$content = html_entity_decode(stripslashes(get_option('custom_content'));