PukiWikiがまだ進化していた！PHP7でも動く
2020年06月19日 プログラミングTIPS
PHPで動くWikiシステムとして有名なPukiWikiは、PukiWiki派生の互換Wikiプログラムもいくつか登場し（PukiWiki Plus!など）、もう何年も前にPukiWikiはオワコンかと思っていました。が…なんと、最新のPukiWiki 1.5.3はPHP7.4にも対応していました！
驚きました。Pukiwiki1.5.0の登場が2014年で、Pukiwiki1.5.1の登場が2016年。ここでもう終わったのかと思っていました。その後、2019年にPukiwiki1.5.2が登場し、今年2020年にはPukiwiki1.5.3が登場していました。
最新のPukiWikiでは、UTF-8推奨、スマホデザイン対応、検索機能強化、プレビュー移動時の警告など、新機能が追加されていました。ただ、実際に新サーバーで動かしてみると、PHP7系の構文で注意や警告のエラーがたくさん出ました。動くことは動きますが、あまりよくはないですね。
今までのサーバーではPukiWiki 1.4系のシステムに、PHP5.4以降でも動くようにパッチを当てて動かしていました。PukiWikiには、既存のページに自動でリンクを張るAutoLinkという便利な機能があります。この機能は、ページ数が増えるととんでもなく重い処理となっていきます。そのため、PukiWikiのページ内容を変換した後にキャッシュさせるプログラムを組み込んでいました。毎回パッチを当てるのも大変なので、今まではずっとPukiWiki1.4系で動かしていました。
サーバーを移転してPHP5系からPHP7系に上がることにより、このキャッシュの機能やPukiWiki自体が動かなかったりしたらどうしよう…とずっと心配でした。先日投稿した記事の「LAMP環境からLEMP環境になりました」にも書いたように、まずは仮想サーバー上で動作確認しました。結果としては、最新のPukiWiki 1.5.3がPHP7.4対応になっていてくれたおかげで助かりました。これをベースにキャッシュの機能を組み込みました。さくらのVPSをレンタル（詳しくは「サーバーをさくらのVPSに移転」参照）した後、試しにページ数の多いWikiで文字数の多いページを表示させてみました。すると、キャッシュなしでは、1ページを表示するのに3秒や5秒かかることもありました。重すぎてこのままでは使えません。キャッシュシステムが動くか不安になりながら、キャッシュのプログラムを組み込んで動かしてみると…1ページ表示するのに、0.002秒～0.003秒！（PukiWikiのプログラム内で計測を始めて、最後のHTMLを出力し終わるまでの時間です）キャッシュシステムを組み込むと、1000倍以上速くなりました。この後、PHPのコンパイル済みのバイトコードを共有メモリに保存するOPcacheをインストールしたところ、さらに2倍速くなり、表示処理は平均0.001秒になりました。1秒間に同時に1000アクセス来ても余裕で処理できます。
驚きました。Pukiwiki1.5.0の登場が2014年で、Pukiwiki1.5.1の登場が2016年。ここでもう終わったのかと思っていました。その後、2019年にPukiwiki1.5.2が登場し、今年2020年にはPukiwiki1.5.3が登場していました。
最新のPukiWikiでは、UTF-8推奨、スマホデザイン対応、検索機能強化、プレビュー移動時の警告など、新機能が追加されていました。ただ、実際に新サーバーで動かしてみると、PHP7系の構文で注意や警告のエラーがたくさん出ました。動くことは動きますが、あまりよくはないですね。
今までのサーバーではPukiWiki 1.4系のシステムに、PHP5.4以降でも動くようにパッチを当てて動かしていました。PukiWikiには、既存のページに自動でリンクを張るAutoLinkという便利な機能があります。この機能は、ページ数が増えるととんでもなく重い処理となっていきます。そのため、PukiWikiのページ内容を変換した後にキャッシュさせるプログラムを組み込んでいました。毎回パッチを当てるのも大変なので、今まではずっとPukiWiki1.4系で動かしていました。
サーバーを移転してPHP5系からPHP7系に上がることにより、このキャッシュの機能やPukiWiki自体が動かなかったりしたらどうしよう…とずっと心配でした。先日投稿した記事の「LAMP環境からLEMP環境になりました」にも書いたように、まずは仮想サーバー上で動作確認しました。結果としては、最新のPukiWiki 1.5.3がPHP7.4対応になっていてくれたおかげで助かりました。これをベースにキャッシュの機能を組み込みました。さくらのVPSをレンタル（詳しくは「サーバーをさくらのVPSに移転」参照）した後、試しにページ数の多いWikiで文字数の多いページを表示させてみました。すると、キャッシュなしでは、1ページを表示するのに3秒や5秒かかることもありました。重すぎてこのままでは使えません。キャッシュシステムが動くか不安になりながら、キャッシュのプログラムを組み込んで動かしてみると…1ページ表示するのに、0.002秒～0.003秒！（PukiWikiのプログラム内で計測を始めて、最後のHTMLを出力し終わるまでの時間です）キャッシュシステムを組み込むと、1000倍以上速くなりました。この後、PHPのコンパイル済みのバイトコードを共有メモリに保存するOPcacheをインストールしたところ、さらに2倍速くなり、表示処理は平均0.001秒になりました。1秒間に同時に1000アクセス来ても余裕で処理できます。
EUC-JPからUTF-8ヘの移行
PukiWikiのシステムがEUC-JPからUTF-8の文字コード推奨に変わったことにより、既存のPukiWikiサイトもEUC-JPからUTF-8に移行してみました。以下のサイトに変換スクリプト「data2utf8.php」があるので、それを利用しました。wiki、diff、backup、cache、counterなどのデータを持ってきて、上のdata2utf8.phpをサーバー上から実行することで、各データをEUC-JPからUTF-8に変換できます。PHPの実効時間やメモリリミットを超えてしまうと変換をミスってしまうため、data2utf8.phpの設定値は適宜変更する必要があります。
EUC-JPとUTF-8で1文字のバイト数が違う
データだけ変換すればそれでOKかと思いましたが、ダメなところがありました。それはAutolinkの設定値です。EUC-JPからUTF-8に変わったことにより、1文字が3バイトになっていました。ここは変える必要がありました。また、規定のバイト数に合わせているのに、なぜかAutoLinkされないページまであって、これは解決できませんでした。Mecabの導入
以前、日本語形態素解析のために、ChasenやKAKASIではなくMeCabを入れて使っていました。今回も再びMeCabを入れてみました。まずはCentOS8.1にMecabをインストールし、PukiWikiの本体に組み込みました。以前はMeCabインストール用の情報がどこかのページに載っていた気がするのですが、見つかりませんでした。見つからなかったので、過去の自分のプログラムを見ながら書きかえました。結果として、以下のページのように、ページ一覧の目次が日本語順で表示できました。漢字でも50音順に並びます。EUC-JPからUTF-8に移行するとページ名とURLが変わってしまう
PukiWikiはページ名がURLになるため、EUC-JPからUTF-8にすると、URLが全て変わってしまいます。「アクセスもあまりないし、まぁいいか…」などと思っていたのですが、ページ数が多いWikiでは影響が甚大でした。すでにUTF-8に変換してしまったPukiWikiサイトはそのままUTF-8で運用し、途中からはEUC-JPのまま移転することにしました。PukiWikiのライブラリやプラグインファイルは一箇所にまとめて各Wikiで利用しているため、EUC-JP用とUTF-8用のライブラリがそれぞれできてしまいました。PukiWiki本体の中までガリガリとプログラムをいじっているため、またアップデートの際に面倒なことになりそうです。スキンとCSSを全て作り直し、スマホデザイン対応
PukiWiki 1.5.3の初期スキンとCSSがスマホ対応されているため、これをベースに全て作り直しました。今まで使っていた既存のスキンは破棄しました。新たにデザインを一から作り直し、スマホデザインにも対応しました。個人的に、PC用の2カラムの広いデザインが好きなのに、Googleから「文字が小さすぎる！」と何度も怒られてしまうので、何度も修正しました。2カラムはやめて、1カラムデザインにしました。1カラム移行用に、自分で新しくPukiWikiプラグインを作ったりもしました。Wikiの表は、とてつもなく広いテーブルもあるため、これをどうするかも問題でした。表の横幅をスマホサイズに収めてしまうと全く文字が入りきらなくて読みにくい表になりますし、文字を小さくすると「文字が小さすぎる！」とグーグル先生に怒られます。
結局、「横に広いテーブルは横にスクロールできるようにする」という対応をしてみました。これが正解なのかはサッパリわかりません。iPhoneのSafariは、横スクロールできる表が現れても「横スクロールできるよ」というスクロールバーが出てくれません。横スクロールできることを知らないまま去ってしまう人もいるんじゃないかと心配ですが、どうすることもできません。
PukiWikiの過去ログを漁っていたら、ネスケ対応の話などが…
うまく動かないところがあって、PukiWikiの過去ログを漁っていたところ、Netscape Navigatorの話題などが出てきました。すごい歴史がありますね…。よく令和の時代になってもメンテナンスが続けられているものです。「PukiWikiはPHPで動的に出力するのではなく、静的なHTMLを出力すべきだ！」というような懐かしい話も見かけました。そういえば、昔は常にPHPを動かすのはリッチだったんですよね。レンタルブログやMovable TypeなどのCMSも、静的にHTMLを出力するシステムが多かったりしました。その後、静的にHTMLを出力するシステムは、「再構築の負荷が高すぎる」という弱点があわらになって、レンタルブログ界隈でも大変なことになりました。今では動的に出力するのは当たり前の時代になっています。ただ、PukiWikiのシステムについては、どこかのタイミングでページキャッシュを入れておくべきだったんじゃないかなぁと思っています。素のままでは、オートリンクの挙動が重すぎます。それでも、今でもメンテナンスされ続けていることには感謝です。ということで、いろいろあって移行作業は大変でしたが、なんとか終わらせました。PukiWiki本家のメンテナンス、ありがとうございます。