Page :: FSWiki / Plugins / attach関連

FSWiki/Plugins/attach関連

〜編集中〜

概要

FSWiki標準のattachプラグインを使用すると添付ファイル名はエンコードされてしまい拡張子が無くなってしまう為、直接参照することが出来なくなります。これは、画像等をサイトに表示したい場合に必ずwiki.cgiが呼び出されてしまう為、システムに負荷がかかってしまいます。

これを軽減できないかと考え、ここでは、添付ファイルの拡張子を有効にし、ref_image等のプラグインでwiki.cgiを経由せずにアクセスできるようにする為のパッチを提供します。

既に、このサイトではこの修正を適用して、画像ファイルに対しては直接参照するという形式を採用しています。

修正箇所

この修正では、添付ファイルのドット"."をエンコードしないように修正し、更に ref系プラグインの参照もドットをエンコードしないファイルにリンクするということを行っています。

修正箇所はかなり広範囲となり、また、修正適用後は既存の添付ファイルのドットがエンコードされたファイルが参照できなくなる為、手動で添付ファイル名を変更しなくてはなりません。ですから、この修正を適用するのは運用開始前、もしくは添付ファイルがまだ少ないFSWikiのサイト等が宜しいかと思われます。

また、この修正適用後は、IE等の持つページの保存機能で画像ファイル等も保存できるようになります。

現在、この修正箇所を公開用にまとめるのに時間がかかっておりますので、暫くお待ちください。


