Posts Tagged ‘atahualpa’

木曜日, 8 月 13th, 2009

暫く前から見聞伝本家はAtahualpa342で動いている。のだが…。
Atahualpa342導入時、私は大いに期待していた。
特に「CSSとJavaScriptの外部化」にはちょー心躍ったのだ。
CSSを外部化するコードをatahualpaのheader.phpに書き込む、なんて邪道は要らなくなるぜ!
と無邪気に喜んだのだが…。
糠喜びでしたorz

まぁ導入する時にちゃんと調べて置けよ、って話ですけどねー。
とりあえず動作確認しただけで安心しちゃったんですよ。
気付いたのは、8/6に朝倉氏の指摘があってでした。
「何かAtahualpa新しくなってから動作遅くね?」@駒場図書館
うーんマジで?それは困るな…。と思いつつとりあえずSafariのWebInspectorを起動。
確かにどう考えても遅くなっている。しかもリロードしても殆ど速度が上がらない。
その上遅いのは件のCSSとJSっぽい。ナゼ?
というかリロードして速くならないのだから一々生成しているとしか思えないが…。
先ずはここから、とページソースを見てみれば外部CSSの記述には?bfa_ata_file=cssの文字が。
モロまんまクエリじゃねーか!
これでアクセスの度生成している疑いは濃厚を超えて限りなく黒に近いグレーに。
しかし未だ逮捕状は降りない。物証主義だから。
wpmu/?bfa_ata_file=cssにもアクセスしてみるが、圧縮(空白文字を除去)されたCSSが表示される。
アクセスにかかるラグからするとやはり生成が行われている気配が濃厚だが、詳しく調べる時間が無かった。
続きは家に帰ってから、という事でバイトに出撃する。

さて帰宅して第二ラウンド。手始めにatahualpa342の配下でbfa_ata_fileを含むファイルを洗う。
functions.phpが何かやっているので見てみる。
思えばここで道を踏み外した…。
190行目付近の記述に引っかかり、add_filter()の動作を追うべくWPMU本体のソースコードの山へ…。
この期に及んでもfilter_hookとaction_hookの辺りが良く分かってないんです。
やっぱ使ってないからかなぁ…。
なんて愚痴?はともかく、ソースを掻き分け、query_varsにbfa_ata_fileを登録しているらしい、ということは分かった。
しかしその登録されたクエリがどうやって解釈されるのかが良く分からない…。
そういうコードはどこから見つければいいんだ???などとよく分からない悩み。
この辺で8/8位ですね。この後煮詰まり感からしばし中断。

