PukiWiki UTF-8版の新規インストール設定と文字化け対策のメモ

以下の情報は、2010年3月時点での情報です。

PukiWikiは1.4.7のUTF-8版を、PHPは5.2.8、サーバは、CPIの共有サーバZ-1での挙動を前提に書いています。

PukiWikiのクリーンインストールを前提にしています。EUC-JPからのアップデートについては一切考慮していません。

他のバージョン、他のサーバ会社では、同じ設定をしても動かないかもしれません。

2010/03/24追記:
本ページへの記載内容については、PukiWiki公式ページに随意に引用・転載(当然、文言の改変もOK)してくださって構いません。> 誰か親切な人。


もくじ


■0:PukiWikiを文学研究用の本文DBとして使うと便利だよね。

というのがPukiWikiを入れてみようかな、と考えた発端です。

階層構造で管理できるから、

古今集/巻01/
古今集/巻02/

古今集/巻20/

とか、

白氏文集/巻01/
白氏文集/巻02/

とかできるでしょう。

Unicode版を使えば、中国語の小難しい漢字もちゃんと表現できるし…。

昔は、自分でUIを設計して、PerlのCGIでゴリゴリ書かなければ実現できなかったことが、既に存在するパッケージを入れるだけでOK、というわけです。

なんだかんだ言っても、ユニコードの普及って便利ですね…。

実はそれ以前に、UTF-8対応をいち早くしていた、Seiji ZenitaniさんのMacWikiを使わせて貰っていて、それを一部改造して漢字の同一視検索も実現していた(でも、コード紛失しちゃった)のですが、自分でメンテナみたいなことはできないよなぁ、と。

先ほど確認したら、MacWikiのページでは、かつて配布されていた「MacWikiそのもの」の配布はやっていないようですね。ここでも今はCarbon Emacs Packageがメインみたいです。

ま、それはそれとして、wikiシステムは簡易DBには最良のツールだと思えます。検索語に色が付くので、結果もとても見やすいし。

検索で正規表現を使いたい場合は、まだ色々工夫をしなければダメかもですが、ひょっとして、既にプラグインがあるかもしれません(未調査)。

あと、欲を言えば、特定の階層を複数指定して、そこだけを検索できると便利なんですが…これもひょっとして、既にプラグインがあるかもしれませんね(未調査)。

以下、CPIのレンタルサーバ(Z-1サーバ)での、あくまでも自分用の設定メモです。

他の会社のサーバでは、設定方法が異なるかもしれません。

[もど凛子]


■1:ディレクトリ構成概念図

以下のような感じで作る、という前提で話を進めます。

./ftp/ ←今回は直接には関係ない。
./html/ ←初期状態で存在する。
./html/cgi-bin/ ←今回は直接には関係ない。
./html/pw/ ←初期状態では存在しない。後で、作成する。
./secure/ ←初期状態では存在しない。後で、作成する。

[もど凛子]


■2:解凍

"pukiwiki-1.4.7_notb_utf8.zip"/root/html/pw/に解凍する。

設定ファイルの中で最も基本的な定義は"pukiwiki.ini.php"の中で行うんだけど、さしあたりは動作確認だけなので、何もいじらない方針で行きましょう。

[もど凛子]


■3:サーバに対するphpの使用宣言

解凍されたファイル群の中で、./html/pw/.htaccessについては、一行目に

# ▼.htaccess開始 -----------------------------------
AddHandler x-httpd-php528 .php
# ▲.htaccess終了 -----------------------------------

とだけ書き、UTF-8のBOMナシ、改行はLFのみで保存する。

エディタはEmEditor(製品版のEmEditor Professionalを強く推奨しますが、Free版でも良い)や、秀丸、フリーソフトならMadEditなどがお勧め。

上の記述の内、528とはレンタルサーバで使用許可されているPHPのバージョンが複数ある場合に、特定バージョンを決め打ちする指定。

上のように、phpのバージョン番号を明示的に指定しないで、

# ▼.htaccess開始 -----------------------------------
addhandler x-httpd-php .html
# ▲.htaccess終了 -----------------------------------

とした場合は、サーバに入ってる最新版が優先割り当てされる模様。

レンタルサーバによっては以下のように二行書かないとだめな場合もあるらしい(ファーストサーバとか?)。

なお、CPIではAddTypeの指定は無効みたい。

# ▼.htaccess開始 -----------------------------------
AddHandler x-httpd-php .html
AddType application/x-httpd-php .php
# ▲.htaccess終了 -----------------------------------

