昨日のポストの続き。
しかしなぜだか、整理してうまく文章にまとめることができないでいる。
しょうがないので、思いつくものをまとめることを考えず書いてみることにする。
今一度、全体の構成は以下の図を参照。
はてなブログからの移行について気を付けたこと
移行データは AtomPub APIを使って吸い出した。
通常のはてなブログのバックアップだとMT形式かつ.mdファイルをレンダリングした後のHTMLファイルとなってしまうので。AtomPub APIだとMarkdown形式のままバックアップを取ることができる。
APIコールはbouzuya/node-hatena-blog-api: Hatena::Blog AtomPub API wrapper for Node.js (unofficial)をES6ベースに書き直したものを使用した。
sfpgmr/node-hatena-blog-api2: Hatena::Blog AtomPub API wrapper for Node.js (unofficial)
データの吸い出しはgetentry.jsで行い、さらにhatena-converter.jsで独自仕様の.mdファイルに変換している。
移行に備え事前に独自ドメイン(blog.sfpgmr.net)に切り替えた。
独自ドメインにしておけば、移行後のWebサーバーでもURLを合わせることができ、検索エンジンからのトラフィックを極力失うことなく移行ができる。
ただ今回の場合、はてなブログはhttpで移行後のWebサーバーはhttps(HTTP/2/)なので、nginx側でリダイレクト設定を行っている。さらにはディレクトリ構造も変更したから、それもリダイレクトしている。Webサーバーの設定である程度融通が利かせられるからで、自前Webサーバーだからできることでもあるのだが。
AMP対応はやっぱり面倒
AMP HTML対応はjxck blogの記事(AMP HTML 対応 | blog.jxck.io)を参考にした。確かにとても制約がきつくて面倒だった。 しかしいくらモバイル表示を高速化するためとはいえ、このようなきつい制約を仕様に課すというのはどうなのかなぁ。。とも思う。。
私的にはタグのstyle属性が書けないのが結構痛かった。MathJaxではstyle属性を使って、処理結果後の数式の高さに応じてセンタリングを行っているので。。かといって、これをheadのスタイルシート中に数式ごとに定義するのは現実的ではないしね。取り急ぎAMPではstyle属性を除去することで対応した。
<iframe>の対応も面倒だ。けれどもたいていはyoutubeをembedしたものなので<amp-youtube>に置換し、それ以外のものは<amp-iframe>にプレースホルダを入れて対応した。<amp-iframe>は「above the fold」の部分を<iframe>で覆われないように、「ファーストビューの領域の75%よりも下、または最上部から600pxより下」に配置しないと、表示できないようになっていて、その場合はプレースホルダを表示するようになっている。
プレースホルダによる代替表示は「S.F. Blog:canvasでWebGLを使わずに立方体を描く」で確認することができる。「amp-iframeの制約により、表示できません。」と表示される部分は、プレースホルダのイメージ(svgファイル)である。
しかし上記のプレースホルダ表示される部分は「above the fold」制約にひっかかるのではどうもないようだ。実際のエラー表示は以下となっている。
Origin of <amp-iframe> must not be equal to container
(<amp-iframe>のオリジンはコンテナと同じであってはいけません。）
sandox属性のallow-same-originは設定しているのだが。。どうもこの<iframe>のsandbox属性の狙いや意味が理解できていないので、もちょっと勉強しなくてはいけない。
<amp-image>のwidthとheightの指定が必須なところは、実際にファイルをGETして「image-size/image-size: Node module for detecting image dimensions」を使いwidth・heightを取得し設定するようにして対応した。
ああ、面倒だ。。
nginxのuri($uri)はdecodeされてしまっている件
私の環境では、コンテンツはWindows 10で作り、それをgithub経由でubuntuサーバーにデプロイしている。問題になったのは、文字コードである。もうちょっというと、コンテンツのファイル名の文字コードである。ubuntuやgitはutf-8に対応しているので、ファイル名をutf-8にすることについては問題はない。が、Windows 10はそうはいかない。思いっきり化けてしまう。
これを解決するのに私はファイル名をurlencodeして保存することにした。そうすればWindowsでも文字化けすることはない。だがこうするとnginxで問題が発生した。
nginxはencodeされたuriをdecodeしてファイルシステムに渡してしまうので、「ファイルが見つからないエラー」となってしまうのである。いろいろ調べた結果、nginxのtry_filesの設定に$request_uri $request_uri.htmlを追加することで対応した。
try_files $request_uri $request_uri.html $request_uri.xml $uri $uri.html $uri/ = 404;
「$request_uri $request_uri.html」は、decodeされていないのでこれでうまくいくのである。。
TeX用のタグを\TeXとした理由
md中のTeXを変換するのにMathJaxを使っている。普通ならTeXコードは$$もしくは$で囲むのが一般的だ。あとはてな記法だと[tex:~]などと書くのであるが、私のコンテンツは文中に$を結構使用しているので、その部分がTeXに変換されてしまうのである。また[tex:~]だとTeX中の[]をエスケープしなくてはならず、面倒なので\TeXで囲むことにしたのである。
そういうわけで
思いついたことは書いたが、何か思い出せばまた書くことにする。。
ちなみにレポジトリはこちら
sfpgmr/www: ホームページ管理用レポジトリ