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

雑談掲示板

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

FSWiki雑談掲示板

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

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

ユーザのページ管理 - こま (2006年03月22日 01時26分32秒)

パート編集の際、ユーザが各パートを凍結できるように(つまりはパート単位の編集権限の設定)はできませんかね?こんなことを考えてます。

  1. 現在の凍結を拡張し、パート毎の凍結を行います。
  2. さらに、新たにユーザ権限での凍結を設けます。

これで管理者専用のパートとユーザが編集できるパートを、ページ内に混在させることができます。(以下管理者権限で凍結されたパートを管理者パート、ユーザ権限のものをユーザパートといいます。ユーザパートの内容は管理者権限でも編集できます。)

  • テンプレートに管理者があらかじめプラグインなどを書き込み、管理者パートとし、続く空のパートを凍結解除かユーザパートとしておく。ユーザがテンプレートを利用してページを作成する場合、その空パートに書き込む。デフォルトテンプレートの強制設定をすれば、必ず任意のプラグインを挿入できる。(もちろんメッセージも)
  • 管理者パートの一部を特定プラグインでいじれるようにする。例えばユーザパートを更にIDごとに凍結できるようにすれば、こんなことができる。ページ作成者のユーザIDをページ先頭の管理者パートに記録しておき、そのIDが編集する時はチェックボックス付きのユーザ一覧を表示する。チェックボックスは別のユーザ対する編集許可設定、選択されたユーザは協力者として編集許可を与えられる。管理者パートをページの設定に利用するわけです。

実際に便利かどうかはわかりませんが、どなたかプラグインを作っていただけませんか?

  • 上記要望の簡易的な方法としては include プラグインを用いてパート毎にページを分けてしまうという方法もありますね。その際、パートに利用するページを隠蔽できればページの乱雑さも軽減できるかもしれません。こうすれば、編集権限等は既存の凍結方法である程度は制御できるのかなと。 - KG (2006年03月22日 01時37分25秒)
  • 現在のアーキテクチャ的に,プラグインでお気軽にできるものではないですね.根本的な疑問ですが,こういう場合パートで分けずに,ページを別にしてつくってはだめなんでしょうか?1ページに大量の文字があると読みにくいので,パートを使うくらいならページを分けたほうが見るほうも書くほうも便利だと思いますよ. - sakuma (2006年03月22日 03時59分59秒)
  • 要望されている内容的には、KG殿が仰っているとおり、それぞれのパートから別ページをincludeプラグインにて取り込む、というのが正攻法ですね。FSWiki的には…。 - あき (2006年03月23日 13時20分50秒)
  • 私も、現段階では、includeプラグインの利用をオススメします。pluginhelpを見ると、「見出し」単位での取り込みも出来ますので、複数のページを持ってもらうというページ管理の煩雑さを抑えることができそうです。 - A_M (2006年03月23日 13時44分44秒)
  • なるほど、確かにincludeプラグインで実現出来そうですね。前半についてはBugTrack-plugin/80を組み合わせて何とかしてみようと思います。早速のアドバイスありがとうございます。 - こま (2006年03月23日 23時23分12秒)
お名前: コメント:

公式サイトのデザイン - 名無しさん (2006年03月20日 19時41分52秒)

公式サイトのメニューでちょっとだけ気になることが

  1. FAQとか開発方針とか子Wiki内にあるので初心者には場所が分かりづらい。
  2. Googleはサイト内検索にしたほうが良さそう。
  3. 分かりづらい文言は変えたい
  4. 設置サイトはプラグイン提供者は別カテゴリにしたほうが良さそう。
  • FAQとかドキュメントからたどるのはちょっと見づらいかなという気がします。ただ単純に親Wikiのメニューに載せると戻る時に問題になりそうですが。
  • 文言→ヘルプは「書式ヘルプ」か「Wiki文法」みたいな感じですよね?あとプラグインも標準プラグイン一覧みたいな感じが分かりやすそう。
  • 設置サイトのカテゴリ分けは出来ればやってほしいけど、面倒そうなのでやらなくても。

自分の好みなんで出来れば変えてもれると嬉しいかなという程度です。

  • メニューについては数も増えてきたし、リニューアルを考える時期かも知れませんね。子wikiのドキュメントは配布ファイルに含まれているドキュメントをおいて改善しやすい様にという意図がありますが、たしかにわかりにくく。特にFAQはもう少しわかりやすくして、更新しやすくした方がよいかも知れません。メニュー以外の編集が許可されているページは編集してもよいという事でもありますので、気がついた方が出来る範囲で編集していただきたいです。それがwikiのwikiたる所以の一つですから。 - typer (2006年03月22日 00時51分21秒)
  • FAQが見づらいというのが気になったんですよね。それで差し出がましいかもしれないですが提案しました。Googleのサイト内検索は自分は「site:fswiki.poi.jp」のオプション付きでブックマークに登録してるので問題ないですが、本家側にあったほうがいいんじゃないかなと思いました。 - 名無しさん (2006年03月22日 02時18分47秒)
  • >site:fswiki.poi.jp これは検索する際に,フォームに入れれば済むので,利用者が必要と思ったら入力するので,それでいいと思います.反対に,勝手にサイト内だけに限定されると,利用者からすると不便かと思います. - sakuma (2006年03月22日 04時01分26秒)
  • 選択は出来ますよ - 名無しさん (2006年03月22日 04時17分08秒)
