サポート掲示板/過去ログ5

[サポート掲示板]

 lastmodified plugin - amn (2003年05月29日 19時55分28秒)

こんにちは。当方 perl がわからないので、こんなプラグインはどうかな、という提案だけさせていだだきます。

おそらく難しくないと思うのですが、

{{lastmodified}}

と書くと、そのページの最終更新日（一覧ページで表示される日時と同じもの）が挿入されるというものです。

オプションで ページを指定できてもよいですね。

• 奇遇ですね。なんで無いんだろうとおもって、ちょうど昨晩つくったので近いうちにあげときます。 - tinsep19 (2003年05月29日 21時07分09秒)
• わ、ほんとに奇遇ですね。早速、ありがたく利用させて頂きますm(__)m - amn (2003年05月30日 09時05分30秒)

 同一サーバーで複数のFSWikiの運用 - Kinsan (2003年05月29日 17時55分34秒)

下の投稿と同じ事柄についてですが、1行コメントでは書き切れそうにないので、別にしました。

私も会社で複数のWikiを立てていて、symbolic linkを使ってました。昨日別件で、URIのPATH_INFOの話題があり、手元の資料で確認して、PATH_INFOの仕組みは、まさに本件のような場合のためにあるのだという事を知りました。

そこで、path_infoの機能を使う形で、FSWikiを複数アカウントに対応させてみました。

以下ではテストのため、wiki2.cgiとsetup2.plというファイル名を用いています。プログラムの修正内容は下記の通りです。

• wiki.cgiのsetup.plの読み込みの部分を下記と差し替え

if(length($path_info) > 0){
    require "./prj/$path_info/setup2.pl";
}else{
    require "setup.pl";
}

• setup2.cgiに下記を追加(プラグインの読み込みの前)

#==================================
# For multi project
#==================================
if(length($path_info) > 0){
    $data_dir = "./prj/$path_info/$data_dir";
    $backup_dir = "./prj/$path_info/$backup_dir";
    $attach_dir = "./prj/$path_info/$attach_dir";
    $pdf_dir = "./prj/$path_info/$pdf_dir";

    $log_file = "./prj/$path_info/$log_file";
    $attach_log_file = "./prj/$path_info/$attach_log_file";
    $freeze_file = "./prj/$path_info/$freeze_file";

# adjust URL address for path_info
    $script_name = "../$script_name/$path_info";
    $css = "../$css";
}

• ディレクトリーの使い方

fswikiの置いてあるディレクトリーの下に prjディレクトリーを作り、そのまた下に、プロジェクト毎のディレクトリー(例：prj/wiki_open)を作り、ファイルsetup2.plとディレクトリーdata,backup, attach, pdfをその下(prj/wiki_openの下)に移動またはコピーする。

• 呼び出し方

http://www.hogehoge.com/wiki.cgi/wiki_openの様に呼べば、そのプロジェクト毎のwikiを呼び出せます。

• テスト結果

詳細なテストはしていませんが、一応動きました。

