2015/02/05(木)ECO-Wiki (acronia)のfavicon
ECO-Wiki (acronia)のfavicon
今置いてあるfaviconは、ECO-Wiki(gamedb)のをとりあえずそのまま使っていますが、
- ECO-Wiki(gamedb)が復活したので同じだとちょっと紛らわしい
- 高解像度のfaviconも準備しておきたい
などの理由で新しいfaviconを置きたいと思っています。
そこで、とりあえずプルル・アルマのSSから作ってみたのですが、どうも16×16の画像が微妙な感じ・・・。まあこの大きさだと、どこかで妥協は必要だと思いますが。
- 案1: - ※16x16はこっちが良さそう?
- 案2: - -
- 案3: - - ※高解像度用(16x16は参考)
あとは、題材はこのままプルル・アルマにするのかという問題もありますね。(結構作るのに時間かかったので、私としてはもうこのままでいいかな、という気分になっちゃってますが^^;)
2015/02/03(火)bodycache patch 2重include対応
pukiwiki bodycache patch 2重include対応
以前、#includeを含んだページで更新時にキャッシュが再生成されるような改良を行いましたが、この改良では上図のように#includeや#pcommentが2重に使われていると、キャッシュが正しく再生成されないことが分かりました。
このような場合、一番深いページを更新したときに、最上位のページのキャッシュが再生成されずに残ってしまいます。これは、キャッシュを再生成するページを探すときに、#includeや#pcommentを更新されたページから1段しかたどっていないために発生する現象です。
そこで、更新時に2段までページをたどってキャッシュを再生成するように変更しました。これで、2重include/pcommentまでなら正しくキャッシュが再生成されるようになります。
ただし、3重include/pcommentには未対応です。対応は難しくありませんが、たどる段数を増やすとその分負荷も増えるので、2重までの対応としています。
2015/02/03(火)見出しタイトル化のバグと続・PukiWiki bodycache patch副作用:id重複
見出しタイトル化のバグ
タイトルプラグイン(PukiWiki)導入に合わせて、最初に出現したレベル1見出しをタイトル扱いにする改造を行いましたが、バグがあったようです。(季節イベントページをみていて気づきました。)
- 発生条件: includeプラグインが使われており、includeで参照しているページにレベル1見出しが含まれている
- 現象: レベル1見出しが含まれる最後のincludeがタイトルとして使われてしまう。
- 原因: includeを使うとconvert_htmlが複数回呼ばれることを考慮していなかった。その結果、後で呼び出されたconvert_htmlにより見出しから抽出したタイトルが上書きされていた。
- 修正前: Heading->Heading() 内の改造箇所
if( $this->level === 1 && !isset( $root->title ) ){ $root->title = preg_replace('|\s*\[.*|', '', $text); $root->title = preg_replace('|^\*\s*|', '', $root->title); }
- 修正後: Heading->Heading() 内の改造箇所
//初回呼び出し時は $root->id は 1 if( $this->level === 1 && !isset( $root->title ) && $root->id === 1 ){ $root->title = preg_replace('|\s*\[.*|', '', $text); $root->title = preg_replace('|^\*\s*|', '', $root->title); }
また、includeプラグインの参照先ページにtitleプラグインが含まれている場合も、同様にincludeしたページのタイトルが優先されてしまうと思われます。ただ、このような使い方はたぶんしないと思うので、こちらの問題はそのままにしておこうかと思います。
続・PukiWiki bodycache patch副作用:id重複
PukiWiki bodycache patch副作用:id重複で適用した修正ですが、不十分だったようです^^;
原因は、やはりconvert_htmlが複数回呼ばれることを考慮していなかったことで、
function convert_html($lines) { //省略 static $contents_id = 0; global $bodycache_status; if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み ++$contents_id; } //省略 $body = & new Body(++$contents_id); //省略 }
この修正では、includeによる2回目のconvert_html出力と、メニューバーの$contents_idが共に2になってid重複してしまいます。
ものすごく場当たり的ですが、以下のように再修正しました。
if ( $bodycache_status === 'cached' ) { //bodycacheから取得済み $contents_id += 90 ; //これだけ足せばきっと重複しない・・・(^_^;) }
いっそ、メニューバーでは見出しの自動id生成をやめた方が良い気もしてきましたが、メニューバーだけ自動id生成をやめる方が修正は面倒そうです。(もしかしたら、本文も自動id要らないかも?)
2015/01/25(日)PukiWiki UTF8版とEUC-JP版
PukiWiki UTF-8版とEUC-JP版
今の ECO-Wiki (acronia) はEUC-JP版
PukiWikiにはUTF-8版とEUC-JP版がありますが、現在はEUC-JP版を採用しています。理由としては、
- 元のECO-WikiがEUC-JPだった
- UTF-8版にすると転送量が増える
- UTF-8版にするとPukiWikiが内部的に使用するファイル名が長くなる
- UTF-8版にするとURLが長くなる(けど、そんなに大した問題ではないかな)
- UTF-8はあまりおすすめしないような記述があった*1
などです。
UTF-8版にするべきか
ただ、最近はUTF-8版にした方が良いかなと考え始めてます。
- 最近の文字コード事情はUTF-8が主流
- PukiWiki公式でもUTF-8推奨になった(PukiWiki開発日記、PukiWiki 1.5.0ダウンロード)
- 転送量は圧縮が効いていればそんなに問題ないかも
とはいえ、EUC-JPで困っているというわけでもないのでUTF-8版に置き換えるかどうかはちょっと悩ましいところです。
UTF-8版にするなら、PukiWiki 1.5.1のリリースに合わせることになるでしょうか。
UTF-8版にする場合の課題
- ファイルなどを全部UTF-8に変換する必要がある
- 変換スクリプトが作られているようなので、これで変換を試みることになりそうです。
- (英数字以外をページ名に含む)各ページのURLが変わってしまう
- 検索エンジンなどからのリンクが切れてしまうので、存在しないページにアクセスされたら、EUC-JP版URLへのアクセスと解釈して301 Moved Permanentlyで新URLに転送するような仕組みを入れたいところです。
- と思って探してみたら、同じ事をやってた人がいました→PukiwikiをEUC→UTF-8移行した後もEUCのURLでアクセスできるようにする - あっきぃ日誌
- 検索エンジンなどからのリンクが切れてしまうので、存在しないページにアクセスされたら、EUC-JP版URLへのアクセスと解釈して301 Moved Permanentlyで新URLに転送するような仕組みを入れたいところです。
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を公開しました。