web-dev-qa-db-ja.com

<！ - nextpage - >でコンテンツを追加すると4.4で破損する

更新2016-01-21

現在のテストはすべて、次の設定で4.4.1の新規インストールで行われています。Plain permalinksTwentysixteen ThemeNo 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;
}

現時点で私はこの機能性を元通りにする方法についての考えからあり、あらゆる援助は認められます。

postsnextpage
14
Milamber

アップデート21-01-2016 19:35 SA時間 - バグが見つかりました!!!!!ええ!!!!!!

私はついにバグを見つけました。前回の更新で述べたように、失敗は$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チケットを提出しました

この記事を書いている時点では、まだフィードバックはありませんでした。定期的にチケットの状況を確認してください。

現在のソリューション - A/W TRACチケットのフィードバック

今のところ、将来のリリースでフィードバックや修正が見込まれるまで、それ以上の通知があるまでWPクラスからそれらの行を削除します。

何時間IS IT ...... ITはデバッグ中です!!!!!

私はこれを完全にテストする時間がありました。私はあなたのコードを取り、それをテストしました：

  • 私の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を待つと、このバグが修正されます。

8
Pieter Goosen

これら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'));
4
birgire