Comment(16)
  • まだ編集中とのことですが、コメントしても大丈夫でしょうか? 例えば写真集とかのページを作ると、凄い遅いですよね。画像ファイルが何十ファイルも有ると確かに使いものにならないくらい遅くなります。それを直リンクにしてみたら半端じゃなく高速に表示されるようになったのを記憶しています。ただ、これをやると非公開ページに添付された添付ファイルまで(ファイル名が分かれば)見れてしまうんですよね? 竹添殿がそれを気にされてましたので…。私は、それに関しては「他の一般的なサイトでも同じでしょう?」ということで気にしてません。だって、ファイル名が分からなければ開きようがない分けですから…。 - あき (2005/11/07-07:29:52)
    • 例えば、私の設置しているサイトで言うと、fswiki下のディレクトリでは参照できるファイルを制限しています。つまり、*.cgi と 画像ファイル のみです。ですから、たとえ直で zip ファイル等にアクセスしようとしても、アクセスできないようになっています。画像の場合は直リンクを貼っても問題ないかと思っています。このような運用が可能なサーバー等を利用すればこれらの修正は有用だと考えています。 - KG (2005/11/07-09:57:21)
  • かなり古い記事に対する書き込みになりますが…、CMS的な用途を考えると、画像ファイルの表示の遅さは致命的と言わざるを得ないかもしれません。画像集とか、写真館とかって感じのサイトを立ち上げている人は結構いますので…。やはり、せめて画像ファイルだけでも、高速な直リンクは必要なのでは?と考えています。 - あき (2006/02/24-01:41:44)
  • そうですよね。ただ、それには"."をエンコードしないようにしないといけないのです。拡張子の判断が付かないとWebサーバーが混乱しますので・・・。そもそも、FSWikiにて"."をエンコードする理由はなんなんでしょうね?上にも書いてますが、この修正を行うには非常に範囲が広いのです。しかも既に運用中の場合はエンコードされた"."が邪魔してしまうので・・・。移行ツール等を作成する必要もあります。また、他のプラグイン等の添付ファイル周りの処理にも影響してしまいます。 - KG (2006/02/24-02:00:23)
  • FSWiki4.0ではファイル名の"."エンコードをやめて欲しいのが本音なんですけどね・・・。 - KG (2006/02/24-02:02:29)
  • そうですねぇ。ページへの添付とその読み出し、という考えで考えると「.」のエンコードは問題の種となりますね。ただ一つ疑問は、エンコードの件が解決されたとして、直リンクの時のURIはどのようになるのでしょう? data_dir下の参照を許可するのですか?そうした場合、theme_dirに対するtheme_uriのようにdata_dirに対するdata_uriを定義する必要も出てきますし、.htaccessが利用できないサーバではセキュリティが怖いことになってしまいそうです。(違っていましたらすみません) 代替案として、theme_dir下にcommon_imagesなどというサブディレクトリを設け、このディレクトリに関しては書き込みも可としたうえで、従来からあるattachやref_imageといったプラグインを別途作成し直し、保存先をtheme_dir/common_imagesになるようにすれば、直リンクはtheme_uri/common_imagesとすればいいわけで、比較的丸く収まるのでは?と思ったりもしています。非公開にしておきたい画像ファイルがある、という考えも尊重するなら、別作成になるのは致し方ないかな、と…。 - あき (2006/02/24-13:09:53)
  • 私の所の環境で言えば、attach_dir に対し attach_uri を定義して、それに合わせて ref_image を修正しています。もちろん、"." の問題も全てのプラグインを見直して解決しているというわけなのですが・・・。data_dir は公開する必要はないと思いますよ。あと、画像ファイルのみ .htaccess で参照可能にしていますので、直リンクで取得できるのは画像ファイルのみとなっています。非公開画像等には対応できませんが、・・・というか非公開画像に関しては考えていませんね。こういうことを踏まえると、表示画像用に新規ディレクトリを作成(image_dir, image_uri)して、専用の添付機能を用いるしかないでしょうね。{{img_attach}},で添付フォームを表示して {{img [ページ名:]ファイル名}} で画像表示とかにしましょうか?・・・あ、{{img}} って既にありましたね。(笑) - KG (2006/02/24-13:24:27)
  • あ、失礼しました。ご指摘のとおり添付ファイルはdata_dirではなくattach_dirでしたね。何を勘違いしたのやら…。(汗) 個人的にはattach_dirの画像ファイルだけ、の案は好ましいとは思えません。後者のimage_dirの案は、従来の構成のままで実装できないのが悩みどころですが、仕様的にはスッキリしていて良いと思います。imageは、やはり意味合い的にthemeとは別モノですからね。後はコア側のソース、どの程度少ない修正で実装が可能か次第でしょうか。1行追加、等で済めば良いのですが…。 - あき (2006/02/24-16:59:49)
  • 後者の image_dir, image_uri の仕様は、コアへの修正は必要ないのではないかと考えています。完全なプラグインという形式(オーバーライド無し)で導入するつもりです。 - KG (2006/02/24-17:07:24)
  • あ、setup.datへの追加(image_dir, image_uri)は必要ですね。 - KG (2006/02/24-17:08:13)
  • あ、コアへの修正不要でできます? setup.datで指定するだけで読み込み対象になるんでしたっけ? setup.datへの追加程度であれば、何も問題ではないと思います。 - あき (2006/02/24-17:41:54)
  • 読込み対象というか、直リンクを貼るわけですからパーミッションの設定は必要になりますね。あと、画像添付に関しては別途プラグインでサポートするということになります。エンコーディング仕様も独自(とは言っても"."をエンコードしないだけですけど)仕様になりますね。落ち着いたらβ版として公開します。(FSWIKIのTODOがドンドン増えるぅ・・・笑) - KG (2006/02/24-19:19:43)
  • imageプラグインのβバージョンを公開しました。 - KG (2006/02/26-16:52:50)
  • いつの間にか作成して下さってたんですね。負担をかけるつもりはなく、途中まで自分で作成していたのですが…。(HTML装飾用プラグインのa_img,imgに相当するものは作成したのですがattach部分はまだでした。対応が速いですね) ありがとうございます。早速使わせて頂きます。 - あき (2006/02/27-13:28:44)
  • フッタに画像を設定しても、他のページから見えないのでは意味がないなと思います。 - 一本SEO (2008/09/26-12:37:26)
  • どういう意味でしょうか?imageプラグインの事でしょうか?Footerでの image プラグイン使用には ページ名を指定しないと他のページで見えなくなると思いますよ。 - KG (2008/09/26-21:22:53)
お名前: コメント:

このページのTrackback(0)

最終更新時間:2004/12/16-21:05:48