トップ 差分 一覧 Farm ソース 検索 ヘルプ RSS ログイン

雑談掲示板

ページの作成や編集にはユーザ登録が必要です。

FSWiki雑談掲示板

サポート掲示板は質問などの書き込みが主になっているようなので、FSWikiを使っての感想など、些細なおしゃべり・雑談の場合はこちらをお使いください。話が盛り上がってきたら適宜、サポート掲示板などに話題を移行させるような感じでの使い方もできるかもしれません。

  • 過去ログはページ下部の選択肢から参照できます。
  • 件数が増えてきたら古いものから順に過去ログに移動します。
  • 雑談掲示板一覧もどうぞ。
  • 設置に関するトラブルや要望などはサポート掲示板のほうにお願いします。
  • バグ報告に関してはバグトラックのほうにお願いします。
  • FSWikiとは無関係と思われる投稿、コメントに関しては削除させていただきますのでご了承ください。
お名前
件名
本文

子Wikiにも親Wikiの設定を反映したい - CAN (2007年12月22日 18時23分23秒)

はじめまして。早速の質問失礼します。親Wikiの管理ページでの設定(プラグインのON/OFF等)を即座に子Wikiに反映させる方法またはプラグインをどなたかご存じないでしょうか？親Wikiと子Wikiを別々に設定しなくてはならず大変なのでお力をお貸ししていただけると幸いです。分かりにくい文章になりすみません。

  • この機能は実装されていませんね。CANさんの仰るように、ルートWikiで全Farmのプラグイン管理を行えると便利だと思います。 - A_M (2007年12月24日 13時41分27秒)
  • そうですか。分かりました。A_Mさんどうもありがとうございました。では、今のところは現状どおり別々に設定をするようにします。 - CAN (2007年12月24日 18時04分31秒)
お名前： コメント：

Picasaウェブアルバムの画像を貼りたい - 名無しさん (2007年12月05日 18時00分49秒)

要望掲示板に書くほどの内容でもないかと思うのでここに書かせてもらいます。Picasaウェブアルバムの画像へのリンクを貼りたいのですが、htmlタグをそのまま書いてもリンクは貼れないですよね。あちこちのページに多数貼りたいのでinclude_htmlプラグインでは面倒なので、もっと簡単に貼れるプラグインをどなたか作っていただけるとうれしいのですが。

  • 『Picasaウェブアルバム』自体がよく分らないのですが（単に勉強不足なだけです。すみません）、画像へのリンクを貼りたいだけでしたら、装飾用HTMLタグプラグインのa_imgで実現できないでしょうか？ - あき (2007年12月14日 23時42分40秒)
  • サービス名だけでなくどういうタグなのかも書けばよかったですね。すみません。Picasaウェブアルバムの画像へのリンクはサムネイル画像を表示して、ウェブアルバムの元画像へのリンクが貼られる物です。 - 名無しさん (2007年12月17日 10時26分37秒)
お名前： コメント：

ログインしたときにだけ表示されるメニュー - 名無しさん (2007年11月17日 01時08分14秒)

サイドメニューで、通常は表示されないけれども、ログインしたときにだけ表示されるようなメニューの作成方法はどうすればいいのでしょうか？

いままでは一覧から選んでいたんですが、ページが増えると下のほうに行くので時間がかかり、現在はIEのお気に入り登録している始末です・・・

もっとスマートな方法はないものでしょうか？

  • すみません、自己解決しました！！　こちらに今回の件とは直接関係はありませんが「･･･参照権限のないページを見せない部分入れて･･･」という記載があり、もしや？！と思って、categoryプラグインでMenuを作成し、表示したくないページだけ管理者権限にしたら、望みどおりの結果になりました。 - 名無しさん (2007年11月17日 01時19分01秒)
  • categoryでリスト表示させるときには、それを表示しているユーザー権限に依存するんですね。知りませんでした・・・。 - 名無しさん (2007年11月17日 01時22分33秒)
  • BugTrack-theme/20に書いたレイアウト・プラグインとそのテンプレート（のonly_logon ログイン時のみ表示）を使った方法の方が、スマートな気がします。categoryでのリスト表示がユーザー権限に依存する、というのは、偶然を利用しているっぽい感じでスマートではないかも…。本人の自由ですが…。 - あき (2007年11月17日 08時09分38秒)
お名前： コメント：

ドキュメントが見れない - 名無しさん (2007年11月11日 02時43分03秒)

Lock is busy. at plugin/core/ShowPage.pm line 68. at lib/Util.pm line 684.

