いまではもう無効になった内容を含んでいるかもしれないことをご了承ください。なんでこんなことになってしまったのかはよくわからないのですが、僕のようにWordPressをWeb開発のフレームワークにしている場合、こんな風に考えることがあります。WordPressはなにもしなくてもサイトが出来上がって便利だなあ、管理画面もついてるしそうだ、投稿じゃなくて購入履歴のDBを追加しよう!購入履歴一覧とか、購入履歴詳細とか、そういうのほしいなあ>>>>>突然のめんどくせ<<<<<なんでめんどくさくなるかというと、WordPressは次のような処理を行っているからです。\(^o^)/ここでWP_Postを拡張しうる仕組みが存在していれば、フレームワークとしてもうちょっと色々できて便利なのですが、そうはなっていません。調べてみると、「なんでWP_Postがfinal(継承不可)やねん、継承できるようにしてやー」と言っている人がいます。WP_Post結果から言うと、ともに却下っぽい感じですね。Nacinというコアコミッターによると、「WP_PostはAPIじゃなくてセキュリティ用のクラスだからfinalなんだよ」とのことです。妥当かどうかは知りませんが、理由あってのこと。なんとかならないかなと思ってやってみました。$var;});まず、クエリバーにsubscriberという文字列を追加します。これによってWP_Queryはsubscriberというパラメータを受付けるようになります。具体的に言うと、http://example.jp?subscriber=hogeを受付けるということですね。これをリライトルールで拡張すると、http://example.jp/subscriber/hogeというURLで「hogeというsubscriberを表示するのね」となります。ここら辺、MVCフレームワークと同じルーティングですね。リライトルールのコードはメンドクサイので書いてません。Codexのカスタムクエリやクエリ概要など参照してください。続いて、本来なら取得するであろう投稿データではなく、ユーザーを取得してみます。WordPressはMVCではないので、SQLをいきなり書き換えます。