その他、サーバによっては、CGIとして動かす場合と、そうでない場合とで設定が違うとか、色々あるようですが、よく調べていません。

[もど凛子]


■4:ファイルのUP

./html/pw/以下のzipファイル以外を「バイナリモードで」UPする。

テキストファイル類もUTF8Nなので、ASCIIで送ってはダメです。

但し、".htaccess"については、各サブフォルダの".htaccess"も含めて、一個ずつサーバ上から削除し、再度ASCIIで送り直しする。

".htaccess"のパーミッションは644か604に設定。(個人的には604がセキュリティきつめで良いのではないかと…。)

基本的に、パーミッションは、PHPファイルの場合は604か644。

PHPファイルが含まれるディレクトリは705か755。

[もど凛子]


■5:閲覧動作試験

http://www.自分のWEBのアドレス/pw/index.php

にアクセスしてみる。

これで動いているようであれば、ひとまず成功。よかったね。

なお、《一部分が》文字化けして「◆◆◆◆」に見えたりするのは、後でフォローするので気にせず進んでよろしい。

そうでなく、あっちもこっちも壊滅的に文字化けする場合や、何にも表示できない場合や500エラーなどが出る場合は、問題です。

最初の段階で何かが間違っているから、やり直す。

多くの場合は保存時の文字コードと改行、送信時のBINARYモード/ASCIIモードの違い、ファイルやフォルダのパーミッションでしょう。

特に、pukiwikiで「あれ?」っと思ったのは、改行が「CR+LF」ではなく、「LFのみ」となっている所ですね。

10年前のPerlでCGIの時代では、この辺はあんまりキッチリしていなかったように思います。注意しましょう。

なお、個別に質問されても私は一々返事できません。

ここに掲げている情報は、あくまでも「私の経験の範囲内での情報」に過ぎませんし、自分用のメモに過ぎません。

PukiWikiの公式ページで相談して下さい。

[もど凛子]


■6:管理者パスワードの作成

URIの最後に「?cmd=md5」を付けたページ

http://www.自分のWEBのアドレス/pw/index.php?cmd=md5

を開き、管理者用のパスワード文字列を入力。

できあがったパスワードを、"pukiwiki.ini.php"$adminpass の所に記述。Sample:と書かれている所を参考に、''で括るようにしましょう。

細かいことは http://www.adminweb.jp/pukiwiki/install/index3.html 辺りを参照のこと。

[もど凛子]


■7:ついでに"pukiwiki.ini.php"の変更をする所

ページタイトルを変更。$page_titleに記述。日本語が入っても良い。

管理者情報を変更。$modifierに記述。日本語が入っても良い。

$modifierlinkに管理者のWebPageのトップアドレスを記述。

ここをwikiのトップにしても良いんだろうけど、そうでないページの方がグルグル回らないで良いような気がする。

例えば、

http://www.自分のWEBのアドレス/

などにして置くと良いのではないでしょうか。

[もど凛子]


■8:書き込み制限をする

更に"pukiwiki.ini.php"の内容を変更して、「閲覧は誰でも自由。但し、書き込みは特定のパスワードを知っている人だけ。」とする事にします。

いたずら防止のために、sandboxなどは初めから凍結処理されていますが、新規ページの作成は禁止されていません。

山のようなゴミ情報を新規ページとして作られたら、たまりません。

そこで、パスワード規制が必要なわけです。

しかし、パスワード規制をかけようとした途端に、いきなり設定が難しくなります。

まず、バージョンによって、方法に差がある。
それと、ある特定のバージョンでも複数のやり方が存在する。

という訳で、

の二つを読み比べろ、っていきなり言われるわけですね。

正規表現を知らない人が読んでも、ピンと来ない人でしょう。

この、いきなり難しくなる、という落差がタマランですね。

要するに上の2つのページに書かれている情報は、

と、いうわけです。

それを短い言葉で書かれているから余計にわからん。

今回は、「新規ページの作成は特定の人しかできないようにする」というだけの、一番単純なヤツで行くからね。

要するに、さっき作った「管理者パスワードの作成」とは別に、書き込みできる「ユーザ名」と書き込み用「パスワード」を作って、その両方を"pukiwiki.ini.php"に定義しないとダメだよ、ということだけ、理解できればよろしい。

閲覧は全員自由とするので

$read_auth = 0;

のままにしておく。

書き込みは要認証とするので、

$edit_auth = 1;

とし、更にその直後にある