ドキュメントを見ようとすると上記のエラーが表示されて見れません。私だけでしょうか？

  • BBS-サポート掲示板/575に書かれている対処法は？ - 名無しさん (2007年11月11日 11時21分16秒)
  • 公式サイトのドキュメントのWikiが参照できないということですよね。公式サイトをmod_perlからCGIに変更して動かしているのですが、その影響のようです。しばらくお待ちください。 - たけぞう (2007年11月11日 21時52分31秒)
  • たけぞうさん 言葉足らずですみません。その通りです。また当方でも正常に見れるようになった事をご連絡致します。ご対応有難うございました。以上 - 名無しさん (2007年11月13日 14時03分58秒)
  • 一時的にmod_perlからCGIに変更しています．とありまして、私も通常のperlに変更しようとしていますが、上記エラーが出て困っています。どこをどのように直したら、通常のperlで動くようになりますでしょうか。。 - ゆう (2008年04月09日 16時29分44秒)
  • たけぞう様しかわからなそうですね。。　尚、今まで動いていたので、パーミッション等は間違いありません。 mod_perl の環境下であれば、正常動作します。 - ゆう (2008年04月10日 08時53分22秒)
  • mod_perlに関するバグが何点か表面化しているため，一時的にmod_perlからCGIに変更しています． この時の変更手順について、誰かわかる方がいらっしゃったらコメントお願いします。　因みに、wiki.cgi はいじっていません。。 - ゆう (2008年04月10日 11時07分22秒)
  • 普通に考えたらApacheの設定でしょ？ - 名無しさん (2008年04月11日 05時01分16秒)
  • Apache　は、通常の CGI は動作し、mod_perl の部分は、削除しています。 - ゆう (2008年04月11日 09時27分29秒)
  • Apacheの設定 じゃありませんでした。書き込みするログファイルの所有者の問題でしたね。　どうもありがとうございました。 - ゆう (2008年04月11日 10時02分06秒)
お名前： コメント：

レンタルサーバー上のdataフォルダ内のファイルがダウンロード出来ない - 名無しさん (2007年11月04日 13時30分46秒)

dataフォルダ内の%のついたエンコードされたファイルがダウンロード出来ないのです。サーバーは http://2nd.cssv.jp/ のレンタルサーバーになります。FTPツールはFFFTP 1.92aを使っています。他のサーバーではエンコードされたファイルも問題無いようです。確認ポイントについてどなたか教えていただけないでしょうか。

  • FTPサーバに問題があるのではないでしょうか，サーバ屋に問い合わせたほうが早いと思います． - sakuma (2007年11月05日 07時37分35秒)
  • サーバ屋に問い合わせしたところ、あっけなく解決しました。セキュリティ対策で禁止してましたがftpdのバージョンアップで対応したことから禁止解除したとのことでした。こんなこともあるんですね・・・ - 名無しさん (2007年11月12日 23時18分16秒)
お名前： コメント：

calenderでのyyyy年mm月dd日（曜日）の形式にするには - 名無しさん (2007年10月29日 22時51分01秒)

calenderでの表示をyyyy年mm月dd日（曜日）の形式にするにはどの様な修正でorどこを修正すれば良いハズなのでしょう。挑戦してみましたが、挫折状態です。また、既に予定はいくつか登録済みですのでページ名を変えない方法が希望です。

  • calnderプラグイン内部でリンクされた該当ページを表示したときに表題の形式をご希望なのでしょうか。Wikiページとしては「カレンダー名/YYYY-M-D」の形で保存する仕様（BugTrack-plugin/292?利用時は、「カレンダー名/YYYY-MM-DD」）ですので、API（wiki->wiki_anchor）の内部でカレンダー仕様のページ名の時には表示を矯正するなどの方法もあると思います。 - A_M (2007年10月30日 02時18分58秒)
  • プラグインから、タイトル、本文が渡ることを期待して調べてみてましたが、calenderのプラグイン部分を覗いただけではわからなかったわけですね。該当ページを表示したときに表題の形式以外にも、futurecalendarプラグイン、recentcalendarプラグインでの表示でも形式を変えたかったのです。API（wiki->wiki_anchor）を書き換えればとことですが、この辺に関する記事、情報はどこにあるでしょう。やはりソースでしょうか。それなら、気長に挑戦してみます。 - 名無しさん (2007年11月01日 21時53分46秒)
  • 「Calendarプラグインで表示されたリンクから開く各Wikiページの表題…」と考えていましたが、BugTrack-plugin/265のようなプラグインも有ります。各ページは、仕様に合わせたページ名となりますが、分かり易い一覧表示が特徴のプラグインです。 - A_M (2007年11月07日 18時12分56秒)
