:CategoryDev
PukiWiki2†
Comment†
HTMLタグ出力ロジックの改善と、SKIN選択で、携帯閲覧機能の強化！ -- tejicube
SKINの選択機能は度々言われた事ですね。現状でも携帯閲覧、印刷用ページ表示、多言語用SKIN選択機能が、それぞれ独自に組み込まれている印象があるので2ではキチンと仕組みを整理する必要があるかもしれない。WikiFarmでも活きてくるかもしれませんし --
複数サイトを統一的に見せて管理を楽にするための工夫ってのをどこかに集めたらよいのかも。自分はブラウザから起動しないプログラム、プラグインを一箇所に集めておいてアップデートしやすいようにして、CSS はとりあえず同じものを使いまわすようにしてます。（いじりたければ CSS の設定を追加して、共通の CSS を上書きしちゃう。）skin の修正は一つ一つ直さないとダメですが、それは skin の設計がよくないってことで。ほんとは HikiFarm みたいな仕組みが楽なんでしょうけどね。 --
スケーラビリティに通じるのかどうかわからないけれど、コンバート後HTMLのキャッシュ機能。AutoLink 機能があると、ページ数やページ中の語数によって結構速度差が出る。更新した時以外はほぼ同じ内容なのだから、キャッシュさせて欲しいしたい。 - morikawa
Wiki 書式 → HTML 出力 の部分を外部から利用できる仕組みがほしい。これが可能なら Namazu 検索の精度を飛躍的に上げられる。 --
よそのPukiWikiのドキュメントツリーの一部を自分のドキュメントツリーの一部としてアサインできる。もちろんskinは自サイトのものが適用される。Copyrightが自動で入るとなおよい。 -- sengoku
それはいくらなんでもまずいでしょ。--
まずいというのは技術的に？それとも他の要因で？ ＃Xanaduみたいなのができたらなぁと妄想してます。 -- sengoku
他サイトの他人の書いたものが表示できるのは著作権的にまずい場合があるからでは？許可していないのに勝手にやられる場合も考えられると思います。 --
XML出力のサポート(何かに応用できる?) -- matsuu WIKIソースのXML入出力なら、便利だと思います。HTMLだったらXHTMLで済んじゃいますし。 -- tejicubue
書式の簡略化、日本語環境に合ったWikiスタイル（WikiName形式が役に立たんので）。 -- tejicube
InterWikiName SandBox MenuBar FrontPage この辺はインストールしたての人に説明するのに苦労しています。 -- tejicube
管理者用機能の充実、たとえば、よく編集するユーザやページのアクセスログを表示するページや、一括で凍結したり編集に制限をかけたりする機能がほしい。複数（誰でも）のユーザで編集できるという思想とは別にコミュニティ(意見ではなく）をコントロールすることは重要だと思う。以前のPukiwiki.orgのように管理しきれないなど大きなサイトになればなるほどそれは顕著であると思う。 -- TEPO それならPukiWikiと別で開発した方が早いのでは？ -- Ratbeta
Wiki っつーより完全に CMS（およびサーバ管理）な方向ですね。XOOPS + B-Wiki を模索した方が早そう。 --
そこまで行かなくても、pukiwiki.ini.phpの内容が管理できるページがあるぐらいならどうでしょう? FreeStyleWikiぐらいの管理機能が欲しいと思ったりします。それ以上ならXOOPS+B-Wikiがよさげですねぇ -- merlin
国際化 対応。スキンの自動選択機能は簡単なんですけど、文章までとなると、どうしたもんかなぁ？(ダイナミックコンテンツ時の言語分離は問題だし。よく検討しないと。)-- upk
英語ドキュメントがある程度できたところで、アジアに進出かな? つぎはヨーロッパでとにかく使ってくれて文句などを言ってくれる人を引き込まないとだめですね。(問題はどれだけコミュニケーション取れるかだけど) :) -- merlin WikiFarm の機能が欲しいなぁ。そうするとどうしても管理画面あたりがあってそこから作れるようにしないとだめだけど. -- merlin
プラグイン関係
プラグイン/開発者向け でぱんだ さんがちらっと述べていますが、plugin のクラス化。 extends Plugin のように出来るとなおよいと思う。 - morikawa
たとえば class Plugin では、Config のような関連クラスをメンバもたせておくなどすしてもらえれば、プラグイン開発時にメソッドを探すのも少し楽かな。 -- morikawa 私書箱みたいな機能はどうでしょう。認証とかに余計な負荷がかかりますかね。 -- maja
その手の物って なんか Xoopsのようになって行く気がするんですけど。個別ユーザーの設置とその権限や個別情報の管理って事になるとWikiの範囲を越えるような気がしていますが どうでしょう? -- merlin
そうそう、それで今の所おいらが行き着いたのがB-Wikiになった。 :D -- ishii
そうですね、はい。ユーザの登録が必須になると、うちではきっと誰も使ってくれないので却下ですね。PukiWiki上に、なんかコミュニケーションツールが有ってもいいなぁと思ったんです。 -- maja
Wikiってコンテンツドリブンのコミュニケーションツールであって、パーソンドリブンじゃないので ちょっとアプローチが違うような気がしています。ただ、話題が分岐したときにその部分を別な板に簡単にフォークできるようにすることができるといいなあと思ったりしますね。現在の物だと使いこなしている人でないとちょっと壁があるようにおもいます。*1 -- merlin ページのサマリとして、特定のタグで囲った部分を採用するようにしてはどうだろう? インラインプラグインをページの任意の位置に入れるとそれで指定された部分がページサマリとして取り出せるようにする。rssや ls でそれmoとりだせると <description>として採用できるので便利な気がします。内容作る時に ここがサマリって感じで書けるし、指定していなければ最初の要素としたりする。YukiWiki系では、最初の行をサマリとして取り出していたように思いますが、それをページ内のどこでも使用できるように拡張したものって感じ。 問題は、ブロック要素を越えるような指定がされた場合なんですけどね。 XML的には、こんなタグがありましたっけ?-- merlin
全てのソースコードに、phpdoc形式のコメントを振る。 -- 通りすがり
wikiフォルダに一律にいれるのではなく、階層構造にする。又はコンテンツ管理をもっと楽にする。多くなった場合、特に日記系で現状のものは管理がしにくいと思う。 -- rainier 現状のままでも良いけど、ディレクトリに相当する部分を分離表示するだけでもだいぶソレっぽくなると思うのですよ 例えば、とっても深い dir/dir2/dir3/ほげのページ に対して表示上のページ名（ページの先頭にデカデカと書かれる部分）は、ほげのページ として それ以前の部分を小さく添え書きするってのはダメですか？ なんか 1.3系や1.4系でもすぐできる気がするけど -- 通行人
2の前に実装してみたいけど、2になりそうなお話として（mod_rewrite なしで）FancyURL の実現 -- みこ
レンタルサーバに設置してて（サーバの制限で）mod_rewrite使えないんで、それは魅力的ですね。 -- ななし
複数の書式（Wikiに限らず）への対応とか、複数の書式（PDF等）の出力へのとか、エンジン部分とCMS部分の切り分け。いやコード的には十分できているんですけど。 -- あらいけいた
http://www.zope.org/Members/mjablonski/Epoz を使った、 WYSIWYG化とか -- あらいけいた プラグインやlib/以下のphpでのHTML出力を行わずに、別のファイルで管理を行う。具体的にはxoopsにおけるSMARTのようなエンジンを使用し、現状のスキンでカスタマイズできない部分もカスタマイズできるようにする。…意味通じますかね (^^; -- Ratbeta
いわゆるsmarty化ってやつですかね？1.4.5ベースで若干チャレンジ中ではあるのですが・・・。 -- 瀧
前回の差分だけでなく、Wikipediaのように、過去の差分、全てみれるようになって欲しいです。あと、同じくWikipediaのように、誰がいじったかわかると嬉しいです。 -- 小林 こんにちは :) バックアップの設定を変えることで、全ての編集をバックアップすることができないわけではありません。誰が編集したかについては、編集認証の仕組みと改造でとりあえず実現できるかもしれないですね。 -- henoheno
アップデートするとカスタマイズしたテーマをやりなおさなくてはいけなかったりするので、簡単にアップデートできるようにして欲しいです。(実際には、テンプレートエンジンを使うなどでしょうか?) -- ほげお
pukiwikiエンジンの切り出し。例えばOpenPNEのようなSNSにwikiエンジンを積みたい場合などに利用できると、色々なCMSやブログなどでpukiwiki insideになるかなぁと。 -- toori
rubyプラグインとリンクの共存。私のサイトでは古典の原文に注釈やルビを挿入しようとしているのですが、ルビと注釈の共存ができるとたいへん助かります。 -- mommoo 新たな、ないしruby/脚注関連のまとめBugTrackで、どのような時にどう問題となるかを適示いただいた方が良いでしょう。 -- henoheno
デフォルトのメニューが使いづらいので、ユーザビリティを考えて頂けると幸いです。自分で修正していますが、バージョンアップごとに書き換えるのに疲れました。 -- monmo 「どこを」「なぜ」「どのように」直すべきかも具体的に。 --
VCIOUDLiACdgWqWMPk -- rihjkjvu スケーラビリティの強化†
スケーラビリティの強化。Wikiページが10,000くらいあっても破綻しない仕組み。 -- Wiki好き
10,000 ページものコンテンツを何人のヒトが作れる（=何人のヒトがシアワセになれる）か、を考えると如何なものでしょう。ならば別ホストに設置したPukiWiki(例えばdevとorg)があたかも一つであるように見せる仕組みが出来た方が面白いのでは。結果的に10,000ページあっても破綻しない事にも繋がるだろうし -- にぶんのに
PukiWikiを会社組織で使ってるとこって結構あると思います。で、複数の人がcalendarを毎日更新するだけですぐに千単位のオーダになってしまいます。本当はそういう需要のあるところがパッチを作って本家に吸収してもらうのがいいと思いますが。複数サイトはやってますが管理が大変です。 -- Wiki好き MySQLに対応する様な件†
SQL化の話ってありませんでしたっけ？ -- Logue
どう魅力なんだー(海に向かって叫ぶ) それだけ じゃ運用の問題は解決しないと思いますよ :) -- henoheno
沢山のページがあってもLISTなどの表示が速くなるのではと期待します。サーバへの負担も軽くなるかと思います。そういう魅力（＋期待、夢）を感じます。どうでしょう？*2 ななしさん
ふむふむ。私が懸念しているのは、例えば tracker の一覧表示、例えば数万件分 (^^; あるいは、数万／数十万件のページ需要があったとして、それが本当に一つのコンセプトに基づいた一種類のコンテンツなのかどうかが疑わしいという点です。業務レベルの需要であればなおさら、それを複数のWikiに分割してInterWikiで相互に結ぶ事を検討すべきだと思います。 -- henoheno
一つの目的のために複数本～数十本のWikiを使う、なんて考え方はまだ一般的じゃないと思うのですが (^^; 既に現実のものになりつつありますよ。例えば 1.4.4 はそれを一人の管理者でメンテナンスできる様になりましたし(サポートの人数は別)、official:PukiWiki/活用事例 のラグナロクオンライン系のPukiWiki群はテーマ別に多数のPukiWikiで分散管理している実例ですね(今数えたら、見つかっているものだけで21本もあるぞ (^^; )。 -- henoheno
では、こちらとしては複数のWikiを連携して使うことを奨励するのであって、一本で大量のデータをということは想定されていないということなんでしょうか？データの上限は何件(何KB、何MB)ぐらいなのでしょう？ :( --
いいえ。状況(ニーズ)にふさわしい構成を取ること(=基本)を奨励したい、ということなんです。今まで何件かスケーラビリティにまつわる質問(5000ページ程度のPukiWikiに関する)がありましたが、それはPukiWikiの冗長な処理を省くことでクリアできています。現状PukiWiki側の制限値は特に見つけられていません。trackerについて懸念を述べる意見もありましたが、やはり改善の余地があることがわかっており、それはファイルシステムに依存した方式の欠点とはみなせません。その他にわかっている外部要因は、PHPのデフォルトの実行時間制限(30秒)と、ファイルシステムのリミット(フォルダに収められる項目の数やファイル名の長さ、ファイルサイズ)です。 -- henoheno 2004-09-19 (日) 12:45:10 昔は、データのDB化に賛成でしたが、今では、反対派あまり賛成しないなぁ。というのも、現状の環境だと運用においても、導入においても、敷居が低い。これが、小規模技術者のいないようなサイトで利用されているところで、広がりを見せているところだと思っています。ニッチかもしれませんけどね。ということで、DB化すると、それらユーザを切り捨てることになり、別なユーザ層になってしまうんだ。と思っています。それでいいんですかね？ということです。 -- upk
恐らく、データ量の増加に伴うレスポンス悪化は、ある程度までは CPUが解決してくれるでしょうしね。-- upk
わたしも、DB化はどちらでもいいやって感じですね。PukiWikiの場合は本当に高速化に繋がるか疑問な部分も多いし・・・(本気でtrackerなど一部のページを速くするだけならkifubbsのようにプラグイン内でDB化してとかできるし)もしおこなうなら、検索系のファイル(.refとか.relとか.datとか)のみおこなって、かつDBなしでもできるように互換性は保てるほうがうれしいです。 -- みこ
ただ、一つのコンセプトでｎ万件というのはありえますよ。＞henohenoさん たとえば、わたしのメインサイトみたいなボードゲームの紹介などは（本気でやると）世界のゲームを紹介していくだけであっという間に10000ページいきますし、それらを分けるのは（検索などがしづらくなる分だけ）変だし・・・DB化というよりスケーラブルに対する対策は（現状だとファイルシステムに頼りすぎるので）どこかでしたい/してほしいなというのはありますけどね。 -- みこ
たとえば、 （getexistpages に代表される） opendir / readdir とかを使わない方策・・・とかね(^^) -- みこ
昔はSQLデーターベースに対応するアカウントは、xreaぐらいしかありませんでしたけど、最近結構SQL対応増えてますね。（MovableTypeの影響？）１万ページ以上というのもすごいですけど、そうなると現状でもかなり厳しいのでは？一番問題なのは、データーの管理ですね。少なくとも英数字のファイル名だと、どれがどれだかわからない。 -- Logue
(みこ さんへ) いえ、そんなのありえないから要らない、というのではないのです。やるならやるで、きちんとしたニーズの下にきちんとやるだけです。スケーラビリティについては常に気にしています。1.4.4の新機能の先頭に「スケーラビリティの向上」を持ってきているのは偶然ではありません :) むしろもっとヘビーなユーザーさんからの率直な要求が欲しいのです。でないと、誰かがN万件のダミーデータを吐き出すスクリプトを書くまで、ページ数の本当の限界は見えてきません(それでもPukiWikiに改良の余地があれば直してしまうので、限界は遠ざかるでしょう) -- henoheno
(危うく、みこ さんに「そのデータ圧縮して送って下さい」と書くところでした (^^; -- henoheno
official:続・質問箱/209 例えば10万以上のページの負荷 -- えっと、率直にいうともともと目指していたのはそれなのですが、怖くてかけません。（というか、1.4rc時代に察知してWikiFarm化しちゃいました (^^;）というのはpukiwiki.orgの表示速度も当時はおそかったので10,000どころか1,000でも限界に近いと思ってたので・・・（いまの.orgを見ていると遠ざかっているのは事実だともおもいます） -- みこ
また、わたしの場合は10,000ページで遅くなる理由もなんとなくわかるのでファイルシステムをext2/ext3系じゃないものを・・・というとOSネイティブな話題になってしまいますが (^^; という意味からこだわりがないのです。いざとなったら自分で手をつけてしまうタイプだし、いいものがあれば乗り換えてしまうので (^^; -- みこ
official:続・質問箱/267 Fatal Error: Maximum execution time (スケーラビリティ問題) --
RDB化目的のひとつとして多閲覧要求(例えば 1000万overPV/day)への対応としてはどうでしょう。負荷分散サーバ環境でページレンダリング+キャッシュサーバ(PHP)とデータ保持サーバ(MySQL)を分離するなど。 -- nobody 他サーバへの更新通知と更新内容取得が問題なくできる pukiwiki では RDB である要求は弱い? この目的なら SOAP での他wikiとの連携のほうが面白いかな。 -- nobody
↑の スケーラビリティの強化 とも絡みますが、PVへのスケーラビリティで問題になっている pukiwiki サイトは少ないんでしょうかね。 -- nobody
こんにちは :) サーバー構成に関するコメントは以下にあります。一番下の方です。かいつまんで言えば、膨大なアクセスをさばく事に関して、また冗長性という事に関して はread only ミラーの構築による分散化の方が優れていると思います。 -- henoheno
この新潟県中越地震のWikiが、私が見た中で最もハードなPukiWikiですね (^^; -- henoheno
MTのように、SQL化もできるぐらいなほうがうれしいなぁ 予期せずサイトが好評だったら、いつでもDB化できるというのが良い感じ -- tomix
CVS 覗いてると、過去に一度 SQL 対応コードが入ってるように見えるんですが、なんであれってポシャったんですか？ --
どうせなら、ユーザ管理とかも他のCMSツールと関連付けられたりできるように・・・って、それだとB-Wikka -- Logue
sapid http://sapid.sourceforge.net/ ってご存知ですか? DB を使わずに DB に頼らないとあまりやらなかったようなレベルのことを非常に軽量にこなす CMS です。この軽さと手軽さの両立が実現できるなら PukiWiki の DB 化は不要だという考えに一票を投じることができます。 -- oka326
SQL化によって導入の敷居が上がるというなら、SQLiteで対処することだってできると思います。SQLiteならPHP5には当然入っていますし、PHP4でもXREAやLolipopなど大手レンタルサーバには入っているみたいです。ファイルの扱いは他のSQLに比べて格段に簡単だと思うのですが。どうでしょう？ -- m00a0370ggtt 特定のRDBMSに依存しているものが求められているはずはありませんから、SQLiteも対象に入っていると思います :) -- henoheno
RDBMSについて、余計な遠回りをしないためには、少なくともPEAR DB(データベース抽象化モジュール)、データベースに依存しないSQL、SQLインジェクションを防ぐためのプレースホルダ、無茶でないテーブル設計、PHP4でもPHP5でも動作すること --- といった条件をクリアする必要があるでしょう。 -- henoheno
現状のPukiWiki本体については、現状の「ファイルを取り扱うコード」がもう少し妥当なレベルに最適化され、データを取り扱う部分が充分に抽象化される必要があると思います。 -- henoheno
やっぱり、下手にジャンルを広げないで、とりあえず、cacheディレクトリの.ref、.relあたりのみをsqlで処理っていうのはどうでしょうか？ -- Logue
PEAR DBでなくAdodbでは? -- toori その心は? --
adodbの方が速い --
まずデータを取り扱う部分の抽象化を推し進め、ファイルに依存しないようにすればいいのでは。 -- MASA.H
お疲れ様です。ADOdb のページに、どの位良いのかをぜひ追記して下さい。決め手は「どれだけ成熟しているか」になるでしょう。 -- henoheno
PukiWikiは (1)PHP4.1.2～PHP5 というとても広い範囲をターゲットにしており、相応のユーザーがいます。また、(2)各自が親しんでいるRDBMSは多様です。また、(3)データベース化を希望するユーザーの視点はほぼ無限のスケーラビリティであって、ほぼ0秒の性能ではありません。この時点で、(1)歴史的に古く、同等に広いPHPバージョンで利用でき、前例・実績・資料が豊富にあり (2)サポートするRDBMSが多く、それぞれはほぼ安定しており (3)それなりに早い PEAR DB が抽象化DBの選択肢として第一の候補に上がるはずです。性能的に良いと言われる別の抽象化DBが後発に複数存在しているのは聞き及んでいますが、既存のPukiWikiユーザーの、既存の環境に対してRDBMS利用のチャンスを与えられない物であれば欠点になります。 -- henoheno
リレーショナルデータベース「も」扱えるように持っていく利点の多くは、MASA.H さんが仰っている様に、「どのDBを使うか(どの抽象化DBを使うか)という話題」以前の問題を克服するまでの過程にあります。すなわち、コンパクトな状態を維持しつつ、なるべく構造化と抽象化を進めた結果を勝ち得る事。*3 やって見れば絶対に何かしら問題が起きますから(それを含めて直すつもりが無ければ未来はありませんから)、そうした動きをお待ちしております :) -- henoheno
最近は PEAR DB から PEAR MDB2 への移行が提案されているのですね。(2006-02-09に MDB2がリリースされている) -- henoheno
RDB化も大事だけど、なんで誰もsmartyのcacheみたいなのを話に出さないんだ --
smartyのcacheのココロは一体…？textデータからhtmlへの変換時間がもったいないということかなぁ？それとも、htmlデザインテンプレートを整備したいという要求なのかなぁ？ -- kawai
Smarty is way too big to include in my opinion. Even with cache, it's still a huge script language and theme engine, of which we will use only a handful of it's features. Simpler theming is a better idea than just jumping with Smarty because it sounds cool. PukiWiki's advantage is that it is speedy. Smarty will CONSIDERABLY diminish that. -- JordanC
Considering a DBMS should be an optional component rather than an enforced backend. It can quite easily be done that the file-write operations are done in such a way that they can be easily switched to SQL queries at any time through a "principle" of abstraction, if you will. Of course, database engines can be highly developed and have impressive optimiser engines, but to say that it will make pukiwiki instantly faster isn't a complete truth. It should be still emphasised that there are things available to make page-based wiki work very well with simple flatfiles. Again PEAR provides a useful library for us with SQL, but we must be very wary to check that a package would be used fully, rather than just using the minor features. Also, if we do use PEAR, then just move PukiWiki entirely to OOP. -- JordanC
Just as a note: I've started to do some beta work on PukiWiki2 myself since it's not really that large a codebase nor large a task. The codebase is on GoogleCode - http://code.google.com/p/pukiwiki/source/browse/trunk/ -- JordanC
今まで速度の面からSQL化の話をしてきましたが、ほかのWebアプリからPukiWikiを使ったり、その逆（元となるWebアプリの認証情報をPukiWikiで使うなど）とかの面からのSQL化する上での視点から考えてみるのはどうでしょうか？ -- Logue
I've had trouble directly translating your question, but I think it was of comparative speed advantage with other applications and, should PukiWiki use it. Well, I think that it'd be an idea to use SQL, but that it should be offered alongside flatfiles for those who prefer it. DBMS engines have optimisers which really reduce the time on data operations and so on, but I think switching to SQL entirely alienates those, like myself - who prefer whole files as the storage format. -- JordanC PukiWiki2 storage<->content†
I wanted to know what you thought about this concept. If we are interested in using MySQL as a storage backend, then i think the entire idea should still be on zeroconf or minimal conf possible. If SQL fails, revert to file content as a fallback. I have started work on this in the GoogleCode repository, and the idea I have taken is that data stored in tables should be queried and returned in an itermediary format so that all are required are abstract class extensions to a non-final class, which will mean the methods for file read, write,edit, delete and so on can be extended. From this, actions which are performed on pages or on the module can still occur and do not interfere with file operations. If we have abstraction of methods and actions with classes, we can then allow hierarchical modularity. -- JordanC
Current proposed structure: 階級 (内容) <- 仲介の <-- 中心 階級 <-- [伸ばす] 階級 (MySQL) コンピュータ 階級 (PostgreSQL) -- JordanC
仲介の = {title, {content},{attributes}} -- JordanC
I considered setting files, such as wiki, chache, and diff, to SQL as they are simply. However, since these data can be divided by class in sql, I separate the processing which displays HTML from wiki, and feel that to remake is better for the remainder rather than improving. -- Logue
Indeed, but I've put these as an array of settings under the PukiWiki_flatfile_conf class, but they can be split up whichever way you like as it supports INI as well. I already indicated that a remake was better, but then again - PukiWiki2 is more-or-less a remake anyway, since the design is somewhat choppy in < 2. -- JordanC
編集ボタンを押す人って結構すくないんですよね... 一概にはそう言えないとか言われそうだけれど。 もちろんRDBMSについては特定のDB製品にこだらわず使えるもので無くてはならず、間違いなくプレースホルダを利用し、SQLインジェクションの話題など最初からありえない物で無くてはなりません。テーブル設計など終わっていて当たり前です Last-modified: 2014-02-11 (火) 04:06:40
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