$edit_auth_pages = array(

の所に、以下を書き足す。

なお、"writeuser"は任意のユーザ名。半角英数字がよろしい。

'/^.*$/' => 'writeuser', // 編集制限の対象ページ(正規表現) => 編集許可グループ名

で、このユーザ(writeuser)が、書き込むときのパスワード認証をせねばならないから、やはり先ほど使ったURIの最後に「?cmd=md5」を付けてページを開く方法、

http://www.自分のWEBのアドレス/pw/index.php?cmd=md5

へアクセスし、任意の言葉(半角英数字がよろしい)でパスワードの生成をする。

この「任意の言葉」は、さっき作った管理者用のパスワード文字列とは別のパスワードを作ること。

で、できあがったパスワードを、"pukiwiki.ini.php"の、$edit_auth_pagesよりもちょっと上にある$auth_usersの所に書き込む。

ここまでやったところで、"pukiwiki.ini.php"を保存し、アップロードする。

これで書き込み制限ができるはず。

試しにtestって名前のページを新規作成してみましょう。

ユーザ名とパスワードを入れないと書き込みできないようになりました。

あ、そうそう。ブラウザによっては、一度、ユーザ名とパスワードの認証が済んだら、それ以降も連続して新規ページが作れるから、ホントにちゃんと動いているか心配な場合アリ。

その時には、ブラウザのキャッシュを全部削除してからもう一度アクセスし直す。

ブラウザのキャッシュの削除方法については、自分で検索してくださいな。

因みに、テストとして作ったtestページの削除は、もう一度、そのtestページの「編集」に入って、内容を全部消して、「更新」をすれば削除されます。

[もど凛子]


■9:php.iniを変更して文字化け対策

ここまでで、どうやら一応は、動いているように見えるはずなんだけど、「検索」のメニューに「ファイル」って書き込んで検索すると、おかしなことになるのが判ると思います。

文字化けして、「◆◆◆◆」に見えたり、検索結果の本文中で「ファイル」が黄色に反転表示されなかったりするんだよね。

これは、UTF-8版を入れると結構頻繁に起きるようです。

公式ページでは「文字化け問題は、ちゃんと過去の質疑を検索しろ」と、キックされてしまうことが多く、みんな萎縮しちゃって、「質問することそのもの」がタブーぽい(?)扱いのような雰囲気を感じるんですが…。

そんなことないですかねぇ?

私も公式ページを色々と探しましたが、


と、まぁ、色々細切れの情報がワンサカ出てきて、頭グチャグチャになりました。

特に、BugTrackは、解決済みのものも残っているだろうから、「初めて」で「新規インストール」の人には却って混乱の元になるかもしれません。

投稿日を見極めないと…。

こういう時、問題を単純化するためには、何事も段階を踏んでカスタマイズして行くのが良いようです。

そうすれば「でもさ、基本設定しかしていない状態でも動かないんだもん。」って言えるわけです。

「何事も段階を踏んで。」って、最近、流行っているそうですねぇ。

ラブプラスとか。ラブプラスとか。ラブプラスとか。

この間、某女子学生から「先生はどっち派ですか?」って聞かれたけど、私は「リアル高校生時代に膝カックン、タッチイベントなど、一通りの事は済ませたので、別にどうでも良い。」というのが正直な感想です。 ハイ。

ということで、凛子ちゃんも愛花ちゃんも寧々ちゃんも放って置いて、"php.ini"をいじりましょう。

CPIがデフォルトで用意している"php.ini"は、EUC-JPを入出力の基本文字コードに寄せるように設定されているようなんですよね。

どうもこれは、CPIがデフォルトで用意しているKAKASIやChaSenが、EUC-JP版なので、恐らくは、それに合わせるためなんじゃないかなぁ…という気がしています。

KAKASIもChaSenも、今はUTF-8対応版があるので、辞書のコンパイルをUTF-8でやったものを提供してくれれば良いのですが、Namazuと連携して使っている既存顧客のために、CPIとしては、まだ、そういう気にはなっていないようですね。

Namazuはnkfと連携して処理しろ、というスタンスのようですから。

要するに、NamazuがUTF-8対応するか、Namazuの代替検索環境(Sennaを入れる気は無いのだろうか?)が整わない限り、CPIはEUC-JPを基本とし続けるであろう、ということになるような気がする。

ある意味、キラーソフトであり続けているわけですね。Namazuってば。すげー。

ただ、CPIは、地方公共団体の顧客も多いようですので、県庁や市役所のWebPageでは中国語(簡体字、繁体字)や朝鮮語(ハングル)などの表示や検索に対する需要も今後、更に増えてくるでしょう。

いつまでもEUC-JPで放置しきれるものでは無いだろうなぁ、という気がしています。

いずれにせよ、CPIがデフォルトで用意しているphp.iniを、自分の環境ではUTF-8を入出力の基本にしてね、と設定の上書きをしてやれば上手く行きます。

CPIのコントロールパネル(サーバーの)にログイン。

「お客様情報」→「プログラムのパスとサーバの情報」で、「PHP iniの設定情報」の情報欄を表示します。

(2010/03/08現在では、PHP 5.2.8が入っています。詳しいデータは http://www.cpi.ad.jp/function/php_info/phpinfo528.html 参照。)

PHP iniの設定情報」の情報欄を表示すると、"php.ini"の中身が全部表示されるので、これを全部エディタに貼り付け。

全て行の行頭に1バイトスペースが入るので、気になるようならそれを削除。

エディタの正規表現で置換する場合は「^\s」→「何もナシ」で一括削除できます。

それが済んだら、ファイル名"php.ini"として保存します。

一応、注意しておきますが、上の例ではファイル名は全部小文字にしてありますよ。

文字コードはS-JIS、改行はLFのみ。

1190行目くらいの所に、[mbstring]と書かれています。

それ以降の部分を、http://www.php.net/manual/ja/mbstring.configuration.php を参考にしながら、以下のような感じで(お好みな風に)に書き換えます。

; デフォルト言語を日本語に設定
mbstring.language = Japanese;

; 内部エンコーディングを UTF-8 に設定
mbstring.internal_encoding = UTF-8;

; デフォルトのHTTP入力文字エンコーディングを設定(順番)
mbstring.http_input = UTF-8,ASCII,EUC-JP

; デフォルトのHTTP出力文字エンコーディングを設定
mbstring.http_output = UTF-8

; HTTP入力エンコーディング変換を有効にする
mbstring.encoding_translation = On

; デフォルトの文字エンコーディング検出順序を設定(順番)
mbstring.detect_order = UTF-8,ASCII,EUC-JP

; 代替文字のデフォルト値を設定
mbstring.substitute_character = none;


まぁ、こんな所で良いようです。
なお、その他に、430行目くらいの所にある

;default_charset = "iso-8859-1"

についても、行頭のコメントアウトを削除し、

default_charset = "UTF-8"

と強制指定しても良いでしょう(私は設定しませんでしたが)。

なお、mbstring.substitute_characterについて補足しておくと、EUC-JPを優先にしている場合、EUC-JPで表現できない発音記号や中国語の文字列などについて、エンティティ表現で出力したいという需要があるでしょう。

サーバの都合でEUCでしかPHPを動かせない場合は、longに指定しても良いかもしれません。

「EUCで動いているのにハングル表示ができる」という風に動くんじゃないかと思います。

ただ、その場合、ソースコードのインジェクションでクラックされる危険性もありますし、また、エンティティ表現として保存された文書は、PukiWikiの文字列検索対象から外れてしまうのではないでしょうか…。

PukiWikiのコードを徹底的に読み込んで解析したわけではないので、よくわかりませんが…。

今回は、UTF-8ベースで保存するんですから、無効な文字は原理上、存在しないはずです。noneにしておくのが無難でしょう。

"php.ini"に対して以上の変更を加えたら、ftp領域のルート直下に"secure"とか"private"などの名称でフォルダを掘りましょう。

んで、そこにASCIIモードでUPします。なお、バイナリモードで送ってはいけません。パーミッションは644か604で良いでしょう。

以下では

./ftp/ ←今回は直接には関係ない。
./html/ ←初期状態で存在する。
./html/cgi-bin/ ←今回は直接には関係ない。
./html/pw/ ←初期状態では存在しない。後で、作成する。
./secure/ ←初期状態では存在しないので、自分で作成する。

という風になっていて、"secure"の中に"php.ini"を保存したことにします。

次に、この"php.ini"を、呼び出して使いますよ、という宣言をします。

これは、最初の方で、一行だけ追加した、/root/html/pw/に設置してある.htaccessに対して、更に編集を加えることで行います。

内容は以下の通り。(編集した部分の1行上のコメント欄に★を付けました。)

# ▼.htaccess開始 -----------------------------------
# ★シンボリックリンクON
Options +FollowSymLinks
# ★PHPハンドラ。バージョン指定する場合はスペースなしでその番号付き
AddHandler x-httpd-php528 .php
# 必要に応じて、上と入れ替えでONにする。CPIではAddTypeの指定は無効みたい。
# AddHandler x-httpd-php .html
# AddType application/x-httpd-php .php
# Apache .htaccess for PukiWiki
#
# $Id: .htaccess,v 1.14 2005/04/29 11:51:31 henoheno Exp $
# Copyright (C)
# 2002-2005 PukiWiki Developers Team
# 2001 Originally written by yu-ji
# License: GPL v2 or (at your option) any later version
#
# NOTE: Correct permission of this file 644(or 604)
# ★php.iniにパスを通す。ファイル名まで書かないこと。
# 「A1234567」部分は自分のCPIのユーザIDを書きます。
suPHP_ConfigPath /usr/home/A1234567/secure/
## Access control by Order/Allow/Deny directives
## needs 'AllowOverride Limit' at httpd.conf
# Prohibit direct access to .htaccess, .htpasswd or others
# (If it's not set by default)
# ★コメントを外して.ht~で始まるファイルの閲覧不許可指定をON。
<FilesMatch "^\.ht">
Order allow,deny
Deny from all
</FilesMatch>
# Prohibit direct access
# ★コメントを外してphpその他のファイルの直接閲覧不許可指定をON。
<FilesMatch "\.(ini\.php|lng\.php|txt|gz|tgz|zip)$">
Order allow,deny
Deny from all
</FilesMatch>
## Authentication to this directory with basic-auth
## needs 'AllowOverride AuthConfig' at httpd.conf
#AuthType Basic
#AuthName "Authentication required"
#AuthUserFile /path/to/.htpasswd
#AuthGroupFile /dev/null
#Require valid-user
## Using zlib.output_compression per directory (via .htaccess)
## needs 'AllowOverride Options' at httpd.conf
##
## NOTE:
## Define PKWK_ZLIB_LOADABLE_MODULE somewhere if you are using
## PHP extension as loadable module (especially FreeBSD ports)
## (See BugTrack/738 for detail)
#php_flag zlib.output_compression On
# ▲.htaccess終了 -----------------------------------

まぁ、こんな感じ。
保存の文字コードはS-JIS、改行はLFのみ。

"php.ini"を、./secure/のような、ブラウザ経由では絶対にアクセスできないような所へ設置するのは、セキュリティを高める効果があるためです。

ただ、契約しているサーバによっては、こういった所にFTPクライアント経由でもアクセスできないところがあるでしょう。

その場合は、"pukiwiki.ini.php"が置いてあるのと同じフォルダ、

./html/pw/

"php.ini"を設置しても良いでしょう。

たぶん、そのディレクトリの中だけで動きます。

少なくとも、CPIではそうなっています。但し、CPIの場合、下位ディレクトリに対しては効果は及ばないそうです。

そうすると、下位ディレクトリ全体に独自の"php.ini"ファイルを有効したい場合は、各ディレクトリに(同内容の)"php.ini"ファイルを1つずつ設置せねばなりません。

そんな面倒な…という場合、すぐに思いつくのは".htaccess"ファイル中で、phpの設定を指定する方法ですね?

普通は、".htaccess"ファイル中でphp_valuephp_flagを指定すれば、その設定部分だけを上書きして動いてくれるはずなのですが、CPIのサーバでは、この方法はできません。

".htaccess"ファイルにphp_valuephp_flagに関わる記述をした場合、500エラー(Internal Server Error)となってしまう(!)とのこと。

なんだか問答無用で500エラーを返すらしいです。試していませんが。

公式アナウンスは以下の辺り。

あと、は2007年3月1日で閉鎖されたらしいけど、以下も参照すると良い。

[もど凛子]


■10:php.iniを設置できないサーバの場合

【重要】以下は、私は、実際には試していません。【重要】

たぶん、これで動くんじゃないかな?というレベルの情報です。

あらかじめご了承下さい。

先述の通り、CPIではこの方法は採用できませんが、".htaccess"ファイル中でphp_valuephp_flagを指定する方法は以下の通りです。

その他の指定もまとめて書き出します。

なお、保存の文字コードはS-JIS、改行はLFのみ。

# ▼.htaccess開始 -----------------------------------
# ★シンボリックリンクON
Options +FollowSymLinks
# ★PHPハンドラ。バージョン指定する場合はスペースなしでその番号付き
AddHandler x-httpd-php528 .php
# 必要に応じて、上と入れ替えでONにする。CPIではAddTypeの指定は無効みたい。
# AddHandler x-httpd-php .html
# AddType application/x-httpd-php .php
# Apache .htaccess for PukiWiki
#
# $Id: .htaccess,v 1.14 2005/04/29 11:51:31 henoheno Exp $
# Copyright (C)
# 2002-2005 PukiWiki Developers Team
# 2001 Originally written by yu-ji
# License: GPL v2 or (at your option) any later version
#
# NOTE: Correct permission of this file 644(or 604)
# ★php.iniにパスを通す。ファイル名まで書かないこと。
# 「A1234567」部分は自分のCPIのユーザIDを書きます。
suPHP_ConfigPath /usr/home/A1234567/secure/
## Access control by Order/Allow/Deny directives
## needs 'AllowOverride Limit' at httpd.conf
# Prohibit direct access to .htaccess, .htpasswd or others
# (If it's not set by default)
# ★コメントを外して.ht~で始まるファイルの閲覧不許可指定をON。
<FilesMatch "^\.ht">
Order allow,deny
Deny from all
</FilesMatch>
# Prohibit direct access
# ★コメントを外してphpその他のファイルの直接閲覧不許可指定をON。
<FilesMatch "\.(ini\.php|lng\.php|txt|gz|tgz|zip)$">
Order allow,deny
Deny from all
</FilesMatch>
## Authentication to this directory with basic-auth
## needs 'AllowOverride AuthConfig' at httpd.conf
#AuthType Basic
#AuthName "Authentication required"
#AuthUserFile /path/to/.htpasswd
#AuthGroupFile /dev/null
#Require valid-user
## Using zlib.output_compression per directory (via .htaccess)
## needs 'AllowOverride Options' at httpd.conf
##
## NOTE:
## Define PKWK_ZLIB_LOADABLE_MODULE somewhere if you are using
## PHP extension as loadable module (especially FreeBSD ports)
## (See BugTrack/738 for detail)
#php_flag zlib.output_compression On
# 以下は、PHP5の場合 ======================================
# On/Offで指定するものはphp_flag、文字列で指定する場合はphp_valueを使う。
# デフォルト言語を日本語に設定
php_value mbstring.language = Japanese
# 内部エンコーディングを UTF-8 に設定
php_value mbstring.internal_encoding = UTF-8
# デフォルトのHTTP入力文字エンコーディングを設定(順番)
php_value mbstring.http_input = UTF-8,ASCII,EUC-JP
# デフォルトのHTTP出力文字エンコーディングを設定
php_value mbstring.http_output = UTF-8
# HTTP入力エンコーディング変換を有効にする
php_flag mbstring.encoding_translation = On
# デフォルトの文字エンコーディング検出順序を設定(順番)
php_value mbstring.detect_order = UTF-8,ASCII,EUC-JP
# 代替文字のデフォルト値を設定
php_value mbstring.substitute_character = none;
# ▲.htaccess終了 -----------------------------------


ここまでの記述で参考にさせて頂いた主な情報源

特に、DESIGN Oilさんの情報が無ければ、解決にもっと時間がかかっただろうと思う。本当に感謝。


[もど凛子]

■11.出力されたXHTMLのコードが変な件

一つ目。

出力されたxhtmlの中で、

<link rel="SHORTCUT ICON" href="" />

と、hrefの中身がemptyなのは、何じゃこりゃ。

どこをいじれば良いかを探してみると、

http://pukiwiki.sourceforge.jp/?%E8%B3%AA%E5%95%8F%E7%AE%B13%2F110

に答えがあった。

pukiwiki.skin.phpの中で16行目辺り。

$_IMAGE['skin']['favicon'] = ''; // Sample: 'image/favicon.ico';

の部分を、favicon.icoというファイル名でimageフォルダに保存する場合は、

$_IMAGE['skin']['favicon'] = 'image/favicon.ico'; // Sample: 'image/favicon.ico';

のように書き換える。

PukiWikiが入っているパスをルートとして呼び出すらしい。

gif画像などからのfavicon.icoの生成については、以下などを参照。

http://www.ideaxidea.com/archives/2008/02/faviconico.html

っていうか、「favicon 作成」とかで検索するよろし。

二つ目。

同じく、出力されたxhtmlの中で、

Site admin: <a href="http://www.foobar.com">foobar</a><p />

の最後に存在する<p />が、なんだか気持ち悪い。

http://pukiwiki.sourceforge.jp/?%E8%B3%AA%E5%95%8F%E7%AE%B14%2F241

の議論によると、「規格上は適合しているから却下」という結論みたいだけど。

「なんだか気持ち悪い。」感は残る。

あと、「どうして<p />が存在しなければならないか?」がよくわからん。

議論をたどって行くと、どうも整形目的で入れているようですが…。

pukiwiki.skin.php の282行目付近を、

</a><p />

から

</a><p>&nbsp;</p>

に書き換えておけば、さしあたりは気持ち悪さからは逃れられる。
 

[もど凛子]


■12.ソースコードで気になった所

pukiwiki.skin.phpの50行目くらいの所に

// Decide charset for CSS
$css_charset = 'iso-8859-1';
switch(UI_LANG){
/* this @charset is for Mozilla's bug */
case 'ja': $css_charset = 'Shift_JIS'; break;
}

とある。EUC-JP版ではなく、UTF-8版でもこのようになっている。なんだか変なので以下のようにして置いた。

// Decide charset for CSS
$css_charset = 'iso-8859-1';
switch(UI_LANG){
/* this @charset is for Mozilla's bug */
// case 'ja': $css_charset = 'Shift_JIS'; break;
case 'ja': $css_charset = 'utf-8'; break;
}

上記の設定でも、今のところはおかしな挙動はしていない(が、あれこれいじるとワケわかんなくなるので戻した)。

pukiwiki.css.phpでは20行目辺りに

// Default charset
$charset = isset($_GET['charset']) ? $_GET['charset'] : '';
switch ($charset) {
case 'Shift_JIS': break; /* this @charset is for Mozilla's bug */
default: $charset ='iso-8859-1';
}

とあるので、Mozillaのバグ対策らしい。古いMozillaのものだろうか?

CSS部分の先頭には

@charset "utf-8";

とか、

@charset "shift-jis";

とかの記述は無いようだ。

なお、tdiary.skin.phpでも550行目辺りに

// Decide charset for CSS
$css_charset = 'iso-8859-1';
switch(UI_LANG){
case 'ja': $css_charset = 'Shift_JIS'; break;
}

とあって、

tdiary.css.phpでは20行目辺りに

// Default charset
$charset = isset($_GET['charset']) ? $_GET['charset'] : '';
switch ($charset) {
case 'Shift_JIS': break; /* this @charset is for Mozilla's bug */
default: $charset ='iso-8859-1';
}

とあったが、こちらは放置した。

UTF-8版では、これらのコード指定はiso-8859-1の記述をやめてしまって、case処理もコメントアウトし、全部utf-8をdefaultにしてしまうのが綺麗かもしれないですね。

[もど凛子]


■13.パスワードを忘れてしまった場合

凍結解除用パスワード凍結用パスワード管理者パスワード"pukiwiki.ini.php"ファイル中の$adminpassでの設定。

書き込みユーザのパスワード"pukiwiki.ini.php"ファイル中の$auth_usersの所での設定。

これらのパスワードを忘れた場合は、復号はほとんど不可能だから、"pukiwiki.ini.php"へのパスワードを設定し直す。

簡単に復号できるんだったら、暗号化パスワード生成の意味がないもんね。

[もど凛子]


■14.画面左のメニューをいじる

  1. 画面左のメニューを設定する。
    MenuBar」という名前のページをwiki記法に従って作る。
  1. メインメニューから下の階層へ入ったら、その階層ごとのメニューを表示させる。

    プラグイン(plugin/)の中にある、menu.inc.phpの

    // サブメニューを使用する
    define('MENU_ENABLE_SUBMENU', FALSE);

    TRUEに変更してアップロードする。

    この作業以降、メインメニューから下の階層へ入り、その階層内に、それぞれ「MenuBar」という名前のページをwiki記法に従って作る。
  1. MenuBarの幅を変更する。

    skin/pukiwiki.css.php の350行目あたりにあるMenuBar のテーブルのスタイル定義

    td.menubar {
    <?php if ($media == 'print') { ?>
    display:none;
    <?php } else { ?>
    width:9em;
    vertical-align:top;
    <?php } ?>
    }

    div#menubar {
    <?php if ($media == 'print') { ?>
    display:none;
    <?php } else { ?>
    width:9em;
    padding:0px;
    margin:4px;
    word-break:break-all;
    font-size:90%;
    overflow:hidden;
    <?php } ?>
    }

    にある2つのwidthの値を変更する。なお、9emは9文字を基準とする指定である。

[もど凛子]


■15.PukiWikiでWYSIWYG編集したい

PukiWikiについて色々と検索していると、ほとんど、設置しただけでその後の更新が無いページが結構あることに気づく。
実際、MenuBarにちょっと書き込もうとしただけで、Wiki記法にイライラしてしまう。
きっと、みなさん、そうだったんですね。

下手にHTMLをいじれるから、「便利で、見た目も綺麗に書ける方法が、自分にはそれしかない。」という状態に自分を置けないのだ。
従って、Wiki記法が手に馴染むまで腰を据えて書き続けるような根性が出てこない。
先ほど、Movable TypeなBlogにちょっと書き込んだら、なんでWikiはWYSIWYGじゃないのだ? と疑問に思った。

で、早速調べてみたら、ありましたよ。ドンピシャなヤツが。
ここ→http://orima.jp/blog/archives/2009/0509021915.htmlにあった修正方法などの紹介に助けられつつ、試してみて、動くようになった。

guieditプラグイン(プラグイン/GUI編集)は、EUC版PukiWikiを前提に設計されているようだったので、以下、「UTF-8版PukiWikiで運用する場合」のメモ。

guieditのphpファイルは、すべてUTF-8で保存し直す。
具体的には

guiedit.inc.php

と、skin/guieditディレクトリの.phpファイル4個

editorarea.css.php
xhtml2wiki.php
wiki2xhtml.php
guiedit.ini.php

以上、合計で5個である。
guieditのパッケージ内にある.cssや.jsファイルはいずれもUTF-8もしくはASCIIで保存されていたので変更不要。

また、guiedit.inc.phpの190行目辺りに

// 文字コードを UTF-8 に変換
$postdata = mb_convert_encoding($postdata, 'UTF-8', SOURCE_ENCODING);

とあるが、UTF-8ベースで動かしているのだから、不要である。
php.ini の設定によっては二重にエンコードされてしまうような気もするので、

// 文字コードを UTF-8 に変換
// $postdata = mb_convert_encoding($postdata, 'UTF-8', SOURCE_ENCODING);

のようにコメントアウトした。
これで、今のところは、異常はない(正常に動いている)ようだ。

FCKeditorについては指示されたとおりにUPする。
UPするファイルとして"editor"ディレクトリの他に、"fckeditor.js"と"fckconfig.js"の2つだけが指示されているが、".xml"ファイルもUPする必要があるようだ(実際に動かしてみて、エラーが出たので気づいた)。

PukiWikiオリジナルのファイルについては、基本的には指示されている通りに編集すればよいのだが、最終的にオリジナルファイルのうち、何個のファイルを差し替えればよいのかが、わかりづらい。

PukiWikiルートの2個
ja.lng.php
pukiwiki.ini.php

skinディレクトリの1個
skin/pukiwiki.skin.php

libディレクトリの2個
lib/convert_html.php
lib/html.php

合計で5個のPukiWikiオリジナルファイルを編集して上書きでUPする。

※なお、「基本的には」の例外は、「pukiwiki.ini.php で $fixed_heading_anchor と $fixed_heading_anchor_edit を 1 にする。」と指示されている部分で、実際には「$fixed_heading_anchor_edit」は最初から存在しないので、「追記する」

[もど凛子]


■16.searchで&baseを使うと◆に文字化けしてしまう

PukiWiki1.4.7のUTF-8版をphp5で試しているわけですが、「?cmd=search」から、検索BOXに「ぷ」と入れて全文書の検索を行った場合は正常に表示されます。
また、ページ内に「#search(ぷ)」で設置した場合にも正常に結果が表示されます。

ところがForefox 3.6のアドレス欄(ロケーションバー)に「?cmd=search&base=ぷ」と入れてEnterでは、アドレス欄が「?cmd=search&base=%82%D5」に遷移します。

画面出力が

 <label for="_p_search_base_id_1"><strong>◆◆</strong> から始まるページを検索</label>

となります。
文字化けした◆◆のコードは、両方ともU+FFFDでした。
その他の文字列でも、U+FFFDに丸め処理されているような印象です。

あれま…。

で、search.inc.phpの中を色々見たけどわからん。

よくよく考えてみたら、「%82%D5」の時点で2バイトじゃんか。
%E3%81%B7」ではないから、「ぷ」にデコードできないのは当然なのであった…。

Forefoxの側の問題のようです。
結局、about:confignetwork.standard-url.encode-query-utf8 の値を true に変更して解決。
他のブラウザでの挙動は試験していないので、わからん。

因みに、特定階層以下だけの検索を(できるだけ標準機能だけで)実現したいなぁ、と、&baseでの検索を試してみたが、これはディレクトリ中の文字列のどこかに一致すれば良いわけではなく、あくまでも単独のページ名の先頭からの一致のようである。
文書を作る前に、文書名に規則性を持たせる設計をし、かつ、ある程度ページ名が長くなってしまうのは諦めなさい、ということになる。

[もど凛子]


 

おしまい。

copyright 2010~ 谷本玲大
http://www.tanimoto.to/