お名前： コメント：

「actives」プラグインは、どこから？ - おにはそと (2007年10月24日 04時25分06秒)

2005年04月01日の「ログイン履歴について」で述べている「actives」プラグインは、どこから入手するのでしょうか？

  • BBS-雑談掲示板/111を参照しましたが、ログインしたユーザの履歴を取る機能は現在も未実装です。ログインのアクションでログを記録し、そのログを元にWikiページに表示する等カスタマイズが必要です。 - A_M (2007年10月24日 06時01分26秒)
  • 「actives」プラグインを入手しました。 - おにはそと (2007年10月24日 09時49分49秒)
お名前： コメント：

CMS向け拡張パックの開発を再開します - あき (2007年10月09日 13時40分05秒)

近日中にCMS向け拡張パックの開発を再開します。

下記に示すような手順での設置ができるようイメージしています。

年内のβ版リリースを目標とします。（バージョン3.6.3[1]のリリース直後くらい？）

開発方針

  • インストールCGI（インストーラ）を同時提供することにより、簡単な設置ができるようにする。インストールCGI自体は、それ単体で（拡張パックを含まない）本家オリジナル版も設置可能なものとする。
  • 既存のサイトからの拡張パック適用は考えない（新規設置に限定する）。以前は、既存運用中サイトからの移行も可能なよう設計していたが、複雑になりすぎるうえ、実装できる機能が限られてしまうため、断念する。設置ディレクトリやディレクトリ構成の指定、パーミッションの設定等にも対応できるようにする予定。
  • まずはCMSとしての機能ではなく拡張パックとしての機能を優先する。できればそこまではなんとか年内に対応し、リリースしたい。
  • 個人的にはCMS向けの拡張パックを目的とするが、他の目的向けの拡張パックも作成できるよう、拡張パック開発のベースとなるものを確立する。
  • 携帯端末からの閲覧にも考慮する。

インストールCGIについて

インストールCGI実行手順

次のような手順でFreeStyleWikiが設置できてしまうような仕様を考えています。

  1. 本体をバージョン番号付きのディレクトリ名で展開する。（つまり本体のZipファイルを解凍してサーバにアップロードする）
  2. 拡張パックをバージョン番号付きのディレクトリ名で展開する。（本体と同様サーバにアップロードする）
  3. 必要に応じてinstall.cgiの先頭行を修正する。
  4. 必要に応じてinstall.cgi実行権限を与える。
  5. ブラウザ上からinstall.cgiを実行する。
  6. 指示に従ってセットアップする。

そう、たったこれだけです。これだけでセットアップできてしまうものを考案中です。

インストールCGIに盛り込む機能・制限

  • 任意のディレクトリに、任意のディレクトリ構成でセットアップできるようにする。
  • インストールする拡張パックの種類を選択できるようにする。
  • 本家（本体）最新バージョンのみを対象としてメンテナンスしていく。以前は本体のバージョン毎に柔軟に対応する仕様を考えていたが、複雑になりすぎて管理しきれないので最新バージョンのみに対応することにする。新規設置に限定することにもしたので特に問題はないと思われる。
お名前： コメント：

新コーナーの設置を計画中。（力を貸してください） - あき (2007年10月09日 13時18分42秒)

構想から２年も経過してしまいましたが、近々、新コーナーの設置をすべく検討しています。

詳細については後述する引用文をご覧頂きたいのですが、要はカオス状態と化してしまっている投稿プラグイン群を整理して有効活用してもらいましょう、有志のプラグイン開発者の力を十分に活かしてFSWiki開発の活性化を促して行きましょう、といった試みです。

是非この試みに、皆様のご意見をお寄せ下さい。賛同して頂ける方がいらっしゃいましたら、是非ご協力下さい。

話の発端

2005年8月26日のメーリングリストへの投稿が発端です。もうかなり前です。（汗）

内容の抜粋

　
　　　　　：
　
前回のメールにも書きましたが、
-----------------------------------------------------------------------
・・・、現状の投稿システムは投稿者が主体で、オフィシャルサイト側
としては、何ら干渉もせず、保証もせず、の状態ですから・・・。
-----------------------------------------------------------------------
こういった部分は改善できるなら改善していくべきかもしれません。
「自分が便利だと思う物を作ったよ。同じように便利だと思う人は使ってね。そ
の代わり自己責任だよ。」という人もいれば、「自分が便利だと思う機能を作り
ました。同じように便利だと思ってくれる人がいれば使ってください。何か問題
点や要望が有れば改良しますので言ってください。」といった人もいるわけで、
これら両者を混同してしまう現状のシステムは、惜しいことをしていると思いま
す。
前者のような有志者の力はとても有力ですし、プロジェクト運営者側としては、
こういった有志の力は大いに活用すべきだと思います。

