WordPressのPOSTデータの一覧表示や絞り込みなどを行う場合、WordPressのURLパラメータを設定するのが便利です。
しかし、WordPressのドキュメントで綺麗にまとまっているところが見当たりません。そこで色々探していたところ、WORDPRESS高速化パッケージKUSANAGIを提供しているプライム・ストラテジー様のブログにURLのパラメータのまとめ記事が掲載されていましたので引用させていただきました。
パラメータの理解
パラメーター名 | 役割 | 指定例 |
---|---|---|
m | 日時 | 201304 |
p | 投稿のID | 1234 |
posts | 不明 | |
w | 週 | 12 |
cat | カテゴリーのterm_id | 1 |
withcomments | コメントフィード関連 | 1 |
withoutcomments | コメントフィード関連 | 0 |
s | サイト内検索の検索文字列 | WordPress |
search | 不明 | |
exact | 検索時完全一致にするかどうか | 1 |
sentence | 検索文字列の分解を行うか | 1 |
calendar | 不明 | |
page | ページ分割時のページ送り数 | 3 |
paged | アーカイブページのページ送り数 | 5 |
more | moreの表示 | 1 |
tb | トラックバック | 1 |
pb | 不明 | |
author | 作成者のユーザーID | 2 |
order | アーカイブの昇順・降順 | asc |
orderby | アーカイブの順列 | date |
year | 年 | 2013 |
monthnum | 月 | 4 |
day | 日 | 16 |
hour | 時 | 20 |
minute | 分 | 21 |
second | 秒 | 23 |
name | 投稿スラッグ | hello-world |
category_name | カテゴリースラッグ | uncategorized |
tag | タグのterm_id | 4 |
feed | フィードの種類 | rss2 |
author_name | 作成者名 | omagari |
static | 不明 | |
pagename | 固定ページのスラッグ | sample-page |
page_id | 固定ページのID | 2 |
error | レスポンスコード? | 404 |
comments_popup | コメントポップアップ | |
attachment | メディアのスラッグ | koara |
attachment_id | メディアのID | 11094 |
subpost | attachmentのエイリアス | |
subpost_id | attachment_idのエイリアス | |
preview | プレビューかどうか | 1 |
robots | ロボットテキストかどうか | 1 |
taxonomy | 分類 | category |
term | 分類のスラッグ | uncategorized |
cpage | コメント分割時のページ送り数 | 4 |
post_type | 投稿タイプスラッグ | custom_post |
この標準で利用できるパラメーターは、wp-includes/class-wp.php の最初に記述されている、WP クラスのメンバー変数、$public_query_vars として定義されています。
URLからパラメーターへの変換 – リライトルール –
パーマリンクの設定をデフォルト以外にした場合、アクセスされたURLを元にしてパラメーターに変換を行っています。
例えば、 https://www.prime-strategy.co.jp/wp/2499/ は、内部的に、 https://www.prime-strategy.co.jp/index.php?p=2499 に変換されてから処理されています。
では、どうやってパラメーターへの変換を行っているのでしょうか?
WordPress は、デー タベース上に表示可能なURLのパターンとパラメーターへのマッピングデータを持っています。これをリライトルールと言います。
マッピングデータというからには、あのパターンはこの変換、このパターンはこの変換といったように、複数の変換ルールによって構成されています。例示するとインストール直後にパーマリンク設定を行った時点での変換ルールは68通りとなります。
リライトルールの変換方法
リライトルールは、URLパターンの正規表現をキーとした連想配列で構成されています。
この連想配列をループ処理によって、順繰りに先頭からURLとの照合処理を行い、最初に合致した変換ルールを採用します。つまり、リライトルールの中に複数合致するものがあったとしても、より先にある変換ルールが採用されるというわけです。
たとえば、カテゴリーのURLと同じになる固定ページを作ったとしても、カテゴリーが表示されるのは、カテゴリーの変換ルールが先に記述され変換ルールとして採用されるためです。
採用された変換ルールの確認
想定したURLにアクセスしても、意図したとおりの表示にならなかった場合、まずは、この変換ルールが正しく行われているか確認しましょう。
確認するのには、Debug Bar と Debug Bar Extender を使うと、ブラウザ上から簡単に確認することができます。
想定したURLにアクセスして、Debug 表示のRequest メニューを見ると、リクエストされたURL(Request )、採用された変換ルール(Matched Rewrite Rule )と変換されたパラメーター(Matched Rewrite Query )が分かるようになっています。
図の場合は、archives/2593 というリクエストに対して、archives/([0-9]+)(/[0-9]+)?/?$ という変換ルールが合致し、p=2593&page= へと変換されたということになっています。