第三し…おっとっと。こんな所でゼミ長を喜ばせている場合ではないのだ(そこ?
第三ラウンドはなんと今朝から始まった。アレだけ煮詰まってたのに…。
解決する時は案外あっさり解決するものである。
今日はなんだか朝っぱらからこの間近所の図書館で借りたJavaScriptの参考書を眺めていたのだが、そしたらなんだか当たり前のことに気付いたのだ。
余談だが、私がこの手の参考書を読むのは珍しい。
大変いい世の中になったもので、大抵の言語(※もちろんコンピュータ言語デスヨ)のリファレンスやサンプルは、Webだけで手に入ってしまう。
話を戻すと、気付いたのは「結局CSSを出力する部分はAtahualpaと同じタイミングでインストールされたはずである」、つまりatahualpa342の配下に最終的に出力するためのコードが含まれているはず。
当たり前の話なんですがねぇ…。ここのところゲームとかゲームとかゲームとかに現を抜かしていたせいか、頭があんまり動いていなかったらしい。
でatahualpa342でgrepしたら「CSS」という語を含んだファイルが見つかる見つかる。
やっぱり怪しいのでfunctions.phpをあけようとフォルダを開くと…。
css.phpってファイルがあるじゃーありませんか。どう見てもこいつだろw
ナゼ最初に気付かない自分。
開けて見るとやっぱりコイツデスヨ。セットでjs.phpってヤツも居るしね…。
さてどこからこれが呼び出されているのかなーとgrepすると、functionsの私が捕まってた行から30行も下じゃない所にあったし。
細かい経緯は不明だけどbfa_css_js_redirect()って関数がtemplate_redirectってアクションにフックされているので、こいつのせいだろ。
さて結局の所、atahualpa342はCSS/JSの外部化はするが外部ファイル化はしないということが判明したわけです。
なんというか中途半端な機能だな…。これじゃーヘッダを見栄えよくする以上の意味は無いではないか。

つまるところ、旧Atahualpaとほぼ同等の手続きをとってCSSをファイルとして保存せにゃなるまい、というのが結論。
CSS関連だけ一ファイルにまとまっているのは改造しやすいけど…。Atahualpaが更新されるたびにこれをやるのかと思うとちょっと気が重いぜorz
さて改造しますか…。ついでにzip圧縮も試してみようかな…。でも圧縮ファイルが受け取れるブラウザかどうかってどうやって判別するんでしょうか?
投げっ放しでとりあえず完。

さらば700行

金曜日, 6 月 19th, 2009

さてAtahualpaの改造だが、一応当初の予定通りの動作をするものが出来た。
ソースを見てもらえば、以前はヘッダにあった長大(700行を越える)なCSSが無くなって、代わりにbfa_ata_style.cssとか、そんな名前のファイルが読み込まれる様になったのが分かると思う。
私が行った改造の具体的な内容及び手順は以下。

  1. Atahualpaの設定が更新されたことを記録するタイムスタンプをadd_optionで用意(実は必要ないが、念のため)
  2. Atahualpaのフォルダ直下にある、functions.phpを開けて、update_option()を呼び出している部分を探す
  3. 上記部分(Save Settingsを押すと呼び出される関数)の末尾に、タイムスタンプをupdate_option('option_name',date('YmdHis'))で記録する部分を追加
  4. header.phpに、カテゴリ判別してスタイルシートの名前を生成するコードを追加(以前からカテゴリ判別してCSSを書き換えていた)
  5. ファイル名を$filenameとすると、filemtime( TEMPLATEPATH . $filename)と、先ほどのタイムスタンプを比較して、タイムスタンプが大きければCSSを再生成する
  6. CSS再生成は具体的には以前のCSSを書き出していた部分の前後から、<style></style>を取り除き、前後にob_start()ob_get_clean()を配置、 バッファリングした内容を変数で受けて、ファイルに保存($filepointer=fopen($filename,'wb+'); fwrite($filepointer,$content);)
  7. 最後に、再生成をしてもしなくても、<link rel='stylesheet' href='春眠に限らず暁を覚えず'>を吐くように記述。

しかし誤算があった…。本家ブログだけでAtahualpaを使っているつもりだったのだが、そうではなかった。
木許さんのブログでもAtahualpaを使っていたのでした…。
複数のブログでAtahualpaを使うと、CSSが一種類しか生成されていないので片方の設定が更新されると、もう片方で読み込まれるCSS(同じファイル)が変わってしまい、結果奇妙なことが起きるのは想像がついていたのだが、「確か他にAtahualpa使ってる人はいないよなー、じゃあブログ判別ルーチンは書かなくていいや〜」と適当に書いた所、案の定衝突が起きました…。
現在はまずglobal $blog_idを呼び出してブログ判別を行い、更にその後カテゴリ判別をしています。
カテゴリとカテゴリIDの対応は、当然ブログ毎に違うので、この判定ルーチンはブログID毎に用意しなくてはいけないのが難点です。
今は本家以外ではカテゴリ判別を行っていないので特に問題はないけど、他でも行おうとすると中々面倒なことに。
引数としてブログIDとカテゴリIDを渡すと、ファイル名を生成するみたいな専用関数を書かないと収拾が着きませんな。
$filename=cr_fname($blog_id,$cats)みたいな。
しかも実際に吐き出すCSSの内容も変更しなくてはいけないので、中々難儀。
そうなったら変更に合わせた内容をoptionに格納してしまうぐらい必要だなー。
要らぬ心配(?)をするのでありました。

あたわるぱ。

水曜日, 6 月 10th, 2009

さてお約束通りCODINGネタ。
前回のキャッシュする作戦は一応成功したらしく、運悪く再生成する場合には、顕著に表示が遅くなる。
まぁ自己満足ですけどね。
でもアルゴリズム的に無駄な所を一カ所発見してショーック。
make_update_list()は、引数を4つ取っているのですが、当然どんな引数が渡されるかは実行時にならないと分かりません。 つまり、前回の引数と違っていたら、動作を変えなくてはいけないので、キャッシュを破棄して再生成しなくてはいけない。
そこで、再生成する度にそのとき使った引数をデータベース上に保存することにしたのですがー。
別に個々の引数が必要な訳じゃないんだから、まとめて判定してまとめて保存しておきゃーいいのに気付かず、 いちいち引数四つを個別に更新しているか判定、さらに個別に保存してまつた…。
後で直します…。

さて次の私の(自己満足の)ターゲットは、本家のあの長〜いヘッダ。アレどうにかしたい。CSSを外部ファイル化したい。とてもしたい。
その為のHeadClearnerってプラグインもあるんだけど、諸般の事情により使えないので、自作(!)しちゃえ。
自作と言う程のことは出来ないけど、Atahualpaのheader.phpを操作(ってかhack)すれば、ページに出力されるCSSが変更できるのは実証済みなので、 その出力を(場合によって)ファイルに保存しておけばいいのです。で、<style rel=”???.css”>とか書き込めば、うまくいく筈ですよね?
同じCSSを使っているページなら、外部CSSファイルを共有して、ブラウザ側でキャッシュしてくれるので、そう言う意味でもサーバ側もクライアント側も嬉しい筈。

で、方針。echoをリダイレクトします。出来るのかチェックした訳じゃないんだけど、これだけCそっくりなんだったら、標準出力への出力をリダイレクトする機能も多分あるでしょ。
CSSをモーレツに出力し始める手前で、条件分岐して、ファイルの更新日時と、タイムスタンプを比較して、もし設定が変わっているようなら、ファイル出力をやり直します。
そうでないなら素通しで。あ、あとカテゴリ毎に違うヘッダを適用するって、Atahualpaじゃ出来ないんでしょうか。Atahualpaの設定項目のほとんどは、CSSの形でheader.phpで呼び出されてしまうので、 header.phpの内容をどうにかしない限りは、どうにもならない。
今はheader.php内にカテゴリ判別を付加して強引に動かしているのですが…。
そんな感じ。いつ取りかかれるやら…。Atahualpa設定項目多過ぎですよ(泣)。