Wikiでは表形式でデータを整理して表示したいケースがあるが、その表がソート可能であれば、非常に便利だろう。残念ながらPukiWikiにはソート可能なテーブル（表）のプラグインが特にないようで、最悪はフルスクラッチで作るか？と思っていた。
ところが、ググッてみると過去に作られて放置された（？）それらしきプラグインの残骸のようなモノがあったので、自力で使えるプラグインに仕立ててみた。思いの外「使える」モノになったので、その設置方法等を記事にしてみたい。
前回の記事と同様にサブドメインを連番で用意してあるので、今回はmuseum-16サブドメインの内容をmuseum-17サブドメインにコピーし、検証しながら作業を進めた。
メニューページが「MenuBar」ではなく「メニューバー」になっている（日本語ページ名でPukiWiki用URL短縮ライブラリにより短縮される）ので要注意。
※2020/07/31追記
ソートテーブル（表）プラグインを完璧に近い形でバージョンアップし、導入記事を書いたので、こちらの記事も併せて参照して欲しい。
プラグインのベースは約13年前の残骸
自分が欲しいプラグインがネット上にないか？と思って探してみると、それっぽいプラグインを見付けることが出来た。次のサイトにアップされているモノがそうだ。
記事の日付が2006年11月と古く、サイト自体も更新されないで放置されているようだ。しかもこのページの記述とPHPのソースだけでは、実際に動くモノにはならない。
参考にさせていただいておいてこんなことを書くのはアレだが、PukiWiki関係の情報はこの手の古くて中途半端な情報ばかりだ。こういった適当なヤッツケ仕事のページが圧倒的なので、今さらPukiWikiを積極的に導入して活用しよう、とならないのだろうと思う。
ともあれ、このページにアップロードされているプラグインのPHPコードだけではソートテーブルは実現不可能なので、必要なJavaScriptファイルであるsortabletable.jsとfilterabletable.jsファイルをネットで探し出し、ソート状態を表示するアイコンも何とか適当に見繕い、実装とテストおよびプラグインの機能拡張を実施した。
ベースのプラグインから拡張した仕様は次の通りだ。
- ソート種別の拡張（「Number」および「Date」指定の機能正常化）
- フィルタ処理オプション指定の変更
- 自動採番No列の追加
- 自動採番増分指定
- 自動採番列名称指定
- ヘッダ行バックグラウンドカラー指定
- 奇数行バックグラウンドカラー指定
- 偶数行バックグラウンドカラー指定
- テーブル全体の幅指定（Ver0.6.0から実装）
- ヘッダ行の折返し禁止指定（Ver0.7.2から実装）
- 任意のカラムをソート対象にしない仕様を追加（Ver0.7.3から実装）
ソート部分はJavaScriptのsortabletable.jsファイル部分が担うが、入手したファイルは2006年9月と古く、しかもソースをチェックすると、列のソート種別の「Number」と「Date」指定のコードが大甘だ。これでは「Number」指定した列に「10個」とか「3.3cm」といった「数字＋文字」もしくは「実数＋文字」のデータだとちゃんとソートされないし、「Date」指定の場合も「yyyy-mm-dd」形式しかサポートしていないので、日本で一般的な「yyyy/mm/dd」形式がサポートされない他、時刻が入った場合も正しくソートが出来やしない。元のソースはスウェーデン人が作ったようだが、素人かよ？なコードだ。ε- (´ー`*)ﾌｯ
フィルタ処理部分を担うJavaScriptのfilterabletable.jsファイルはまた全然別の人（多分欧米人）が作ったようで、こっちも同じく2006年9月と古いが、まだマトモでちゃんと動きそうである。やれやれ。
やるなら自動採番もしたいし、奇数行と偶数行でセルのバックグラウンドカラーを指定して見やすくしたい。1ページに複数の表が存在する場合も考えられるから、表のヘッダ行のバックグラウンドカラーも指定できた方が良いだろう。
そうこう考えていると、単純にソートテーブルを作りたい場合と、ちょっとしたデータ件数があるソートテーブルを作りたい場合とで、プラグインに渡す引数の数が違ってくる。
元々のプラグインのソースでは、第2引数に「1」を指定するとフィルタ処理のオプション指定となる仕様だが、コレではプラグインとして非常に使い勝手が悪い。
そこで、ほぼ換骨奪胎して私の方でプログラムをあらかた作り替えてしまった。元のソースも素人かよ？なコードだったしな。ε- (´ー`*)ﾌｯ
仕様として整理すると、次のオプションを順不同で指定可能（省略可能）にした。
- 自動採番No列追加（autonum[=開始番号]）
左端に固定で列を追加して自動採番する（開始番号は指定可能で省略した場合は「1」） - 自動採番増分指定（numstep=増分）
自動採番Noの増分を指定する（このオプション省略時の増分は「+1」） - 自動採番列名称指定（numname=列名称）
自動採番列名称を指定する（このオプション省略時の列名称は「No」） - ヘッダ行カラー指定（head=カラー指定）
ヘッダ列（行末が「|h」）のバックグラウンドカラーの指定が可能 - 奇数行カラー指定（odd=カラー指定）
奇数行のバックグラウンドカラーの指定が可能 - 偶数行カラー指定（even=カラー指定）
偶数行のバックグラウンドカラーの指定が可能 - フィルタ処理（filter）
Excelライクな表のフィルタ処理が可能 - テーブル幅（width=％指定）
テーブル全体の幅指定が可能 - ヘッダ行折返し禁止指定（nowrap）
具体的なプラグインの書式は次の通りとした（列のソート種別は必ず1番目に引き渡されるものとする）。
#sortable_table([Number|Date|String][,autonum[=1]][,numstep=1][,numname=No][,head=#f0f0f0][,odd=#ffffff][,even=#f6f9fb][,filter][,width=100][,nowrap]){{
|~数値|~日付|~文字列|h
|RIGHT:|CENTER:|LEFT:|c
|数値セル1行目|日付セル1行目|文字列セル1行目|
|数値セルn行目|日付セルn行目|文字列セルn行目|
|数値フッタ|日付フッタ|文字列フッタ|f
}}
上記書式の例で全部のオプションが指定された場合、列の左から数値（Number)・日付（Date）・文字列（String)でソートし、列定義行（行末が「|c」）で、左から右寄せ・センタリング・左寄せ（デフォルト）となる。
表の左端に「No」列として自動採番列を追加し、開始番号は「1」自動採番の増分は「1」となる。
その他、ヘッダ行・奇数行・偶数行のバックグラウンドカラーの指定があり、フィルタ処理指定で、テーブルは100％幅指定となる。
また、テーブルのヘッダ行は折返し禁止で表示される。
※2021/04/13追記
任意のカラムをソート対象にしたくない場合、例えば上述の書式の例で「文字列」カラム（ソート種別「String」）をソート対象にしたくない場合は、
#sortable_table(Number|Date|, ･･･
といったように、任意のカラムに対応するソート種別を省略すれば良い。
但し、全部のソート種別を省略した場合はデフォルトで全てのカラムのソート種別を「String」とみなすので、この場合は
#sortable_table(||, ･･･
とすることで回避出来る。
この場合、自動採番No列追加（autonum[=開始番号]）を指定しない限り、全てのカラムがソート対象外となる。
ソートテーブル（表）プラグインの設置
色々と工夫してソートテーブル（表）プラグインを作り込んでテストし、本サイトのダウンロードページにアップロードしておいた。
ダウンロードページからソートテーブル（表）プラグインをダウンロードし、ローカルの作業フォルダに解凍する。
解凍すると図のように「image」フォルダにソート状態を表示するアイコン（PNG形式）ファイルを3つ置いてあるので、サーバの「image」フォルダにFTPする。同様に「skin」フォルダにはJavaScriptファイルが2つ置いてあるので、サーバの「skin」フォルダにFTPする（追加分のpukiwiki.cssファイルもあるが、とりあえず気にしない）。
最後にプラグイン本体であるsorttable_table.inc.phpファイルをサーバの「plugin」フォルダにFTPし、FTPした全ファイルの属性を「644」に設定しておこう。
次に、「skin」フォルダにあるpukiwiki.cssに手を入れる。
PukiWikiの標準CSSの場合だとテーブル（表）が全てセンタリングで表示されるため、それが気に食わないので正しておく（気にならない人は修正しなくて良い）。具体的には148行目付近のCSS定義で、marginの値を変更する。
skin\pukiwiki.css（修正前）
.style_table {
padding:0px;
border:0px;
margin:auto; /* この行を変更する */
text-align:left;
color:inherit;
background-color:#ccd5dd;
}
skin\pukiwiki.css（修正後）
.style_table {
padding:0px;
border:0px;
margin: 0;
text-align:left;
color:inherit;
background-color:#ccd5dd;
}
ついでに（なぜこんなのがあるのか不明だが）「ie5」クラスがテキストをセンタリングしているので、この部分を殺しておく。具体的には207行目付近だ。
skin\pukiwiki.css（修正前）
div.ie5 {
text-align:center;
}
skin\pukiwiki.css（修正後）
div.ie5 {
/* text-align:center; */
}
先ほどダウンロードして解凍した「skin」フォルダに（追加分）pukiwiki.cssファイルがあると思うが、その内容をpukiwiki.cssの最後にコピー＆ペーストする。具体的には656行目付近に追加する。
skin\pukiwiki.css（修正後）
/* sortable-table.js */
.sort-arrow {
background-position: center center;
background-repeat: no-repeat;
margin: 0 2px;
background-image: url("../image/sort-blank.png");
}
.sort-arrow.descending {
background-image: url("../image/sort-descending.png");
}
.sort-arrow.ascending {
background-image: url("../image/sort-ascending.png");
}
/* filterable-table.js */
.filter-box {
width: 100%;
height: 1.5em;
margin: 0;
}
@media print {
ファイルを更新し、サーバの「skin」フォルダへFTPすれば、プラグインの設置は完了だ。
ソートテーブル（表）を書いてみる
実際にソートテーブル（表）はどうなるのか？が気になるところだと思うので、テストと評価の意味を込めてソートテーブルを記述してみよう。適当なデータだが、次の記述をFrontPageに書いてみる。
ソートテーブル（表）記述例
** ソートテーブル（表）テスト
***通常のテーブル（表）
|~日付|~長さ|~尺貫法|~メートル法|h
|CENTER:|CENTER:|RIGHT:|RIGHT:|c
|2019/08/01|1里|36町|3.927km|
|2019/08/02|1町|60間|109.09m|
|2019/08/03|1丈|10尺|3.03m|
|2019/08/04|1間|6尺|1.82m|
|2019/08/05|1尺|10寸|30.3cm|
|2019/08/06|1寸|10分|30.3mm|
|2019/08/07|1分|10厘|3.03mm|
#br
***ソートテーブル（表）
#sortable_table(Date|String|Number|Number,autonum=1,numstep=1,numname=No,head=#f0f0f0,odd=#ffffff,even=#f6f9fb,filter){{
|~日付|~長さ|~尺貫法|~メートル法|h
|CENTER:|CENTER:|RIGHT:|RIGHT:|c
|2019/08/01|1里|36町|3.927km|
|2019/08/02|1町|60間|109.09m|
|2019/08/03|1丈|10尺|3.03m|
|2019/08/04|1間|6尺|1.82m|
|2019/08/05|1尺|10寸|30.3cm|
|2019/08/06|1寸|10分|30.3mm|
|2019/08/07|1分|10厘|3.03mm|
}}
#br
ソートテーブルのオプションとして、「autonum=1,numstep=1,numname=No」は「autonum」だけの指定で省略が可能な内容だが、一応例として列挙しておく。
早速ページを更新して見てみよう。
タイトル行をクリックするたびに、その列の昇順・降順を切り替えてソートするのが分かる。
一応、「尺貫法」と「メートル法」の「単位」を度外視すれば、ちゃんと「数値」として正しくソートされている。自動採番の「No」列と「日付」列でのソートも正しい。
データ件数的にフィルタ処理をしても仕方がないが、「フィルタ処理」のチェックボックスにチェックを付けるとフィルタ処理が可能だし、データ件数が多い表をページとして公開し、メンバーと共有することも可能だ。
本気でデータ件数の多いフィルタ処理をやるなら「Excelファイルを添付すりゃいいんじゃね？」とは思うが、PukiWikiで公開するデータ（表）を手軽にフィルタ処理が出来るのは、やはり画期的ではあると思う。
ここまでの改造の成果
ここまでの改造の成果であるPukiWikiはこちらなので、「実際どうなのか？」を確認したい人は参照して欲しい。
今回も前回と同様にゲストアカウントを用意したので、スパムや破壊行為は困るが（スパムフィルタspam_filter.phpは導入済みだが）、ユーザー名とパスワードは次の通りだ。
ユーザー名：guest
パスワード：guest
ファイルの添付やページの凍結・解除は行なえないが、ほぼ全てのPukiWikiの作業が可能なので、色々と試してみて欲しい。「案外PukiWikiって使えるな」と思っていただければ、私としても嬉しく思う。
おわりに
テーブル（表）をソートしたいニーズは今までもあっただろうし、今でもPukiWikiを利用してサイトを運用している人だっているハズなのに（そんなに多くはないのかも知れないが）、なぜ今までこういったプラグインが存在していなかったのだろうか？それとも、単に私がネットでプラグインを見付けることが出来なかっただけなのか？（まさかね？）
お陰でちょいと気合を入れてプラグインを作り込んでしまったが、それなりにニーズと実用度の高いプラグインにはなったと思う。
今までPukiWikiを改造しまくって少しでも「使える」モノにして来たのだが、それにしてもここまで工数をかけないと「使えない」とは、普通なら手を出さないだろうな、と思う。
全体的に（潜在的な需要はあると思うのだが）Wikiシステム自体が下火だし、こんなんじゃ普通の人はますますPukiWikiやその他Wikiシステムで自前のサイトを運営しようとは思わないだろう。WordPressの方が遥かに便利で簡単だし、見栄えのするサイトが少ない工数で実現するのだから。
それでも私は、Wikiシステムの「ライトさ」には魅力があると思っている。
本サイトで記事を書くのでもそうだが、WordPressは便利なものの、気軽にコンテンツを作るには「ヘビーだ」と感じる。PukiWikiでページを気軽に作ってメンテナンスするほど、WordPressは気楽ではないと思うからだ。
･･･もうしばらく、私はPukiWikiに手を入れて改造しているような気がする。
Warning: strpos() expects parameter 1 to be string, array given in /home/eware/dajya-ranger.com/public_html/wp-includes/compat.php on line 498
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
