先日来より、以前からバージョンアップをしたかったPukiWiki用レスポンシブデザイン対応サイト内検索プラグインの仕様策定（調査含む）と、バージョンアップ開発をしている。
ある程度開発にメドはついたものの、テストと仕様（プログラム）の調整を含めるともう少し時間がかかりそうだなぁと思っていたら、本サイトで公開している記事やプラグイン等に関してメールが来ていた。
実は書きたい記事もあるし、内容的に後々暫定公開で運用しているPukiWiki改造普及活用計画のコンテンツにしようと思っていたのだが、軽く本サイトで記事にしようと思った。
これからPukiWikiでサイトを構築しようとしている人にとっても有益だし、本サイトやＱ＆Ａ掲示板での問い合わせも減少するだろうと思うからだ。
※2021/06/12追記
ファンビジネスとオンラインサロンを独自に再構築して運用を開始したため、その部分の記述を修正している。
PukiWikiの設定をちゃんと説明していなかった？
冒頭で述べた通り、いただいたメールは次の通りだ。
差出人の名前とそのメールアドレスからも分かるように、一方的ではあるものの、当方への謝意と改善点を教えていただいた。
しかし、「はて？PKWKEXP_DISABLE_MULTILINE_PLUGIN_HACKについて、今まで何も書いていなかったっけか？」と思ったので調べてみたのだが、「PukiWiki1.5.2にスパム対策メールフォームを設置！Googleアドセンスに備える！」記事（「メールフォームの設置」の章）でわずかに説明しているだけだった。
「PukiWiki1.5.2をインストールして初期設定をする！」記事も確認してみたが、PukiWikiのインストールとパーミッション、管理者パスワードと編集設定、ページタイトルと管理者情報の修正といった、最低限の説明しかしていない。
なぜかと言えば、PukiWikiでサイトを構築して運営していれば、常識的なことだからだ。
このメールをくれた人は自分で何とかするスキルを持っていたようだが、実はこの内容に関してはＱ＆Ａ掲示板に答えがある。
上記Ｑ＆Ａ掲示板の「ソートテーブルプラグインについて — しろ 2021/02/03 (水) 15:05:11」スレッドで、私がレスで回答している内容がソレだ。
Ｑ＆Ａ掲示板での質問や、本サイトのお問い合わせページでもそうだが、質問者がPukiWikiにどんな設定をしているのか、質問者がどの程度のスキルなのか、こちらとしては一切分からない。
その上で「どうやったら相手に自分の質問内容とその意図が伝わるのか」を考えて文章にしなければ、当然ながら第三者（と私）には質問内容とその意図は伝わり切れない。
お問い合わせページからのメールや、TwitterのDMでの問い合わせは全部「FAQにしたいのでＱ＆Ａ掲示板にお願いします」としか返答はしないし、Ｑ＆Ａ掲示板に投稿してもDiscordに投げてくれなければ、私は投稿を見ることはほぼない。
そして、Ｑ＆Ａ掲示板の投稿内容の意味がちょっと考えて分からなければ放置する（時間がある時にレスで返答する）しかない。私としてもこれらの対応はボランティアでしかないからだ。
仮にＱ＆Ａ掲示板で私がレスし、質問者の問題や疑問が解決したとしても、その内容を質問者が投稿してくれなければ、同じ様な問題や疑問がある他の人の役には立たない。
PukiWikiはOSSで無料かつ自由に使えるし、本体その他を改変することも可能ではあるが、それはすべて自己責任であるから、OSSを使うには相互扶助での「助け合い」が必須となる。
そうでなければ、時間をかけて自分で調べて勉強するか、私のようなSEやプログラマといった専門家に安くない金額を支払い、対応してもらうしかないのである。
こういったことも、私からしたら至極当然で常識的なことなのだが、IT系エンジニアの人以外には常識ではないようだ。
ともあれ、PukiWiki独特のクセのある設定について、まとめて詳しく解説している記事がネットにはないようだから、思い付くままに書いてみよう。
PukiWiki独特の設定
PukiWikiが導入されているサーバのルートドキュメントにある pukiwiki.ini.php の設定について解説する。
1. プラグインのマルチライン引数を有効にする
PukiWiki1.4.6以降でサポートされたマルチライン引数形式で、プラグインの設定を行う場合は、次の設定にする必要がある。
define(‘PKWKEXP_DISABLE_MULTILINE_PLUGIN_HACK’, 0); // 1 = Disabled
本サイト（オンラインサロンの会員限定公開も含む）やGitHubでダウンロード可能にしているプラグインを利用する場合、
これらのプラグインを利用するには必須の設定となる。
2. WikiNameを無効にする
PukiWikiでは、大文字小文字を混ぜた英字文字列（例：「PukiWiki」や「WikiName」）のことを「WikiName」と呼び、ページ内で記述すると自動でページのリンクとなる。
例えば、「PukiWiki」や「WikiName」といったページ名が存在すればそのページ名のリンクとして有効だが、当該ページが存在しない場合は「PukiWiki?」や「WikiName?」といった、ページが存在しないリンクとして「?」が付加される。
この機能を無効にしたい場合は、次の設定をすれば良い。
$nowikiname = 1;
3. 編集画面での改行を有効にする
PukiWikiの謎仕様のひとつに、「行末に~（チルダ）を入れて改行」がある。
一般的なブログやWordPress等でも、編集画面での改行はページにそのまま反映されるのが普通だが、PukiWikiの標準仕様だと行末に「~（チルダ）」を入れないと改行が反映されない。
例えば、PukiWikiのページ編集画面で次の3行を入力したとする。
1行目
2行目
3行目
ページを保存すると、
1行目2行目3行目
このように表示されてしまうのだ。
ゆえに、標準仕様の場合はページの編集画面で
1行目~
2行目~
3行目~
と入力する必要がある。
こんなアフォ仕様を解除したい場合は、次の設定をする必要がある。
$line_break = 1;
PukiWiki特有の仕様として、行頭と行末に意味を持たせている。
行頭での主な意味としては、
- * 見出し
- – 番号なしリスト
- + 番号付きリスト
- ~ 段落
- | 表（テーブル）
上記のモノがあるが、行頭が「//」だとコメント行になったりと、行頭での意味は重要だし、知らないとPukiWikiでページが書けない（詳しくは、PukiWikiの「FormattingRules」（テキスト整形のルール）ページを参照のこと）。
ちなみに、行頭の「~（チルダ）」は段落（HTMLでの<p>タグ）を意味するが、これが行末になると改行（HTMLでの<br>タグ）の意味となるのだ。
4. ページ編集時の「QUERY STRING TOO LONG」エラー回避
サイトに未ログイン時に（ログインしてからタイムアウトした場合も含む）、既存ページを編集しようとしてログイン画面に遷移し、ログインしたのに「QUERY STRING TOO LONG」とエラー表示されて (・д・)ﾁｯ と思ったことはないだろうか。
本サイトとGitHubでは、PukiWiki標準で用意されていない「ログイン」と「ログアウト」アイコンを含むPukiWiki操作アイコン（WebP版含む）をフリー素材として公開し、「PukiWikiにGoogleアドセンスとPukiWiki操作アイコンを導入する！」記事も公開しているから、明らかにログアウトしていたり、ログインしていないのであれば、ログインしてからページの編集をするべきだろう。
とは言え、意図せずログアウト状態でページを編集してしまわないことがないワケではないし、いちいち「QUERY STRING TOO LONG」で弾かれるのはイラッとする。
そこで、単純に「QUERY STRING TOO LONG」エラーを殺すには、次の設定をすれば良い。
define(‘PKWK_QUERY_STRING_MAX’, 0); // Bytes, 0 = OFF
PukiWikiの標準ユーザ認証はHTMLのGETメソッドを利用しているため、標準設定の場合だとページ名に日本語が使われている長いページ名の場合は、ページ名の長さによって「QUERY STRING TOO LONG」エラーで弾かれてしまう。
かと言って上記のように無効化してしまうと、ネットでのワーム攻撃に遭遇するとヤラレる可能性が無いとは言えない。
この辺は私が手を入れて開発しているPukiWiki用スパムフィルタライブラリをどう活用してサイトを防護するかにもよるし、同様に私が開発しているURL短縮ライブラリでどこまで対応するかにもよる。
とりあえずエラー回避のために無効化するのも手だし、標準設定の倍の値を設定する等、工夫するしかないのが現状だ（私が開発して対応するとしても、優先順位は低い）。
5. バックアップの設定
PukiWikiに限らず、Wikiシステムは複数人が同時にページを作成したり、編集したりすることが可能なように設計されており、極論を言えば認証なしで通りすがりのネット民がページを作成したり、編集することも可能だ。
ゆえに、PukiWikiではページの更新ごとにページのバックアップを最大512版まで残すことが可能になっており、変更点を画面で確認して元に戻すことが可能になっている。
この点がWordPressを含むブログシステムと大きく異る点で、Wikiシステムが不特定多数のメンバーとのコラボレーションが可能な理由だが、これも無闇矢鱈とバックアップを取れば良いというものではない。
PukiWiki標準設定では、次のように設定されている。
$do_backup = 1;
$del_backup = 0;
$cycle = 3; // Wait N hours between backup (0 = no wait)
$maxage = 120; // Stock latest N backups
説明すると、上から
- 自動バックアップ有効
- 自動バックアップ削除機能無効
- 3時間以上経過後のページ更新時にバックアップを取る
- 過去120世代までのバックアップを残す
という設定となっている。
これはサイト規模と運営している人数や、運営方針によって違って来るので、適宜設定して欲しい。
バックアップサイクルが短く、かつ保持するバックアップ世代数が大きければ、それだけサーバのディスクを消費するし、PukiWikiの動作速度に影響を与えるので、よく検討する必要がある。
ページ編集画面の設定
PukiWikiでサイトを運営すると、毎回使うページ編集画面の設定は重要だ。
これは pukiwiki.ini.php と同じくPukiWikiのドキュメントルートにある default.ini.php を設定する必要がある。
1. 編集画面サイズの設定
編集画面（テキストエリア）サイズは、PukiWiki1.5.3のデフォルトでは次のように設定されている。
$cols = 80;
$rows = 20;
PukiWiki1.5.3から編集画面部分のCSSが変更になっており、実際には次のように定義されている。
skin/pukiwiki.css
/* html.php/edit_form() */
.edit_form {
clear:both;
}
.edit_form textarea,.edit_form select {
width:95%;
}
編集画面のテキストエリアは$colの設定とは関係なしに95％幅で表示されるので、実質は$rowsで行数を設定することになる。
また、私が独自に開発して本サイトとGitHubで公開しているドラッグ＆ドロップアップロード対応attachプラグインでは、$colの設定とは関係なく100％幅で表示するように改造してある。
図はドラッグ＆ドロップアップロード対応attachプラグインを導入している、私設松本零士博物館サイトの編集画面だ。
もし、本稿の読者がPukiWikiでサイト運営をしているなら、この画面を見れば一目瞭然で理解して貰えるだろう。
詳しくは、「ドラッグ＆ドロップアップロード対応attachプラグインでPukiWikiに革命を起こす！」記事を参照して欲しい。
2. テンプレートページの無効化と有効利用化
新規でページを作成する際に「テンプレートページは必要か？」に関して、議論が分かれそうである。
単純に「テンプレートは要らない」のであれば、次の設定をすれば良い。
$load_template_func = 0;
図はテンプレートページの読み込みを無効化した画面だが、ちょっと待って欲しい。
今さら説明するまでもないが、PukiWiki標準仕様ではテンプレートページを編集画面からコンボボックスで選択して「読込」ボタンをクリックすると、ページのテンプレートとしてテンプレートページが読み込まれる。
具体的には、pukiwiki.ini.php で次のように定義されている。
\pukiwiki.ini.php
/////////////////////////////////////////////////
// Template setting
$auto_template_func = 1;
$auto_template_rules = array(
'((.+)\/([^\/]+))' => '\2/template'
);
基本的にウェブサイトはコンテンツによって、ページは定型的な構造を持つ。
例えば私設松本零士博物館サイトの「管理人的親不知讃歌」コンテンツの場合、次のページ構成となる。
- SEOプラグイン設定
- タグリンク
- ページトップ画像
- 更新日
- 見出し
- 本文
- ナビゲーションプラグイン
- コメントプラグイン
ゆえに、イチからこれらを手入力するよりは、雛形となるテンプレートページを作成しておき、新規にページを作成する際に読み込めば、ページの作成はグッと楽になるだろう。
この辺は具体例を示さないと分かりにくいので、「管理人的親不知讃歌」コンテンツを例に説明する。
同コンテンツは西暦年ごとに記事を追加するページ構成にしているため、2021年に新規で「テンプレート利用例」記事を追加する場合、ページ名は
管理人的親不知讃歌/2021/テンプレート利用例
としてページを新規で作成すると、自動的にテンプレートページの内容が読み込まれて編集することが可能だ。
または別のコンテンツページで「管理人的親不知讃歌」コンテンツのテンプレートを利用する場合は、
管理人的親不知讃歌/2021/template
上記テンプレートをコンボボックスで選択して「読込」ボタンクリックすると、ページの雛形としてテンプレートページの内容が読み込まれる。
図は新規ページ作成時にテンプレートページを読み込んだ際の編集画面だ。
どういうテンプレートページなのか図だと分かりにくいので、プレビュー画面をお見せしよう。
図はテンプレートページをそのままプレビューした画面だ。
記事としては、
- SEOプラグインの追加設定（キーワードやタグの追加）
- タグリンクの追加
- 更新日時
- 見出し
- 本文
を書き、ページを更新すれば良い。
雛形（template）ページを用意し、活用することで新規にページを作成する際の手間が省けるだけでなく、コンテンツページとして統一したページ構成を維持することが可能になる。
また、2022年になったら、テンプレートページ名を「管理人的親不知讃歌/2022/template」に名前を変更し、内容の2021年部分を2022年に変更して保存すれば、テンプレートページとしていつまでも使い続けることが可能だ。
ちなみに私はTiddlyWikiに書くメモや、今こうして書いている記事原稿の文章でも、SNSでの投稿ですら、テキストエディタにバーッ！と書いて推敲し、ウェブサイトその他に流用するから、雛形ページを読み込んだからといって、直接ブラウザの編集画面に文章を書くことはしない。
PukiWikiでページを作成・更新する場合も、編集画面の内容全部をテキストエディタにコピー＆ペーストし、テキストエディタで存分に原稿を書いて（または編集して）からそれを編集画面にコピー＆ペーストするやり方をしている。
テキストエディタは軽快な動作もそうだが、文字列の検索や一括置換等が可能だし、思考を妨げることなく文章を書き殴ることが可能であるのが大きい。
それに、私は基本的にインターネットとウェブブラウザ自体を信用していないし、いつ入力した文章がパー！になるか分からないような場所に書く気にならないのだ。当然ながら、テキストエディタは編集中でも自動でバックアップするように設定してある。
おわりに
当初は簡単に記事にするツモリでいたのだが、本稿の先頭でＱ＆Ａ掲示板やお問い合わせページからのメールでの質問に触れたように、「読み手に伝わる」文章を書き、さらに分かりやすく画像を提示して説明すると、どうしてもこのぐらいのボリュームの記事になってしまう。
PukiWikiに関しては、この2年ほどで30本を超える記事を書き、オリジナルで開発したライブラリとプラグインは、バージョンアップ版やオンラインサロンの会員限定（2021/06/12 文言修正）バージョンを含めると、やはり30本は超えるようだ。
その上にアイコン素材等も公開しているので、本サイトのPV数に占めるPukiWiki関連ページはそんなに大きくないものの、多数の方に参照していただいているようである。
冒頭で紹介したメールのように、当方に感謝してアドバイス（要望等）をいただけるのは、開発者にとって望外の喜びであり、モチベーションになる。
ゆえにこうして記事を書いているのだが、かと言って今まで私が本サイトで書いた30本以上の記事を全部読んで理解し、公開しているライブラリやプラグインのドキュメントその他を参照して理解しろ！とまでは言えない（PukiWiki初心者で勉強がしたいのなら、全部読んでから質問して来るべきだとは思うが）。
それに私はPukiWiki関連の開発が本職ではないから、どうしてもリアルを優先するし、他に書きたい記事もあるし、本サイトの他に運営しているサイトもある。
結局のところ、PukiWikiに関して継続した開発とその発信をするには、経済的な支援をしていただかないと、こうして記事にしたり、開発したライブラリやプラグインを公開する労力をかけることは出来ない。
そこで、ファンビジネスとオンラインサロンを独自に再構築し、運用するに至っている（2021/06/12 文言修正・追加）
逆に言えば、オンラインサロンの会員はオンラインサロン内で質問や要望を直接開発者である私に言うことが可能だし、私としても積極的に取り入れるモチベーションとなる。
今のところ、少ないながらもFANBOXで支援をして下さっている方がいるが（注：2021/06/12現在）、今後はオンラインサロンの入会者が増えるよう、本サイトで記事と有料コンテンツを公開して行くことにする。
Warning: strpos() expects parameter 1 to be string, array given in /home/eware/dajya-ranger.com/public_html/wp-includes/compat.php on line 473
Warning: preg_match_all() expects parameter 2 to be string, array given in /home/eware/dajya-ranger.com/public_html/wp-includes/shortcodes.php on line 155
Array