• wiki.cgiに次のコードを追加するのを書き忘れました。(上記の分の前に追加)"$path_info = $cgi->path_info();$path_info =~ s@^/@@;" - Kinsan (2003年05月29日 18時02分44秒)
• 素晴らしいです。今の作業が一段落したら取り込ませていただきます。 - たけぞう (2003年05月29日 18時44分07秒)
• 最近流行りのWikiFarmみたいな感じになるんでしょうか？ - tinsep19 (2003年05月29日 21時21分20秒)
• おお、もう解決案が。ちなみに↓のはWikiFarmも想定してました。 - Lef (2003年05月30日 05時09分19秒)
• ちょっといじってみました。FSWikiFarmというページを勝手に作らせていただいてそこにまとめてみました。 - Lef (2003年05月30日 09時26分12秒)
• setup.plの代わりにrequireすることでFarm風に動作するものをつくったのですが、いくつか大きな変更点があるため悩んでいます。一番大きな変更は、設定ファイルが独自になっている点です。file自体は100行程なので対して量ではないのですが…。setup.plには手を加えず、Farm向けの設定ファイルがない場合には、setup.plも含めて他には影響がないようにしています。なお、副作用？でPATH_INFOやPATH_TRANSLATEDを使わずに、suexe対応でFarmっぽく動作させることも出来るようになりました。3.4.0dev6ベースです。お見せすべきですか？>たけぞう氏 - Lef (2003年06月02日 04時29分55秒)
• 私の書き方だと、path_info()を呼んでいる行をコメントアウトすると、この機能は無効になるはずです。設定ファイルが独自にならないためには、そういう書き方をすべきと私は考えました。 - Kinsan (2003年06月02日 06時47分44秒)
• 私はまだ3.4.0の作業で手一杯という感じでFarmに関しては主導できない状態ですので議論のネタ出しという意味では公開していただけるとありがたいです。 - たけぞう (2003年06月02日 16時43分41秒)
• FSWikiFarmのページに公開してみました。コードの主な部分は互換性維持なので、やってることは大したことないです。readmeもかなりいい加減で、bug出しとかもかなり甘いと思います。すみません。(ってもうdev7が出てる〜) - Lef (2003年06月03日 21時41分38秒)

 同一サーバーで複数のFSWikiの運用 - Lef (2003年05月28日 03時08分36秒)

手元でFSWikiを使わせていただいているのですが、すでに3アカウントで利用しており、バージョンアップなどの対応がやや大変です。今後さらに増えるかもしれないこともあり、できれば一ヶ所にインストールしたFSWikiを複数のユーザーが利用できるようになると助かります。いまはとりあえずsynlinkでなんとかしているのですが、いつ動かなくなるかちょっとわからないので、できれば考慮していただけると嬉しいです。(setup.pl的な内容を持つwiki.cgiで起動するがいいのでしょうか？)

 スタイルシートのバグ？ - TK (2003年05月23日 20時50分16秒)

デフォルトのスタイルシートに

div.sidebar h2,h3,h4 {
  margin-top : 0px;
}

のような箇所がありますが、この表記では、sidebar内で有効なのは、h2のみで、h3,h4 は全てという意味になってしまいます。これって意図したものとは違いますよね。div.sidebar ul,li とかも同様だと思います。

• div.sidebar h2,div.sidebar h3というように記述するんでしょうか。HTMLがValidでなかったりというところもありますが、このあたり疎くてすいません。 - たけぞう (2003年05月29日 18時40分54秒)

 PDFプラグインについて - たけぞう (2003年05月22日 20時58分35秒)

ユーザの皆様にお聞きしたいのですが、PDFプラグインは実際に活用されていますでしょうか？現状では、PDFにはPDFプラグイン側で処理をしない限りプラグインからの出力が一切取り込まれません。最近はcalendar系のプラグインなど、外部ページを取り込んで表示するものが増えてきたこともあり、どうしたものかと考えています。選択肢としては以下の３つと考えています。

• あまり活用されていないようであればPDFプラグインは削除する。
• PDFプラグインは今のまま残す。プラグインの出力が反映されないのは仕方ないと諦める。
• プラグインからWiki形式のテキストを返却するように変更すればPDFに反映させることができる。理想的だが大改造が必要な上、全体的なパフォーマンスが落ちる。

ご意見をお待ちしています。