そこで、私が考えた案ですが、

（実は前回書いておきながら、送信を見送った部分です）
----------------------------------------------------------------------
『承認システム』の導入
現状では、本家の機能を無視したもの（例えば、Farm機能に未対応のもの）や、
対応バージョンが記載されていないもの、セキュリティ上の問題を抱えている
もの、の区別が全くされないまま共存してしまっています。
作者（竹添殿）に認められたプラグインについては、ステータスが「リリース
済み」となり、互換性が保証されますが、そうでないプラグインでも、有用な
プラグインは数多くあり、問題を抱えているプラグインと切り分けがされてい
ません。
これでは、ユーザは混乱するばかりです。（現状がそうです）
ですので、投稿されたプラグインを審査する機構を設け、それに合格したもの
については「提案」以外のステータス、合格しなかったものについては「却下」
とするのです。（「保留」というのがあるので、そちらでも良いかもしれませ
ん）
「却下」とする場合は、そう判断した理由をコメント欄に記載し、プラグイン
作者の自発的な修正を促します。このようにすれば、良質な（互換性のある）
プラグインのみが生き残るでしょう。
ディストリビューションという展開になった場合も、特定のディストリビュー
ションに限定したプラグインであれば、ステータスは「却下」としてしまえば
良いのです。
たとえ「却下」となっていても、使う側がその問題点を理解し、それでも可と
判断すれば使うでしょう。
問題は、誰が審査するのか、というのと、現状のbugtrackプラグインのままで
は運用が厳しい、というところでしょうか。
他にも問題点はあるでしょうが、こういった方向で考えていくのはいかがでしょ
う？
----------------------------------------------------------------------

というのがあります。
実際には現行のものを置き換えるのは大変でしょうから、新たにそういった
コーナーを新設する、という方法でも良いかと思います。
コア標準のプラグイン（及びコア拡張）として取り込んでもらうことを目的に
投稿を行うコーナーを新設するのです。（今までのように、「使いたい人は使っ
て」ではなく、「こんなの良いと思います。採用して頂けませんか？」というコ
ーナーです。明確な違いだと思います）
もちろん本体への取り込みを意識しての投稿な訳ですから、いくつかの制約
（例えばGPLライセンス固定、メンテナンス義務等）を設けるのも有りだと思い
ます。
オープンソースなので強制は難しいかもしれませんが、『本体に採用するための
条件』という名目であれば納得して頂けると思います。

現状のような「投稿者主体、干渉もせず、保証もせず」の状態では有志の力が
活かしきれないと思います。
誰しも、他人のソースは触りにくいですが、自分が作成したソースならメンテナ
ンスも容易なはずです。
そもそもの投稿の動機はボランティアなわけですから、上記のようなシステムに
すれば（『開発者の一員』という意識を持たせることができれば）、メンテナン
スに前向きに協力してくれる有志者も増えてくると思うのです。

＃同じプラグイン作成者として、自分が作成したプラグインが公式に認められる
＃というのはやはり嬉しいものです。その嬉しさのあまり、「もっと頑張ろうか
＃な？」って気になりますし、それは私だけじゃなく他の作成者も同じだと思い
＃ます。

有志者への動機付けに成功すれば、プロジェクト全体にも活気が出てきますし、
開発速度という意味においても、相乗効果が期待できるのではないかと思います。

新コーナーの概要

大雑把に言いますと、プラグイン投稿に寄せられているプラグイン群から有用なプラグインをピックアップして『厳選プラグイン一覧』として体系化することを考えています。

次のような運用方法を考えています。（まだ構想している段階ですので、よりよい案がございましたらご意見をよろしくお願い致します）

  • 有用なプラグインをユーザの方々に推薦してもらう。（メンテナンスをお願いしたいので自薦を推奨）
  • 承認機構を設け、承認されたプラグインだけを厳選プラグインとして登録することにする。
  • プラグイン作成者には可能な範囲でメンテナンスを行ってもらう。（安全性や互換性の向上、他プラグインとの仕様統一、ドキュメントの充実等）
  • プラグイン・テスターを募り、推薦されたプラグインが厳選プラグインとしての基準（内訳に関しては後述）を満たしているかのチェックを行ってもらう。問題があればプラグイン作者に改善を依頼し修正してもらう。
  • 形式を統一し、統一された形式でアップロードする。
  • 検索性の向上ため、ジャンル分けをして（現行のプラグイン投稿のコーナーとは分けて）管理する。（添付ファイルの置き場所はプラグイン投稿のコーナーで可）

