正規URLシステム全体ではなく、URL自動補完のみを無効にする


8

私は、次のように構造化/名前が付けられた「プロジェクト」のカテゴリにいくつかのページがあるブログを持っています。

  • / projects / project-2012
  • / projects / project-2013
  • / projects / project-2014
  • / projects / project-2015

ユーザーがhttp://myblog.com/projectまたはhttp://myblog.com/projeのようなURLを入力すると、ページ/ projects / project-2012にリダイレクトされます。(301が永久に移動しました!)

ワードプレスでURLを明確に定義された1つのページ(例:http://myblog.com/?p=123)に変換して正規形式にしたいのですが、「不明な」URLのURL自動補完のみを無効にしたい複数のページを指す場合があります。

私の質問は、次のとおりです。どうすればこれを達成できますか?


私もいくつかの研究をしました...

  • Wordpress URLの自動補完を無効にする」という質問に対する承認された回答 は、正規URLシステム全体を無効にします。これは私には受け入れられません。

  • 約4年Wordpressのバグトラッカーにポップアップこのような何か前:https://core.trac.wordpress.org/ticket/8948。ページを提供するようないくつかの良いソリューションは(「私たちはあなたのURLが見つかりませんでしたがしかし、あなたでしたおそらく次のページの1つを探していますか?」)そこで議論され、チケットは最後に閉じられました。

  • 編集:実際にはhttps://core.trac.wordpress.org/ticket/16557に新しいチケットがあり、私が必要とするものを正確にカバーしています。4.0リリースを対象にしているようです。チケットのコメントにも解決策が含まれています(以下を参照)。


このコアURL推測機能は、SEOおよびSEOツールにも影響します。
マウ

回答:


11

さて、もう少し検索した後、私はこの機能要求チケットのコメントに隠された自分の質問への回答をようやく見つけました:https : //core.trac.wordpress.org/ticket/16557ユーザーnacinはこのコードの使用を提案しました:

function remove_redirect_guess_404_permalink( $redirect_url ) {
    if ( is_404() )
        return false;
    return $redirect_url;
}

add_filter( 'redirect_canonical', 'remove_redirect_guess_404_permalink' );

これを新しいプラグインphpファイル(たとえば、wp-content / plugins / disable-url-autocorrect-guessing.php)に追加すると、Wordpressのオートコレクト「推測」機能を無効にするためにアクティブ化できる素敵なプラグインができます。 。

トラブルを回避するために、私は実際にこれを行い、Wordpress.orgで私のプラグインを渡しました。そこでレビューされたら、https//wordpress.org/plugins/disable-url-autocorrect-guessing/からダウンロードできるはずです


これは実用的なソリューションですが、提案されたコードは多少ハックです。https://core.trac.wordpress.org/ticket/16557の機能リクエストが実際に実装されると、これに対するより優れた解決策と、推測を実際に実行する方法をより適切に制御できるようになります。


私はこれを3回
賛成できればいいのに

ページリダイレクトで問題が発生したとき、私は刺激を受けました。するつもりだったremove_filter()。しかし、今私が問題を抱えている特定のケースのみをバイパスします。ジャストインケース私の問題について関心のある人:wordpress.stackexchange.com/questions/307670/...
Parixit

v5以降では動作しません
nodws

@nodws:何を言っているのですか?5.2.2のコードスニペットでプラグインを使用していますが、それでも問題なく動作します。
Hauke P.

ああ、それはYOASTのリダイレクトとの衝突でした
nodws

0

残念なことにredirect_canonical()、400行以上のコードがあり(リリースごとに増え続けています)、目的によって制御されるように特に構成されていません。柔軟に構成できないのは、全部かゼロかの取引です。

実用的な観点から見ると、最良のオプションは次のとおりです。

  1. リダイレクトを手動で処理しtemplate_redirectます。
  2. redirect_canonicalターゲットが思いついた場合、フックとしてリダイレクトを防ぐことは望ましくありません。

どちらの場合でも、望ましくないリダイレクトを正確に行うロジックを開発する必要があります。


ええと、それは予想外に非常に残念です。:-(望ましくないリダイレクトの私の定義は非常に単純です:正確に解決することはできませんすべてのURL 1のターゲット(ただし、複数またはなし)は望ましくなく、404を生じるはずである
Hauke P.

@HaukeP。それを担当するロジックはその一部でredirect_guess_404_permalink()あり、そのような区別はしません。SQLが生成する最初の一致を
取得し

:実は私は自分自身で解決策見つけたwordpress.stackexchange.com/a/144970/51898
Hauke P.

@HaukeP。「厳密に1つのターゲット」について少し誤解しました。ファジーマッチングの一部のケースは技術的に1つのマッチのみに解決されるためですが、それは一般にファジーなものを取り除くこととは
異なります

ええ、実際、最後のコメントを書いている最中に、誤解を恐れてもう一度考えてみました。:)結局のところ、私はコメント(および質問)をより正確に書いたはずです。
Hauke P.
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.