Google
WWW を検索 fswiki.poi.jp を検索
  • ディストリに付属の検索プラグインについては、デモンストレーションの目的もあると思うのですよね。単一Wiki内のページ数が多すぎて、パフォーマンスを発揮できていないですけどね。 - A_M (2006年03月22日 06時49分14秒)
  • ここ自体デモンストレーションの目的がありそうですよね。そうするとLiteもデモとしてほしいかなあとか思ってみたり。 - 名無しさん (2006年03月22日 17時07分31秒)
  • 遅くなりましたがコメントを…。提案されている内容は的を射てますね。検討に値すると思います。こういった要望はどんどん出して頂けるとありがたいです。全てが全て要望に添えるわけではないでしょうが、見慣れてしまっている人間にはなかなか気付きにくい部分でもありますので…。Googleの検索ボックスですが、確かに、「WWW を検索」と「fswiki.poi.jp を検索」のラジオボタンは出した方がいいですね。ですが私はこれを「サイト内検索用に…」と考えたことはありませんでした。サイト内検索用に用いると、検索速度的には申し分ないですね。さすがGoogleって感じです。ですがこれ、当然のことですが、Googleにクロールしてもらってないと駄目なんですね。そういった意味ではsearchプラグインとgoogleプラグインの併用は必須なのかもしれません。閲覧者にとっては混乱の種となりそうな気もしますが…。すみません。話が脱線してしまいました。(^^; - あき (2006年03月23日 08時22分51秒)
お名前: コメント:

xampp - 名無しさん (2006年03月19日 19時35分44秒)

知っている人が多かったらごめんなさい。

サーバーの環境を一括でインストールしてくれるツールらしいです。Linux版とWindows版があるそうです。

インストールしてくれるのは

  • Apache
  • MySQL
  • PHP
  • Perl
  • mod_php
  • mod_perl
  • mod_ssl
  • openssl
  • PHPMyAdmin
  • Webalizer
  • BLAT Version

と、テスト環境を作成するにはなかなか便利そうな感じです。

こういうのに頼ってると自分みたいにへたれなままになってしまうのかもしれないですが、時間の節約にもなるし面倒なので今までやらなかったPukiwikiの機能も調べようとかいう気もおきてきます。

公式
http://www.apachefriends.org/en/index.html
日本語による説明とか
http://srvhat09.anaheim-eng.com/modules/tinyd4/index.php?id=2
  • 似たようなので、私は以前 SpaceTag Server ってのを使ってましたよ。ただ、SpaceTag Server はアップデートサービスは有料なので、上記の xampp ってやつの方が良いかもしれませんね。あと、これらに頼るのは、最初は楽でいいですが、余計なものもたくさんインストールされますので、慣れてきたら自力で個別にインストールってのを挑戦されることをお勧めします。「へたれなまま」っていうか、最初は誰だってへたれだからそれで良いと思います。まずは簡単にインストールして(「簡単にインストール」と言っても、自分で独自にインストールするよりはこれらインストールパッケージは安全な設定でイントールしてくれるの安心)、いろいろ勉強して実力をつけた後、独自インストールにステップアップする、というのも手ではないかと思います。私はお勧めします。 - あき (2006年03月19日 22時33分53秒)
  • 私ならFreeBSDのportsが簡単で拡張性があり,へたれではない仕組みだと思いますけどねぇ - sakuma (2006年03月19日 23時57分08秒)
  • そうですね。頼りきるのは問題ですけど、その後自分でステップアップしていけばいいですしね。あと、これを使うと何か不具合が発生した場合、頭によぎる「何か環境設定を間違えたんじゃないのか?」というのがある程度無くなりますし、別の人に同じ環境でテストしてもらえるというのもあるんじゃないかなと思います。FreeBSDのportsというのは知りませんでした。教えてもらってありがとうございます。 - 名無しさん (2006年03月20日 07時01分34秒)
  • configure のオプションを自分の環境に合わせて指定できないうちは、ヘタレというか入門者なんじゃないかと思います。portsも万能じゃないですから、make install だけで済ませてるうちは他でいうパッケージを入れるのと大差なくて、結局レベルは上がらないですよねー。 - gyo (2006年03月20日 12時03分45秒)
  • ザンプはPHPの - 東京 (2006年09月12日 02時23分47秒)
  • ローカル開発環境を整えるのには最適ですが、容量がはんぱなくデカイ。更新とかが結構つらいです。 それとPerl使ってた人はほとんどApacheだから。。 - 東京 (2006年09月12日 02時24分48秒)
お名前: コメント:

スタイルシート - Kinsan (2006年03月19日 15時15分10秒)

ここのサイトのスタイルシートが外部(http://www3.vis.ne.jp/~asaki/default.css)に置かれており、そのサイトが会社では、閲覧許可のフィルターに引っかかるため、css無しの表示になってしまいます。

スタイルシートは、実際にも別サイトですか?それとも、URLだけがそうなっているだけでしょうか。

いずれにしても、fswiki.poi.jp以下にcssが置かれている扱いになってくれると、うれしいのですが。

  • config.datにはそのように設定されているので、スタイルシートは外部から参照されているはずです。ちなみに管理関係はたけぞえさんが自身で行っています。 - にらたま (2006年03月19日 16時17分09秒)
お名前: コメント:

FreeStyle Wikiのプラグイン - A_M (2006年03月14日 14時53分34秒)

ここで述べたいホントウのお題は「既存のCGIっぽいプラグイン」となりますが、「既存のCGIファイルをwiki内に設置」という発言を受けて思いついたものです。

FSWikiのワークフレームって「表示したい内容のアクションを書く。それらの組み合わせで活用する」というのが、感覚的にも染みついていますが、この開発方法で、既存のCGIっぽい作品を作れそうですね。

出力はパーサー任せで良いので、データのフォーマットと処理部だけに集中して遷移した画面のアクションを書くといった具合に。もっとも、よくあるテキスト形式なデータファイルをどのディレクトリに置くか、アクセス権限をどのようにするか、Farmでの動作はどうするかといったFSWikiとの親和性が課題になりますけど。…こんなことを考えるのは、私だけでしょうか。

CMSパックの動きやら将来的なユーザ認証についてを考慮すると、FreeStyleWikiの可能性として、そのような方向もあるのかなと。あくまでも可能性ですけど。…プラグインは、Wikiページを豊かにするためにあるのが分かり易いでしょうかね。

  • おぉ。それってなんかオブジェクト指向っぽくていいですよね(違うかな?w)。しまいには某有名プログラミング言語みたいに「FSwiki自体が、FSwikiで書かれている」とかになったりして。 - ふる (2006年03月14日 16時19分45秒)
  • 失礼。冗談はともかく、このようになったら個人的に以前から感じていたんですが、「自サイトでは導入されているプラグインでも他のFSwikiサイトでははいっていないので表現や記載が制限される」みたいな問題が解決できますね!! これは提案でもなんでもないのですが、もしもそのサイトで使いたいプラグインが実装されていない場合も、そのページ内に記載(実際はコピペになりますが)擬似的にそのページだけで通用するオブジェクトと言うかプラグイン命令を造って記載できますし。でも悪用も出来そうですが…… - ふる (2006年03月14日 16時23分51秒)
  • プラグインなので、他のサイトは全く関係のない形を考えていました。たとえば、設置サイトの中には、オンラインゲームのメンバー表CGIをIFRAME要素で取り込んでいる方もいらっしゃいますが、このように「Wikiとは全く別物のコンテンツを、幾つものアクションハンドラの作成と組み合わせで実現できる」のではないだろうか。といった事を伝えたかったのです。あくまでも、「サイト内で実装されているプラグインを活用する形」なのですが、実装されていても利用の可否がある、つまり、ユーザ毎にプラグインの利用権限があると良いかもしれませんね。 - A_M (2006年03月14日 18時38分15秒)
  • 確かに、プラグインの利用権限は必要だと思いますね。これは保存する時にチェックすればなんとかなるものなのかな? - KG (2006年03月14日 19時20分01秒)
  • 自分に理解力が無いだけなのか、ちょっとイメージが掴めないでいます。『FSWiki上で動作するアプリケーション』みたいなものでしょうか? と後、提案されているのは、「そういったプラグインも開発して行きませんか?」といった内容でしょうか? それとも、「そういったプラグインが開発できるように土台を整備して行きませんか?」といった内容でしょうか? 或いは全く発想が違って、「特定のフォーマットでWikiページを作成するとそれがCGIっぽく動作する、みたいなプラグインってのはどうですか?」ことでしょうか? すみません。BBS-雑談掲示板/170の件といい、こちらの件といい、本当に私自身が文章を解読する力が無いだけなのかもしれません。申し訳ないです。 - あき (2006年03月15日 04時37分01秒)
  • あき氏の仰ること殆ど(前半)が該当しそうです。現状でも「FSWiki上のアプリケーション」としてプラグイン群を使った拡張ができそうですよね。…具体的に問題になるのは、セッション管理を含めた認証周り、ユーザ管理、プラグイン管理の部分になるのかな。あえて「可能性」の話しに留めたのは、こうした土台整備は、コア部分でもありますし、データの保存についても特殊な発想だからです(用途に応じてWikiページやコンフィグ、キャッシュが在るが、コンテンツ次第では、CSV でも…)。ただ、 実際にやってみようという話しになってから でも遅くないと思ってます。後半部分(特定のフォーマットでWikiページを作成)については、Wiki記法を覚えてもらえるようなドキュメントの整備で事足りると思います。添削:Wikiページの記法をCGIっぽくというのはマクロのような考えになりそうなので、私の発言とは異なります。 - A_M (2006年03月15日 07時25分25秒)
  • なるほど。「Wikiページでマクロ言語を…」というのとは違うのですね。今一度熟読し直してみます。 - あき (2006年03月15日 08時17分52秒)
  • 上記プラグインタイプのアプリケーションを作ったと仮定して「一部のデータだけを抽出してWikiページ内に貼り付ける」というのは、従来のインライン、パラグラフのプラグインで提供できそうに思います。 - A_M (2006年03月15日 11時18分57秒)
  • ちょっと方向性が違うかも知れませんが、Formプラグインってのを考えてみました。 - Kinsan (2006年03月20日 00時18分14秒)
  • BugTrack-plugin/215の発展系という感じですね。 - 名無しさん (2006年03月20日 01時11分01秒)
お名前: コメント:

新しいテーマやプラグインを導入するとき - ふる・たいプ (2006年03月14日 00時48分29秒)

 FSwikiをいつも使わせて頂いております。

 ところで、新しいテーマやプラグインを導入するときに、現在の仕様だとファイルの設置サイトへのFTP転送しかないのですが、それらを特別なページを作成することで導入することは(今後)検討していませんでしょうか? plugin/categoryみたいなページで。(そういうプラグインでもかまわないのですが……)

 HTMLのソースのなかでファイルを扱うときにwiki書式が使えたらいいなぁって感じたことがあるんです。いまのところはFSwikiページをリンクするときは直URLを書くしかないわけです。既存のCGIファイルをwiki内に設置するときも外部ファイルをは(あたりまえですが)設置サイトにFTP等で設置しますよね。それ自体がwiki内におければ便利かなぁと。

 また実は気に入ったFLASHがあったんですが、FSwikiでそのFLASHを設置する自体は簡単ですが、そのFLASHで表示させるメッセージは外部ファイルを使用しているのでそのつどFTPで書き換える必要があったんです。それの外部ファイルをwikiページに置き換えることは元のFLASHの仕様も変えないといけないわけですのでFLASHは無理っぽいかもしれませんが。

 あ、でも、添付ファイルの保存方法をwikiかそれとも生かで選択できるようになっているだけでもいいのかな?

 すみません妄想みたいな雑談で。(汗

  • 実は自サイトのFSwikiで、画像にJavaScriptで吹きだしをつけようとして、ちょっとドツボにはまったので勢いで書き込んでしまいました。申し訳ありません。 - ふる (2006年03月14日 00時50分54秒)
  • 「attachプラグインのような形式でもいいからサーバー上のファイルシステムを操作するプラグインがあれば…」ってことですね。WEBブラウザだけで実現できるのは利便性が高まるのですが、実現の為には、他にも考えなければならない事が多いように思います。…個人的にはFTPソフトを使っちゃうかな。 - A_M (2006年03月14日 06時31分19秒)
  • Wifkyみたいに、CSSという名前のページをつくってそこにCSSを書く感じですよね?実現出来たら面白うそうですが。プラグインは普通にFTPでいいんじゃないかなと思います。 - 名無しさん (2006年03月14日 07時16分34秒)
  • 便利そうなことを提案されているような気はするのですが、いまいち提案の内容が理解しきれません。「HTMLソースの中でWiki書式が使えたらいい」というのがまず分かりません。「Wiki書式としてHTMLタグが使えたらいい」とかなら分かるのですが…。HTMLにはHTMLの仕様があるわけで…。そういうことではないですよね? 「Wikiページへの直リンクを簡単に」ということであれば、ブラウザでそのWikiページを表示させてURL欄をコピー・ペーストで良いですよね? これをさらに簡単にできないか、ということでしょうか? それから、次の疑問「既存のCGIファイルをwiki内に設置するときも…」ですが、「CGIをWiki内に設置」という辺りが良く分かりません。Wiki自体が独立した一つのCGIですので、この中に他のCGIを設置する、というのは何を指しているのでしょう? FTPソフト等を使わず、Wiki上の操作だけで他のCGIを設置できたら、ということでしょうか? できたら確かに便利ですね。ですが、これをCGIでやるにはセキュリティ的に危険を伴います。「CGIでサーバ上のファイルを操作したい」ということでしたら、webexplorerなんてのも存在しますが、操作するディレクトリ、ファイルは全てCGIに対して全権限(参照権限や書込権限)を与えておかなければならないわけで、その分危険です。「FTPソフトを使う」という手段は、httpとは別のポート(通り道)を使ってのアクセスとなるため、その点安全な訳です。すみません。時間が無くなりました。また後で追伸します。 - あき (2006年03月14日 08時22分12秒)
  • Flashの件ですが、確かに外部ファイルを扱うFlashの表示には対応させたいですね。今の構造のままでも外部ファイルをtheme_dirディレクトリに置いてやれば辛うじて表示させることは可能かな? KG殿提供の直リンク画像表示プラグインを使えば、image_dirディレクトリ下に直接アップロードできて、かつ表示させることも可能な気がします。「(拡張子が)画像ファイルじゃなきゃアップロードできない」とかありましたっけ?>KG殿 拡張子制限がなければ、swfファイルと外部ファイルをimage_dirディレクトリにアップロードして、image_uri経由でswfファイルを参照してやれば外部ファイルを扱うFlashも扱えると思います。ただ、これらの操作を外部のユーザにも許すような設定にしてしまうと、またそれはそれで危険な薫りがしてきてしまいます。編集制限や添付制限をかけるべきですね。 「外部ファイルをwikiページに置き換えることは…」>FlashからWikiページを参照ってのは構造上無理ですね。WikiページはWikiCGIからでないと参照できないです。サーバの設定次第で参照させられなくもないですが、Wikiの秘匿性が損なわれるのでやるべきではないでしょう。携帯からの書き込みでした。ふ〜、疲れた。(-.-;) - あき (2006年03月14日 11時24分06秒)
  • 良かったぁ、書き込めてた。(-o-) - あき (2006年03月14日 11時28分26秒)
  • image プラグインにアップロード制限はありませんよ。制限があるのは移行ツールの方です。(本当は制限あった方がいいのですが・・・)。imageに固定しない方が良かったかもしれませんねぇ。「直リンク・リソース・プラグイン」とか(^^; - KG (2006年03月14日 11時37分45秒)
  • やはり安全上好ましくないですね。皆さんの書き込みを読んで理解しました。個人で使用していると、どうしても広い視点で見れなくなってしまいます。確かにFTPでやっていたことをオンラインで操作できるようにすることは危険ですよね。安直に掲示板に書いてしまって申し訳ありませんでした。 - ふる (2006年03月14日 12時28分44秒)
  • お求めのものと同じかわかりませんが,管理画面からプラグインをアップロードするプラグインを書きました. - sakuma (2006年03月15日 02時12分38秒)
  • おぉ!! サンクスです! はやすぎ!>sakumaさん - ふる (2006年03月15日 02時21分50秒)
  • あ、でもこれってFTPと同じ事をwikiの管理画面からできるってことですね - ふる (2006年03月15日 02時23分01秒)
  • 「安直に掲示板に書いてしまって申し訳ありませんでした。」>申し訳なくはないですよ。こういった意見はとても貴重です。安全性を損なう発展は良くないですが、安全性を確保しながら如何に便利に発展させていくか、というのはとても重要な考えです。開発者サイドとしては、頭ごなしに「危険だからやらない」という考えになってしまいがちですが、要望が多いと「じゃあ、方法を考えてみようか」という流れになるわけで、遠慮する必要は全くありません。 - あき (2006年03月15日 03時46分42秒)
  • BBS-雑談掲示板/171のほうかどちらに書こうかと悩んですが、こちらにかきます。BBS-雑談掲示板/171でもそうですが、ここの書き込みは私がしましたが、すでに皆さんはかなり先を行っていますのでさすがだと思う次第です。気軽な雑談のつもりが意外な展開に驚いています。真面目な話、今回の発案(!?)はFSwikiにwiki以上のことをさせようとしているみたいなことに気がつきました - ふる (2006年03月15日 14時16分35秒)
  • ですので、このまま話がいったらFSwikiが「FSwiki・API」かもしくは「FSwikiエンジン」みたいになってわけがわからなくなりはしないかと心配です。考えすぎかな? 最初は「テーマ(スタイル)をwikiで書けて手軽にプレビューで確認しながら修正して手軽に登録できたらいいな」とか「プラグインをwiki文章として書いて登録しておけば参照権限の変更だけで利用可能&不可の設定がラクだよな」とか - ふる (2006年03月15日 14時21分25秒)
  • また「そうなれば手軽に拡張できるから、必要ときだけMySQLとか使えるかも」とか安易に考えていたんです。でも逆にFSwikiの魅力の部分を損なうこともありますよね? ちょっといま自分でも必要ないことを言ったかもと反省しております。 - ふる (2006年03月15日 14時25分10秒)
  • Wikiらしさ(編集における簡便性)は最重要項目だと思っています。加えて、FSWikiのコアは「Wiki以上の機能を実装できる可能性も秘めている」というだけで、混乱を招くようなプラグイン開発はしてはならないとも思っていますよ。慎重に考えたいと思ったので、BBS-雑談掲示板/171では、可能性で留めたつもりです。 - A_M (2006年03月15日 14時39分20秒)
  • テーマをWiki上で修正出来るようにするという考えは面白いかなあと思いました。そもそもテーマの投稿が少ないのでユーザーサイトを巡っても似たようなデザインのサイトが多いんですよね。tDiaryのテーマが使えるといってもそれほど互換性ある訳じゃないし・・・。 - 名無しさん (2006年03月16日 19時59分57秒)
  • テンプレートはともかくとして、各種ブログサービスの管理画面のように、テーマをTAXTAREA経由で変更できるのは良いかもしれませんね。 - A_M (2006年03月16日 20時05分08秒)
  • ユーザーが変更出来る必要は無さそうなので、管理画面で変更出来るといいかなと思います。スタイル設定のとこで選択したテーマを読み込んで変更出来るようにするとか - 名無しさん (2006年03月16日 20時32分29秒)
  • 「スタイル設定のとこで選択したテーマ」を直接編集となると、賛否両論有りそうですね。 - A_M (2006年03月19日 17時03分01秒)
  • まあプラグインだから反対の人は使わなければいいだけかも。 - 名無しさん (2006年03月19日 19時20分29秒)
  • ここでいう『賛否両論』っていうのは、そういうことではないと思いますよ。A_M殿は、「こうあるべき」といった標準的な仕様について発言されていると思います。(今までの他の発言の経緯から言っても…) 便利な反面、私もこの仕様に関しては少し疑問を感じてまして、「スタイル設定のとこで選択したテーマ」というのはつまりconfig.datのtheme_dirやtheme_uriに格納されたファイルに上書き権限を与える、ということになるわけで、セキュリティ面において不安な要素が出てきてしまいます。管理画面で操作できるユーザ定義スタイルっていうのは外部から直接は見えないファイルへの書込になるわけで、その分いくらかは安全なのです。プラグインという形で公開するとなると、セキュリティに関して十分な知識を持ち合わせていないユーザの方々は安全性より利便性を優先して設置することになるかもしれないわけで、A_M殿も、こういったことを懸念されているのではないでしょうか? 好みの問題ではなく提供する側の責任という意味において…。 - あき (2006年03月19日 23時01分48秒)
  • そうですね。少し軽率な発言でした。ただ、自分が想定してたのはCSSを直接編集は出来ますけれど、それはユーザー定義スタイルへの書き込みであって、テーマディレクトリのファイルを上書きするというつもりではありませんでした。 - 名無しさん (2006年03月20日 01時22分48秒)
  • 今でもユーザ定義スタイルは書き換えられますよ? - sakuma (2006年03月20日 01時25分45秒)
  • 管理画面で何故編集出来るようにしたいかというと、ブラウザの違いとか解像度の違いを管理画面で吸収できたらなと思うんですよね。 - 名無しさん (2006年03月20日 01時30分35秒)
  • 1枚のスタイルシートで表現するFSWikiの仕様上、ブラウザの違いを吸収するには共通して利用できるプロパティの記述が必須になりそう(人為的な記述に依存しそう)です。また、各Farmのconfig.datに指定テーマが異なることも考えられ、CSSのコードミス(人間だからそういうこともありますよね)で既存ページの表示が崩れちゃう事になりそう。…そうしたことを考慮しないと「使えない」プラグインになるんですよね。 - A_M (2006年03月20日 08時29分02秒)
  • 今の仕様はHTMLソースを見る限り
<link rel="stylesheet" type="text/css" href="選択したテーマ">

ここからユーザー定義スタイル
<!--
/* エラーメッセージ */
.error {
color       : #FF0000;
font-weight : bold;
}

という感じで、選択したテーマの後にユーザー定義スタイルを加えるという感じじゃないでしょうか?それで妄想なのですが、ユーザー定義スタイルのところにIEとFirefoxを分ける条件式のようなものをつくって

<!--TMPL_IF NAME="USER_AGENT_IE"-->
〜

みたいな感じで、付け加えられないかなと考えてた訳です。実現出来るかは分からないのですが・・・ブラウザから変更する必要があるのはこういうローカルルールかなと思って言ってました。と書いているうちに、そこまでやる必要も無いかなという気もしてきました・・・- 名無しさん (2006年03月20日 08時39分44秒)

  • Farmも同じ感じで既存のテーマはいじらずにローカルルールをFarm毎に記述する感じですかねぇ - 名無しさん (2006年03月20日 09時05分37秒)
  • 可能か不可能かで言えば可能です。確かに、ユーザー定義スタイルとはそもそも、サイトスタイルでは定義しないような内容(例えば、個々のプラグイン固有のスタイル)を定義する場所ですので、ブラウザ固有の追加スタイルを定義する場所ではないですからね。ですが、ブラウザから変更すべき内容か、と言うとそれもまた違う気がします。ブラウザ固有の違いも含め、CSSファイルはデザインしておくべきです。(テンプレート側でブラウザを切り分け、それぞれのブラウザに応じてclassを分ければ可能ですよね?) いっそのことCGIから*.cssファイルを呼び出す、という発想をやめて、その内容をごっそりユーザー定義スタイル側で定義する、という向きの発想なら良さそうですね。ま、『ユーザー定義スタイル』でっていうのは行き過ぎですので、各パーツのスタイルをそれぞれ別々のTEXTAREAタグやコントロール配置用のタグを使って設定できるようにすれば、巷にあるようなブログの設定画面に似たようなことはできます。一応そういった方向でも考えたことはあったのですが、表現できる幅に制限を設けることにもなりますので、気が進みませんでした。ですが今ちょっと良い手段を思いつきました。ちょっと練ってみたいと思います。 - あき (2006年03月20日 13時18分18秒)
  • かぶっちゃいそうですね。まだまだ、考えるべき点は多いのですが、このように荒削りな状態を作っています。 - A_M (2006年03月20日 13時48分08秒)
お名前: コメント:

赤文字(または警告文字?)の出し方って公式なのでしょうか? - ZON (2006年03月12日 22時45分31秒)

いまごろ気づいたっていうのも恥ずかしいのですが、SandBoxや投稿プラグインのページで、警告や注目目的のために文字を赤く装飾しているものを見掛けまして、ふとどうやっているんだろうと思ってソースを見たら次のように記述されていました。

<<注目させたい文字列>>

そして、HTMLソースではerrorのクラスが定義されていました

<p><span class="error">注目させたい文字列</span></p>

標準配布のFSWikiだけで赤文字が表現できるなら、それはそれで使い勝手が良さそうなんですが、それがerrorを故意に使っているのだとしたら、と思ってちょっと心配になりました。

もっとも、lib::Wiki::Parser.pmを見ると、< <と> >でerrorとなるように書かれているようですね。

とりあえず“赤文字”で検索してみてそれらしい文章を見付けられませんでした。また、標準ヘルプの『テキスト装飾』の項目にはこの< <と> >で「エラー」とか「警告文字」とかいうような定義の説明も無いようですので気になりまして書き込んでみました。

既出でしたらごめんなさい。

  • 私も同様に他の方が記述したWikiソースを見て気づきました。lib/Wiki/Parser.pm の parse_lineメソッドに処理が記述されているので、機能としては標準と考えて良いと思います。ちなみに、ドキュメントやヘルプでは紹介されていないので、赤文字というより、システムエラーとして目立つことが最優先となる記述だと思います。スタイルシートでの変更もその点を考慮するのが良いと思います。 - A_M (2006年03月13日 06時21分26秒)
お名前: コメント:

バージョンアップ時の更新ファイル - もりやん (2006年03月12日 14時30分11秒)

先ほどpermalinkプラグイン対応のために最新版にバージョンアップしたんですが、いくつかのデフォルトプラグインに手を入れているために、とりあえず全部Upは避けました。結局ファイル比較ソフトで更新のあったファイルを探して置き換えたんですが、パッケージ内の更新ファイルリストをどこかに書いておいていただけるとありがたいなー、と。

  • アーカイブがあるので,diffったら差分がわかりますよ - sakuma (2006年03月15日 02時14分27秒)
  • 個人でも可能な事ですが、こんなページを作ってみました。今のところニーズは未知数です。--> 配布物のファイルの更新情報 ……ちなみに私は自分でこういうリストを作って更新に使っています。必ず確認しなくてはいけないので一人でやってるときのミス予防にもなってます。 - zon (2006年05月29日 18時49分37秒)
お名前: コメント:

Wikiスパム - 名無しさん (2006年02月25日 01時35分54秒)

最近Wikiスパムによる被害がちらほらと見かけられますけど、みなさんは何か対策してるんでしょうか。

  • ウチにも来ました。コメント機能を利用した書き込みでした。掲示板などでもそうですが、記事投稿の前に「プレビュー」などのワンクッションを設けると、これに対応していないスパムは弾けるようですね。そういう仕様のプラグインなどが公開されると、プログラム初心者にとっては助かるのですが。 - 被害者A (2006年02月25日 01時39分51秒)
  • ここにもスパムがきますが小人さんがサクッと削除してくれるみたいですね - typer (2006年02月25日 14時35分20秒)
  • スパム対応は、キーワードだけという現状なので、凍結をする、コメントは別ページとなるpcommentを使うなど、復旧を早く行えるようにするしか無いように思います。編集できる人は、Wikiらしく小人さんになることも大事ですね。過去の履歴に戻せる「復元」機能があれば…と感じることはありますね。 - A_M (2006年02月25日 18時39分49秒)
  • コメントが書けるだけの権限とかがほしいかも。ゲストユーザー用のIDを用意してサイト上に公開しておくとか - 名無しさん (2006年02月28日 01時08分26秒)
  • 個々での削除は単なる事後処理ですな。対策とは言いがたい - 匿名 (2006年02月28日 23時31分36秒)
  • 確かに、ソフトウェアにおける対策は自動化が理想ですよね。ユーザに限定した運用が確かなのですが、管理者がアカウントを発行しなければならない、現在の仕様が気になりますね。事後処理もWikiらしさではありますが。 - A_M (2006年03月01日 00時55分46秒)
  • 「http://」をスパムの保存しない文字列に設定して、通知するときは「ttp://」と書くようにすればいいですけど、使いづらくなりますね。 - 名無しさん (2006年03月02日 00時54分48秒)
  • スパムは必ずhttp〜の記述があるので、その辺をスパムと見分ける糸口になればいいんですけどねえ - 名無しさん (2006年03月02日 00時56分23秒)
  • データの学習が必要ですがスパムフィルタである bsfilter や bogofilter をかませられれば自動化できるかもしれないですね. - 名無しさん (2006年03月02日 03時21分55秒)
  • 自分のところも、相当来ました。IPアドレス元は中国と韓国からです。国のIPアドレスを.htaccessでdenyしました。しばらく様子を見てみます。 - 名無しさん (2006年03月04日 00時22分48秒)
  • fswikiの範疇でキーワード以外になにか良い方法がありませんかねぇ。bsfilterなどを使うってのはなかなか良い案だとは思いますが、pure perlじゃないのでcoreには入れられないし、おっしゃるように学習や誤判定対策のためのインターフェースをどう設計したら良いのやら。だれでも編集できる事とSPAM防御とを両立できるpure perlでできる都合の良い方法がないものかな(笑) - typer (2006年03月06日 22時48分44秒)
  • spamassassinを使う方法で実現できるかもしれませんね - sakuma (2006年03月15日 13時50分48秒)
  • CAPTCHAを使った,人間であるか確認のプラグインを書きました.コードはあるのですが,ドキュメント類を書いてないので,ドキュメントを書いて,明日あたり公開したいと思います.CAPTCHAプラグインで公開しました.外部ライブラリを用いていますが,Pure Perlなので設置するだけで動きます. - sakuma (2006年03月15日 23時17分07秒)
  • 小技で対策といえるかどうか、管理画面のスパム対策の行間に空白行いれると書き込み不可の一時しのぎになりますね。- すなぷ (2006年07月22日 11時15分35秒)
  • どこかの掲示板で荒らし対策として、コメントが英数字のみの時エラーとするとかやってましたよ。 - 名無しさん (2006年07月23日 00時38分34秒)
お名前: コメント:

リファラー対応キーワードハイライト - Kinsan (2006年02月24日 20時59分27秒)

ちょっと勘違いから思いついたのですが、大手検索サイトで検索してたずねてきた場合にだけ、検索キーワードと同じ語句だけをハイライト表示してあげるってことは、やろうと思えば出来ますよね。

そこまで親切にしてあげて、見返りがあるかは別ですが(笑)。多分、その分表示も遅くなりますしね。

  • 話し全然違いますけど、ページを更新した時に更新部分をハイライト表示するってのも出来ないですかね - 名無しさん (2006年02月25日 01時37分47秒)
  • ページの途中を更新されるとどこが更新されたか分からないので、いつも差分を見てるんですよね。なんかボタンを押すと差分だけハイライトされるとか、更新された部分を一番上にも表示するとかあったら便利そう。 - 名無しさん (2006年02月28日 01時11分42秒)
  • これも話違うかもですがsearchでの検索結果もハイライト表示されるといいかもですね。ついでに先頭候補に移動するとか。 - 名無しさん (2006年03月24日 15時48分20秒)
  • BugTrack-plugin/235を使うと検索結果がハイライトされますがいかかでしょうか? - 名無しさん (2006年03月24日 16時11分12秒)
  • 単語単位ですが、私のサイトの方で、javascriptだけで対応して見ました。まだ、ベータ版のLayoutテンプレートですが、一応・・・自サイトのSEARCHプラグインと、Google,Yahoo の検索結果に対応できているかもしれません(笑)。切り出し等が雑なコードですので思わぬバグが潜んでいるかも・・・です。あと、入力エリアに任意の単語を指定してハイライトすることもできますです。まだまだ、テスト中・・・ - KG (2006年03月24日 21時57分11秒)
  • こちらでβ版として公開しました。現在機能追加予定ですので全ての機能の組込みが終わりましたら、当サイトにて公開します。 - KG (2006年03月27日 13時26分03秒)
お名前: コメント:

[ 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 ]

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