こうして厳選されたプラグインは、開発者の目に留まれば本体へ取り込まれたりするかもしれません。本体には取り込まれなくても、将来予定されている拡張パックに取り込まれる可能性は高いです。（ちなみに私はCMS向け拡張パックを作成します）

厳選プラグインとしての基準

現時点では次のような基準を考案しています。もっと詳しく詰めたいので、皆様のご意見をお待ちしています。

  • 安全性が考慮されているか？（XSS等に利用される心配がないか、等）
  • 互換性が考慮されているか？（Unix系サーバ、Windows系サーバの両方で動作するか、等）
  • 他のプラグインとの互換がとれているか？
  • ドキュメントが充実しているか？
  • ユーザサポートが可能か？
  • ライセンスはGPLが理想。（GPLでなくても良いが、GPLでないと本体への取り込みや拡張パックへの取り込みが難しい）

コメント

  • 皆様のご意見をお聞かせ下さい。特になければ作成してしまいます。 - あき (2007年11月14日 10時58分24秒)
  • 投稿プラグインの利用者として、また、いくつか「自分で欲しいので作ってみました」的なライトな作者として、これは歓迎する事だと思います。プラグイン数が一定数を越えると、評価、あるいは目安にできる何かが必要だと考えるからです。(閑話休題) さて。分けるというよりは属性のようになると思いますが、「通常プラグイン」「管理者プラグイン」「関数上書き系プラグイン」(_ex_で始まるやつですね、もっといい名前があるといいですが)「diff(パッチ)系プラグイン」といった情報がプラグインに付属すると嬉しいかな、と思います。導入の難易度ともかかわってくると思いますので。よもやまな発言でした。 - ZON (2007年12月01日 20時39分54秒)
  • コメントに気付いてませんでした。ご意見どうもありがとうございます。一応最初に考えた案でいくつかのページをローカル上で作成してみてはいるのですが、皆さんに評価して頂くためにはもう少しサンプルとなるページ数を増やさなければなぁ、と思っています。とりあえず現状のものをアップしてみようかな？　あぁ、でも時間が…。 - あき (2007年12月15日 00時10分06秒)
  • どこでどう名乗りを上げたらいいのか迷ってますが、まずはここで。 いきなりMLにメール飛ばしたり、登録は気が引けたので・・・(^-^A;) 自分はWeb系ではないですがテストの仕事をしているので、テスト方面でお手伝いができればと思っています。 普段お世話になっているので、お手伝いができればと。。。 - とものぶ (2007年12月17日 22時05分47秒)
お名前： コメント：

「画面右上のページ名をクリックした際の検索」機能のカット - 名無しさん (2007年09月10日 15時35分52秒)

デフォルトの状態だと画面右上に表示されるページ名をクリックすると、ページ名による検索画面が表示されます。

この機能をカットしたいのですが、「searchプラグインの機能を維持したまま」、当該ページ名検索機能だけカットする方法をどなたか教えていただけないでしょうか？？

  • wiki.cgi の 151行目付近の下記の部分を修正して見てください。 - KG (2007年09月10日 17時43分34秒)
	# ページのタイトルを決定
	my $title = "";
	if($cgi->param('action') eq "" && $wiki->page_exists($cgi->param('page'))){
		$title = "<a href＝\"".$wiki->config("script_name")."?action=SEARCH&amp;word=".
		       &Util::url_encode($wiki->get_title())."\">".
		       &Util::escapeHTML($wiki->get_title())."</ａ>";
	} else {
		$title = &Util::escapeHTML($wiki->get_title());
	}

wikicgi(151行目)の上記部分を下記のように変更

	my $title = &Util::escapeHTML($wiki->get_title());
  • 機能のカットが出来ました！ありがとうございます！ - 名無しさん (2007年09月11日 09時41分14秒)
お名前： コメント：

[ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 ]

  • [1]3.6.3を選んだのは期間的に妥当なのと3.6.3ではかなり大幅な改造が加えられているため。（複数行プラグインが利用できるようになっていたり、表示速度等が大幅に改善されていたりします←と思いましたが、表示速度に関しては今のところ良く分かりません。理論的には速くなっているはず）

最終更新時間：2014年08月28日 09時33分14秒

メニュー

関連リンク

入門Wiki〜みんなで投稿/編集できるWebの作りかた

検索

キーワード

Google

Google

最新

2023/3/30

2023/3/29

2023/3/22

2023/1/31

2023/1/23

Copyright (C) 2002 Naoki Takezoe
Powered by FreeStyleWiki3.6.5 with Perl5.020002