【設定例を変更しました。】固定ページのURLをナウなヤングにバカうけなやつにしようと思いRewriteRuleの設定を試みたところ、かなりハマった件。

By | 2018年7月7日 , Last update: 2018年11月7日

はじめに

WordPressの固定ページはパーマリンク設定がデフォルトのままですと、以下のようなURLになると思います(「サブタイトルネタ帳」の例です↓ この記事を最初に書いた時点では別のページの例を記述していましたが、変更しました)。

https://pandanote.info/?page_id=1874

 
(このURLがSEO的な意味で最適かどうかという議論もあるかとは思いますが、ここではそれには触れません。)

このWebサイトを始めた当初は、このサイトがどういう方向に育っていくのか、そもそも三日坊主で終わらずに長続きするのかというあたりが見えなかったわけですけど、記事の本数も100本を超え、固定ページもそれなりに増えてきたところで、上記のURLも

https://pandanote.info/catchphrase

 
というようなURLに変えてもそろそろ罰が当たらないのではないかと思い始めたわけです(ページのタイトルとURLで使用している英単語が異なるのは気にしない方向でお願いします)。

ただ、Wordpressのパーマリンクの変更機能だと、特定の固定ページのURLを書き換えるといった用途には使用することはできません。また、すでに運用を行っているWebサイトのページということで、すでにGoogle先生等にはインデックス化されていることと思われますので、「URLが変わりましたよ。」的なお知らせもしっかりしておきたいところであります。

そこでこの記事では、Apache httpdの設定ファイルをいじるところで固定ページのURLをよりクールにする方法について書いていきます。かなりハマりました。

スポンサーリンク

やりたいこと。

まず、やりたいことをまとめておきます。仕様ですね。

  1. もとのURL(以下、「旧URL」と書きます。)は
    https://pandanote.info/?page_id=1874&_r=2&_o=1

     
    のようにpage_id以外のパラメータが複数つく可能性があるので、page_id以外のパラメータは残したい。上記の場合には、以下のように書き換えられて欲しい。

    https://pandanote.info/catchphrase?_r=2&_o=1

     

  2. 上記の場合には「301リダイレクト」を行う。つまり、ブラウザから再度新URLでリクエストが行われます。
  3. 逆に
    https://pandanote.info/catchphrase?_r=2

     
    がURL(以下、「新URL」と書きます。)としてリクエストされた場合にはApache httpdの内部でURLを

    https://pandanote.info/?page_id=1874&_r=2

     
    に書き換えてWordpress側に渡して処理をさせたい。この場合、リクエストしてきたクライアントにはリダイレクトを通知しない。

ということになりますが、これって本当にできるんですかね…

リダイレクトがループするんじゃないかとちょっと不安になりますが、やってみることにします。

サクサクと設定。


スポンサーリンク

仕様が決まったら、サクサクと設定していきます。なお、本節の設定はpandanote.infoというVirtualHostに対して行っています。

新URLから旧URLへの読み替え。

まず、こちらを先に設定します。VirtualHostセクションでRewriteEngineを使用する設定を行っているところ(以下のような行です。)

RewriteEngine on

 
の後ろの適当なところに以下の設定を追加します。

なお、LocationMatchの行以降の設定は他の設定との兼ね合いで設定しているものであり、必須の設定ではありません。

Apache httpdが生成するディレクトリのインデックスを使用しない設定としているので、読み替えの結果を “/?page_id=1874″と指定するとエラーになってしまうため、”/index.php?page_id=1874″と指定しています。ここはクライアントからは見えないところですので、多少冗長でもやむを得ないところです。

Chromeの301リダイレクトのキャッシュの無効化またはキャッシュの削除

ここまで設定できたところで、Chromeで動作確認です。

ところが、何回試しても”/recolog/?page_id=1874″にURIが書き換えられてしまいます。

そこで、ログレベルを以下のように設定してhttpdを再起動してみることにしました。

LogLevel warn rewrite:trace9

 
再起動後にURLがどういう経過を経て書き換えられているのかや、httpdのログファイルをじーっと見直してみると、どうもリダイレクトなしにいきなり上記のURIに対してアクセスが来ていることがわかりました。

こうなると、Chromeが何らかの悪さをしているとしか思えません。(´・ω・`)


スポンサーリンク

そこて、Firefoxを使って https://pandanote.info/catchphrase にアクセスしてみると…

なんと!!

設定どおりに読み替えられました!! (`・ω・´)ゞ

そんなわけで、Google先生にお伺いを立てること小一時間。

それによると、Chromeは301リダイレクトを行った際の結果についてもキャッシュするんだそうです。ところが、設定ミスなどが原因で意図しないリダイレクトが最初にされてしまうと、それを取り消すにはChromeのキャッシュを削除するかキャッシュ機能を無効化するしかないようです。

そこで、Chromeのキャッシュを削除してからhttps://pandanote.info/catchphraseにアクセスしてみると、URIが意図した通りに読み替えられました。(`・ω・´)

※補足: Firefoxの新しいバージョンでも301リダイレクトをキャッシュする仕様になっているようです。

旧URLから新URLへのリダイレクト。

次は、旧URLから新URLへのリダイレクトのための設定を行います。こちらはクライアントにもURLが変更されたことを熟知してもらう必要があるため、301リダイレクトを行うように設定します。

設定は前項に示した設定の直前に以下の記述を追加し、Apache httpdを再起動することにより行います。

上記の記述のうち、2行目でpage_idをクエリ文字列から取り除き、3行目では後方参照により残りのクエリ文字列をURIの末尾に付加しています。

ここで、再度動作確認。

ここまでの設定が問題なく動くかどうかを確認します。301リダイレクトがキャッシュされていると、本来の動作にならない可能性がありますので、動作確認の前に動作確認に使用するブラウザのキャッシュをクリアしておきます。

既存のPHPファイルなどに埋め込まれているパスの変更。

最後に、既存のPHPファイルなどに埋め込まれているパスを変更します… と言いたいところですが、この記事を最初に書いた時点(2018年7月)では絶賛作業中です。

スポンサーリンク

まとめ

JavaでいうところのString#replaceメソッド的な文字列の置き換え感覚で使っても何となく使えてしまうRewriteRuleですが、使い込んでみると、かなり奥深いものを感じますね。

この記事は以上です。

参考文献