基本的には link 要素によるナビゲーションだが、未対応ブラウザに対しては妥協して変換してやる、と。
今のところ考えているのはそんな感じです。最初は全部サーバ側で済ませてしまおうと思ったんですけど、閲覧者に提供される HTML のソースは従来通り body 要素内にナビゲーションがあるわけで、結局サーバ内の変換前のソースがきれいになりましたというだけの自己満足に終わってしまう
ことに気付いたので、やめます。ダメじゃん、と。
IEなんかの場合は仕方ないのでサーバ側で変換、XSLT処理できる視覚系ブラウザにはクライアント側で処理してもらう、みたいな、そんな感じ。で、今借りてるサーバだと、XSL絡みの関数がPHP内で使えないのでどうしよう、みたいな。
「アオイシロ」が予定通り届いたけど、結局今日、っていうか昨晩は1分もプレイせずじまい。帰宅が遅かった、且つ疲れて文字読む気が起きなかったから。
無駄に限定版買ってみたので、ブックレットだけ流し読みしました。「ダメだこれ、本編やってから読むものだろ」って感じ。ネタバレ云々じゃなくて、意味が分からない。土日使ってプレイすることにしますです。
MHP2Gも地道にプレイ中。ナルガX装備を作るべく奮闘中。ナルガ素材はどうでもいいとして、モンスターの特濃集めるのが面倒。森丘の爺さんが浮岳龍の体液と交換してくれるらしいので、それ使った方がランゴスタ狩るより早そう。
まー、そんな感じです。あー、土日はお試し期間中のCORESERVERも弄ってみないと。
smallballの山口氏から、さらにナビゲーションについての言及が。たしかにJavascriptとかCSSで何とかするのは微妙ですねー。検索はやっぱりあったほうがいいのか。っていうかあった方が便利ですよね。
各ブラウザの実装とか、ブラウザへの依存度とかを考えるとlink要素でナビゲーションを記述して、サーバ側でXSL変換かけるのがベストかなぁ。ブラウザにXSL処理させるのはユーザの環境によって実装に差がありそうだし、サーバ側で処理した結果をユーザに返した方がよさそう、とか。
と、思ったらSablotronとexpat入れなきゃいけないのか。今のサーバじゃ無理だなぁ。サーバ会社に問い合わせたところでインストールしてもらえるとは思えないし。お試しでCORESERVER借りたんだけど、こっちはいけるっぽい。PHP4じゃなくて5だから、XSLTプロセッサがSablotronじゃなくてlibxsltだけど。サーバ引っ越そうかなぁ。今使ってるEasytoneはレスポンスとかに不満はないけどPHP4なのがイヤ。
はてブとかでamachang氏の書いた技術系の記事（最近だとProcessing.jsの記事）とか、Think itの「[Think IT] 第1回：そろそろ本気で学びませんか？ (1/3)」なんかをブックマークしてる人って、きちんと勉強してるのかな、試しているのかな、っていつも疑問に思ってます。
私もわりとそうなんだけど、ブックマークしただけで勉強した気になったりしてないかなって。所謂「あとで読む」的思考で、結局何もしない人が結構いたりするんじゃないかな、とか勝手に思ってます。すごい失礼なこと書いているのは承知で、あえて書きますけど。自分への戒めも兼ねて。
ついでに言うと、Think itの当該記事は大したこと書いてないよね。何であれのブックマーク数が600超えるのか分からない。
ナビゲーションをbody要素内に書かないで、link要素使って何とか出来ないものかと思案中。
HTML文書を「Webサイトの1ページ」ではなく「文書」として考えた場合、本文中に「ナビゲーション」なんてものが書かれているのはおかしいと思うんです。smallballにナビゲーションネタが書いてあって、そんなことを改めて思ったわけです。
で、link要素で何とかしようと思った場合、XHTMLをXMLとして扱っていることを利用してXSLT使うか、Javascriptか、って感じ？ あとCSSで何とかする方法もあるのかな？ テストしてみて何とかなったら実装してみます。いつになるかは例によって未定。現状維持って可能性も大いにあります。
URLが変わってしまう
URLって変わりますか？ PHP化したから何ってないと思うけどなぁ。MT4だと何か違うのかな。拡張子が変わるから？ もし拡張子がどうのこうのって話であれば、htaccessファイルで.htmlでもPHPとして処理するように変更してしまえばいいだけだと思います。見当違いっていうか、ぜんぜん関係ない話だったらごめんなさい。
あー、ダイナミックパブリッシングにすると変わるのかな。うちはPHP化はしたけど、ダイナミックパブリッシングにはしていなかったのでその辺が謎。
動的ファイルなので、検索エンジンに掲載されにくい
それと。これはたぶん関係ないです。複雑なパラメータつきのURLはインデックスされにくかったはずですが、それとMTのPHP化は無関係です。MTをPHP化してもURLにたくさんパラメータがくっつくとかないですよね。これもダイナミックパブリッシング使うと何かあったりするのかな、謎。MTをページ動的生成システムとして使ったことがないので謎が多すぎる。（だったら言及するなって感じですね、ごめんなさい）
ただ、「動的生成されたページ」がきちんとインデックスされることはAmazon内のページが死ぬほどインデックスされていることを見れば明らかです。要するに「http://example.com?id=1234567&page=1234567&post=1234567」みたいなのが良くないってだけの話であって、「インデックスされにくいこと」と「ページが動的生成されていること」とは直接関係ないってこと。
MTの出力ファイルをPHPとして扱う利点の中で個人的に一番大きいのは「PHPのincludeが使える」ってところかな。SSIとかでも別にいいんですけどナビゲーションとかヘッダ内の何かに変更を加えたときに再構築しなくて済むのはいいですね。MTテンプレートのモジュールでも似たようなこと出来ますけど、再構築しないと変更点が反映されないですからね。link要素でリンクしているCSSファイルの名前が変わった、とか軽微な変更で逐一再構築しなきゃいけないのは、エントリー数が増えたときに辛いです。
サーバの処理の重さとしては、静的なHTMLより重いのは事実。アクセスされるたびにPHPとして処理をするわけですから。まぁ仕方ないですね。サーバサイドスクリプトの宿命ってことで。
リンク集とサイト情報のページをWordPressのページにしました。その関係で、古い静的HTMLのページからはリダイレクトかけてます。たぶん、リンク切れはないはずです。
リンク集はWPのリンク機能で管理することにしました。が、標準で用意されているテンプレートタグだと、旧静的HTMLと同じ表示にならなかったのでPHPの関数を自作。サイト情報のページは単なるページなので特に問題なかったです。