2015/01/24(土)PukiWiki bodycache patch副作用:id重複
PukiWiki bodycache patch副作用:id重複
たまたま気が付いたのですが、ECO-Wikiのメニューバーと本文それぞれの見出しのidが重複していました。
例えば、ECO-Wiki (acronia) トップページでは、メニューバーの「ECO攻略Wiki」と本文の「ECO-Wiki (acronia):エミル・クロニクル・オンライン攻略情報wiki」に同じid="content_1_0"が振られています。
原因を追ってみたところ、どうやらbodycacheパッチの副作用のようです。
- 発生条件
- PukiWiki bodycacheパッチを適用している。
- MenuBarと本文の両方で見出しを使用している。
- 原因
- bodyキャッシュを読み込んだときは、本文に対するconvert_htmlの実行はスキップされる。その結果、convert_html内の$contents_idがインクリメントされなくなるため、メニューバー生成時のconvert_htmlの実行結果に影響を与えてしまう。
function convert_html($lines) { //省略 static $contents_id = 0; //省略 $body = & new Body(++$contents_id); //この$contents_idのインクリメントが必要 //省略 }
- bodyキャッシュを読み込んだときは、本文に対するconvert_htmlの実行はスキップされる。その結果、convert_html内の$contents_idがインクリメントされなくなるため、メニューバー生成時のconvert_htmlの実行結果に影響を与えてしまう。
- 対策
- 場当たり的な対応ですが、$bodycache_statusが'cached'になっていたら、bodycacheによりconvert_htmlの実行がスキップされたと見なして、$contents_idをインクリメントするコードを追加しました。
function convert_html($lines) { //省略 static $contents_id = 0; global $bodycache_status; if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み ++$contents_id; } //省略 $body = & new Body(++$contents_id); //省略 }
- 場当たり的な対応ですが、$bodycache_statusが'cached'になっていたら、bodycacheによりconvert_htmlの実行がスキップされたと見なして、$contents_idをインクリメントするコードを追加しました。
追記
改良したbodycache patchを公開しました。
2015/01/23(金)タイトルプラグイン
タイトルプラグイン(PukiWiki)導入
ECO-Wiki (acronia)にタイトルプラグインを導入しました。これで、ページ名(URL)とは別に、自由にタイトルを設定できるようになります。
導入した理由ですが、検索エンジンでの検索結果には基本的にタイトルが表示されるので、そこを分かりやすくしたかったからです。あとは、うまく使えば検索結果の上位に表示されやすくなってくれるかな~。
bodycacheとの干渉
タイトルプラグインですが、すんなり導入できるかと思ったら、bodycacheと干渉しました^^;
タイトルはbody部に含まれないので、確かにそのままだとタイトルはキャッシュ対象外になってしまいます。
対策としては、bodycache側を改造して、タイトルもbodycacheファイルに含めるようにしました。(ファイル構造が変わるのでバージョンを1から2に変更。)
追記: 2015/01/24
今のECO-Wikiの構成だと、ページ内の最初の見出しがほぼタイトル相当なので、最初の見出しをタイトルとして使うようにPukiWikiを改造しました。
そのため、わざわざ#titleで指定する必要はほとんどなくなりました。(#titleによる指定も引き続き可能です。)
2015/01/20(火)ECO-Wiki画像リサイズ
ECO-Wiki画像リサイズ
こちらの記事(ECO-Wikiでの画像縮小・拡大)でふれていた、ブラウザ側でリサイズされていた画像について、一部*1をリサイズ済みの画像と差し替えました。元画像は、サフィックス _big を付けたファイル名にリネームして残してあります。
- 例
ECO-Wiki上の画像サイズ指定について
画像差し替えの際に、画像の実サイズと表示サイズを一通りチェックしたのですが、想像していた以上にいい加減でした^^;
例としては、
- 実サイズ:177x111 → 表示サイズ:100x100
- 縦横比が合っていない
- 実サイズ:128x128 → 表示サイズ:127x127
- 周りの画像は表示サイズ128x128に統一しているのに何故か1ピクセルだけ縮小
- 実サイズ:128x123 → 表示サイズ:123x128
- 縦と横が逆
単純ミスのものもあるでしょうし、既存の記述をコピーして修正したときに画像サイズ指定をそのままにしてしまったという可能性もありそうです。不特定の人が編集する場合は、画像サイズ指定は省略した方が無難なのかもしれないですね*2。
画像アップローダーは実サイズを指定した&ref記述を生成するので、これをそのまま使ってくれる分には問題はなさそうですが。
「アンケートページ:今後の ECO wiki について」のコメント
最近、「アンケートページ:今後の ECO wiki について」をチェックしていなかったので気づくのが遅れましたが、
装備品データベース等を面倒ではあるが独立したWikiとしての公開をするべきと思う
acroniaでは別のサイトに飛ぶが検索する閲覧者に酔ってみれば使い勝手が良い物とは言えない
というコメントが付いてますね。
ただ、このコメントの意図がよく分からないです。
- 「検索」がWikiの検索機能を指す場合
- 独立したWikiでは検索は結局別々なので解決にならない。
- 今のECO-Wikiに含めるなら検索はできますが、ECO-Wikiが肥大化しかねない。
- 「検索」がGoogle等の検索を指す場合
- データベースが検索にかかるようにすることを考えるべき。*3
あと、データベースにしておかないと、細かな条件を付けた検索や、データの機械的な再利用が困難になるので、よほどの事が無ければデータベース化が望ましいと思います。
・・・というか、Wiki管理だと数が多すぎて破綻しそう^^;*4
2015/01/08(木)圧縮転送による読込時間改善、他
圧縮転送による読込時間改善
以前、ECO-Wiki (acronia) でページ生成時間を表示するようにしましたが、内容が多いページではかなり時間がかかっているのが気になりました。
例えば、Iris/Explanationでは
HTML convert time: 0.007 sec. (total: 2.447 sec.)
と数秒かかり、実際に体感できるロード時間も同程度です。
これは、Iris/Explanationだとページ(HTML)サイズが約700kBとちょっとした画像並みに大きいため、単純に転送に時間がかかっていると思われます。
そこで、転送データをgzip圧縮して転送量を削減してみることにしました。さくらのレンタルサーバーは半年くらい前からmod_deflateが使えるようになったらしいので、以下の記述*1を .htaccess に追記します。
<FilesMatch "\.php$"> SetOutputFilter DEFLATE BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html AddOutputFilterByType DEFLATE text/html </FilesMatch>