• 社内でのドキュメント作成時にWikiでとりあえず書いてPDFで出力ということはたまにします。ただそのようなページはプラグインはほとんど使わないので今のまま残してプラグインの出力が反映されないのはあきらめるを選択します。というかpluginの反映は特に必要ではないです。。 - tinsep19 (2003年05月22日 22時22分06秒)
• 私もたまーにＰＤＦで出力はしますが、プラグインの反映は無くても問題ないです。希望は選択肢の２つ目です。 - tpircs (2003年05月23日 09時38分04秒)
• PDFは大して使用しておりませんが、3番目の方法はそんなにコストが掛りますか？とりあえずPDF用にtextを返すメソッドを追加して、includeと同等な処理をすれば改造も少なくパフォーマンスの影響もPDF生成時のみに抑えれると思うのですが。 - typer (2003年05月24日 15時23分20秒)
• 本件からちょっと拡大した話になりますが、プラグインの出力をどう処理すべきかについて、約束ごとがあると良いと思います。例えば、プラグインの出力中にWikiNameがある場合に、それをhtmlに変換するためのサブルーチンを通すのを基本とするとか、あるいは自由で良いことにしておくのかとかが決まっていないと、後々プラグインの整合が取れなくなってくると思います。 - Kinsan (2003年05月24日 21時14分56秒)
• 今のところプラグインからはHTMLを返す（パーサ側での再処理は行わない）という仕様です。というか、プラグインから出力されたHTMLにWikiNameが含まれていても今のパーサでは処理できないと思います。また、仮にPDF絡みで中間形式での出力を採用する場合は当然パーサ側で全て処理することになります。 - たけぞう (2003年05月25日 00時00分16秒)
• 希望ということでいうと、wikiで画像まで置いたものがpdfになるとコンテンツ作成という側面でかなりうれしいです。 - Lef (2003年05月28日 02時45分18秒)
• 確かに私も画像が貼れると嬉しいのですが、一部のプラグインだけに対応するというのはちょっとと感じる点、画像といってもJPEGしか対応できないという点、PDFでプラグインを考慮しないことで行中でのプラグイン展開が可能になるという点などから3.4ではPDFに一切プラグインの出力を反映させないようにしようと考えています。・・・しかし、悩ましいです。 - たけぞう (2003年05月29日 18時50分11秒)
• 自分のわがままを書くのは気がひけるのですが、(勝手に)議論だとおもって書いてみます。せっかくのpluginの結果が反映されないとPDF出力の魅力が失われちゃうなあ、という思いがあるのと、PDF出力や(現在はtoolとして提供されている)静的なHTML出力ができると、スナップショットとしても使えるし、多人数でのCMSとしても魅力があがるかなあ、と。wikiってコンテンツの「リリース版」がつくれないって残念だな、と思うことがあるんで。(と書きましたが、ソースをちょっと眺めただけではありますが、確かに大変ですね…) - Lef (2003年05月30日 05時15分37秒)
• プラグインをPDFに反映させるなら全てのプラグインを反映できるようなフレームワークを提供したいと思うのです。なので3.3.xのようにPDFパーサ側で一部のプラグインだけに対応するというようなアドホックな作りはどうかなぁ、と。 - たけぞう (2003年05月30日 10時30分56秒)
• 以下プラグインという枠での話です。プラグインはほとんどが３種とその組み合わせに分けれます。１つはほぼ文字情報でwikiフォーマットで表現できるもの、１つはリンク（GETメソッド）を作るもの、最後の１つがフォームを作るもの。で、リンクも別名リンクと組み合わせてwikiにし、wikiへの変換とフォームへの変換の２段処理とすればフォーム以外PDF化できると思います。パーサはまず、プラグインの前処理メソッドを使ってリンクとwikiテキスト化できる部分はwikiにしてもらい、出来ない部分はプラグイン（たとえばfoge_formプラグインは存在しません。）として変換する。そのあとで他の書式も含めて順次HTML化・PDF化し、その過程で残されたプラグインの処理であるフォームの出力をHTMLで行う。このときPDFではフォームは必要ないですから空白や記号としてしまう、またはプラグインのメソッドとして代替テキスト（altですね）を用意する。class指定やその他表現方法に制限が出てきますが、XSSへの対策にもなるだろうし、こういった仕組みはどうでしょうか？ - typer (2003年05月31日 16時45分00秒)
• いまのpdfの扱いが特例で、フレームワーク化されるのはめちゃくちゃうれしいです。typer氏のコメントは、かなり具体的なので魅力を感じます。結局、filter pliginといった感じで、プラグインにも種類をつくって処理する位置をわけてやる必要があるんだろうなあ、と。たけぞう氏のいうフレームワーク化と合致する方向性だといいのですが。(というかいい加減ソースみろ>自分) - Lef (2003年05月31日 21時13分49秒)
• pluginを作る側としては、wikiを吐かせる方が簡単でいいです。inline_wikiメソッドとかで拡張してwiki形式を吐くpluginも作れるとありがたいなあ - matto (2003年06月27日 15時43分43秒)

 添付ファイルのリンク表示 - しお (2003年05月22日 12時12分05秒)

FreeStyleWiki3.3.7 を使用しています。任意のページにファイルを添付すると例えば、ここのダウンロードページのようにページの最下部に添付ファイルの一覧が付加されると思うのですがうちの環境では表示されません。サーバ上のattachフォルダの下にはファイルは作成されているしページ右上の「添付」をクリックした場合にはファイルのリストは表示されます。

• このサイトではFooterにfilesプラグインを記述しています。 - たけぞう (2003年05月22日 14時38分22秒)
• なるほどFooterページを作ってfilesプラグインの記述をすればよかったのですね。 - しお (2003年05月22日 17時01分45秒)

 ページ削除のOperaへの対応 - Kinsan (2003年05月21日 15時08分16秒)

作成したページを削除しようと"修正"で中身を空にして保存しても、ブラウザーとしてOperaを使っている時には\r\nが残っているために中身が空にならず、ページの削除になりません。そこで、plugin/core/EditPage.pmの38行目(保存処理の先頭)に下記の処理を追加したら、うまくいく様になりました。

$content = '' if($content =~ /^[\r\n]+$/s); # added for opera

この問題はOperaが原因でしたが、中身が空行のみのものは作れない方が良かろう、とも思えます。

• そうですね。次のリリースで取り込みます。 - たけぞう (2003年05月22日 12時01分15秒)

 メール通知に関する要望 - amn (2003年05月10日 21時45分52秒)

メール通知機能ですが、当方の環境ですと sendmail を利用していないので現在りようしておりません。

そこで機能要望となりますが、smtp server を指定しておくと、smtp 通信してメールを送信してくれるような方法にも対応していただけると幸いです。

• 将来的には実装したいです。とりあえず3.4ではメール送信処理をフックで起動するように変更しているので差し替えは可能です。 - たけぞう (2003年05月22日 12時02分46秒)

 ファイル作成権限 - amn (2003年05月10日 18時44分30秒)

いつもありがとうございます。便利に使わせていただいております。

私の環境でうまくページ更新ができないことがあったので、現在、setup.pl の中に umask(0); の記述をいれて対処しています。このままでも良いのですが、よろしければ wiki.cgi に取り込んでいただけると嬉しいです。

• これはファイルの所有者やパーミッションの問題ではないでしょうか？もしそうであれば環境に依存する対処ですので面倒だとは思いますがsetup.plで設定していただいたほうがよいでしょう（もともとそういうカスタマイズのためにsetup.plを分離しているという意味もあります）。また、umaskはセキュリティ上使用を禁止しているサーバもありますので、wiki.cgiには取り込まないつもりです。ご了承ください。 - たけぞう (2003年05月13日 10時18分02秒)
• コメントありがとうございます。なるほど、了解です。 - amn (2003年05月13日 11時01分54秒)

 外部ページへのリンクを別窓で表示 - Zero (2003年05月10日 02時08分25秒)

ページリンクのアンカータグにTARGET属性を付加しただけですが(^^;外部ページに飛んだときに自分のページの表示が消えるのがいやな人はどうぞ(笑)変更するファイルは「lib\Wiki\HTMLParser.pm」の291行目です。

-		return "<a href=\"$url\">".Util::escapeHTML($name)."</a>";
+		return "<a href=\"$url\" target=\"_blank\">".Util::escapeHTML($name)."</a>";