雑談掲示板

FSWiki雑談掲示板

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

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

お名前
件名
本文

新しいテーマやプラグインを導入するとき - ふる･たいプ (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という名前のページをつくってそこにＣＳＳを書く感じですよね？実現出来たら面白うそうですが。プラグインは普通に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秒)
１枚のスタイルシートで表現する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秒)
「ｈttp://」をスパムの保存しない文字列に設定して、通知するときは「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秒)

land.to の子wikiでrss - kitta (2006年02月12日 09時25分46秒)

land.toに設置して使っていこうかと思ってるんですが子wikiでrssに広告が挿入されて困ってます。以下二つをすると

「.htaccess」ファイルを設置し、これ以下のフォルダに広告を表示させないファイル形式を設定する。

LayoutIgnoreURI *.cgi

自動挿入を停止したいファイルの任意の箇所に「」タグを挿入する。

を.htaccess　テンプレートに行ったんですが親wikiだとrss正常なんですが　子wikiだとrssに広告が入っちゃうんです。

"広告について"を見ると

perl用

require "/ad/bn.cgi";

こんな方法もあるみたいなんですが　Perlがよく分からないんでこれは試せていません。どなたか教えていただけないでしょうか？

LayoutIgnoreURI *.cgi を *.* にしておけばいいですよ。 - KG (2006年02月12日 09時49分27秒)
おぉ　なるほどぉ　試してみます。 - kitta (2006年02月12日 09時50分27秒)
それって、やっていいのかな？規約上、禁止なんじゃ...。 - 名無し (2006年02月12日 09時54分23秒)
完璧です。*.*とは思いつきませんでした。ありがとうございました。 - kitta (2006年02月12日 09時54分43秒)
全頁で広告が入ればいいんでしょ？問題ないんじゃないでしょうか？ - KG (2006年02月12日 09時58分17秒)
自動で入れる広告を読み込まない様にする事を禁止してないので、.htaccessを*.*とし任意の位置へ広告入れば良いはずです。 - kitta (2006年02月12日 10時17分01秒)

ドキュメントのフロントページが書き換えられているようです - ZON (2006年02月09日 11時00分23秒)

TipsからたどってFSWikiドキュメントを見に行ったら、フロントページとキーワードが書き換えられているようです。

docs:FrontPage

docs:Keyword

こんな感じの内容

弊順宣脂利
-喇嶄忽遍社 宣脂
巷望?貧今略秤斌暦徂儂嗤?巷望幹一?巷望奥覚＾
廨匍略秤?廨冩宣脂?廨匯捲暦￣議娼舞蝕婢?購宣脂捲暦
?宣脂亅咏?宣脂徂儂?宣脂夏恢蛍護?鞭欺阻芙氏才箪悶
議挫得。埋隼ゞ脂咆隈〃及膨噴鎗訳号協阻斤噐
宣脂 鱒墾唐灰議癖喘訳周?徽糞樹嶄?喇噐宣脂鱒墾唐灰叙
冢鯉癖喘噐揖肖、嶷脂、社優羽薦
……以下省略、URLは省きました。

書き込まれているリンクは触っていませんが、フロントページなので元に戻すオリジナルが分からなかったので、こちらに報告します。

FSWiki_liteについて - 名無しさん (2006年02月07日 15時25分30秒)

FSWiki_liteはもう更新されないんですかね・・・Shift_JISでの出力は期待しているところなんですが・・・

私はFSWiki_Liteにパートエディットプラグインが出来れば嬉しいなと思っています。 - 名無し (2006年02月08日 10時57分11秒)

Wikiのメニューとページのメニュー - ゑ (2006年02月05日 01時12分32秒)

Wikiに対するメニューと、Wikiのページに対するメニューが混ざっているのが納得できない。別々にして欲しい。

wiki{トップ新規一覧 Farm 検索ヘルプ RSS ログイン}

page{編集差分ソース PDF}

トップ新規一覧 Farm 検索ヘルプ RSS ログイン編集差分ソース PDF という順が理想でしょうか？　「新規」はこの位置で宜しいですか？　「ログイン」は一番最後が収まりが良い気がしていたのですが、このように分けた場合、中の方に入ってしまいまが、特に違和感はありませんか？ - あき (2006年02月23日 08時15分54秒)
この話題に関連するようなことをたまたま昨日・今日と考えていたのですが、Wikiらしい作りを推し進めるならば、ページレイアウトもInterWikiのようにあるページに記述するだけで変更できていいと思う。FreeStyleWikiでは現在、Menu, Header, Footerなどがデフォルトで配置されているが、そこらを簡単に自由にしても良いと思う。この質問を今日見るまでは右上のメニューのことまでは考えていなかったのですが、InterWiki的なやり方でその配置と表示される文字列も自由に変えれるようにしてはどうでしょう。 - Kinsan (2006年02月23日 23時17分47秒)
とても興味深い提案ですね。このスレッドの本題からは脱線してしまいますが…。実はA_M殿がこれに近いことにチャレンジしてくれています。サイドバーを左右どちらか一方、というのだけには飽きたらず、両方に配置。さらに、それらをテンプレートで切り替え可にしてしまおうというものです。（BugTrack-sitetemplate/4か又は、この辺りかな？）私はそれを見て以来、xoopsのレイアウトが自由に変えられる仕組みをFSWikiに転用できないか、ずっと考えていました。「InterWikiのように…」というのは管理者以外もレイアウトを変更できてしまうわけでちょっと問題かと思いますが、管理画面で変更できる仕組みにすることは十分実用的で需要も大きいと思います。同じ管理者なら、テンプレートファイルも弄れるというものですが、やはりファイルを直接編集するのと、ブラウザ上から変更できるようにするのとでは随分と使い勝手が異なります。実装する価値は十分にあると思います。ですが、新たな実装手段を考えるまでしなくても、レイアウトの配置される場所毎に固定のページ名を決めておいて、その名前のページを作成したりリネームしたりすることで様々なページレイアウトを楽しめるようなのにするくらいなら、専用のテンプレート（とテーマ）を作成するだけでも実現できてしまいそうです。

Header,Footer,Menuを全ページ共通で配置させているのは、テンプレートでそのように定義しているからです。HeaderというページをFooterという名前にリネームすれば配置が上部から下部に移動します。これの延長で、Left1（左サイドバー１段目）、Left2（左サイドバー２段目）...、Right1（右サイドバー１段目）、Right2（右サイドバー２段目）...、CenterLeftTop（中央左上段）、CenterRightTop（中央右上段）、CenterLeftBottom（中央左下段）、CenterRightBottom（中央右下段）のように配置されるテンプレートを作成しておけば、似たようなことはできるのかな、と…。

このテンプレートにベストマッチするテーマを作成しようと凝り始めると本当に時間がいくらあっても足りなくなってしましそうですが、こういった仕組みを考えること自体は意外と楽しいものかもしれません。 - あき (2006年02月24日 00時45分44秒)
別スレッドにした方がいいかな？ - あき (2006年02月24日 01時45分06秒)
メニュー部分は、実装の仕様があるにも関わらず微調整できるメニューアイコン・プラグインを活用すると幸せになれたように思います。ところで、他のCMSの殆どがTABLEでレイアウトしていますよね。個人的に「スタイルシートを使わないときに、どういう流れの文章になるか」というのもWikiらしい視点だと考えています。 - A_M (2006年02月24日 06時28分37秒)
FSWikiの隠し機能として、登録済みのページをテンプレートとして、新規ページを作ることが出来ます。この機能などを利用するためにも、メニューセットを複数使い分けれると良いと思います。また、サイドメニューを表示しないモードってのは、印刷のために前からある需要ですよね。 - Kinsan (2006年02月24日 08時01分57秒)
cssファイルを簡単に作成し、使い分けれる仕組みも欲しいですね。 - Kinsan (2006年02月24日 08時07分37秒)
ここで指摘されているメニューに関しては、メニュー項目の属性（Wiki or Page）か何かの情報を付加しないと解決は出来ないでしょうね。その情報さえあれば、混在させたり分割させたりすることも可能になると思います。属性の追加だけであれば、iconmenu で設定できるようにすることも可能ですね。あとは、プラグイン形式で wikimenuプラグインは存在しません。とか pagemenuプラグインは存在しません。とか指定して表示できるようにするなどの方法が考えられます。 - KG (2006年02月24日 10時24分35秒)
自動で振り分けようとすると属性情報が必要でしょうけども、ユーザーが自由に簡単にメニューを変更できるならば、自動振り分けは不要だと思います。 - Kinsan (2006年02月24日 17時54分17秒)
メニューを自由に変更できるというと、例えば｛｛menu メニュー項目[,メニュー項目][,....][,v]｝｝というような指定で、指定されたメニュー項目が表示可能であれば表示する。さらに、vオプションが指定されたら縦に表示する･･･などのような機能？ - KG (2006年02月24日 19時15分02秒)
上で書いたように、InterWikiのようにある特定の書式で、ある特定の名前のページを作ると、それがトップメニューにあるという仕組みが良さそうに思います。そのページに、表示される文字列とそのリンク先となるACTIONまたはURLを組にして記述するってことでどうでしょう。

例えば、下記のような感じでTopMenuというページに書き込むことにしてはどうですか。

:トップ:page=FrontPage
:新規:NEW
:一覧：LIST
:検索:SEARCH
:ヘルプ:page=Help
:RSS:RSS
:ログイン:LOGIN

- Kinsan (2006年02月24日 20時33分00秒)

Kinsanさんの仰るような方法（メニューも別ページ）は前から考えていたんですけど、プラグインを新しくインストールしたときに自動でメニューが出てきたほうがいいかなぁ、ということでそのままにしてます。実は作りかけ（放置中）のJava版では別ページでメニューの内容を定義できるようになっています。 - たけぞう (2006年02月25日 09時24分19秒)
メニューに関しては、私は新たな仕様は不要だと思います。A_M殿もコメントされてますように、Wikiメニューにアイコン画像を表示するプラグインがありますので…。冒頭で私が最初に質問したのはCMSパックでこの辺りの順番をちょっと弄ってみたいな、と思ったためです。 - あき (2006年02月27日 13時18分03秒)

ダウンロード・カウンターは定期的にクリアしている？ - KG (2006年01月23日 19時59分38秒)

当サイト（本家fswikiサイト）において、ダウンロードカウンターが定期的にクリアされているようですが･･･これは意図した動作なのでしょうか？というか、手作業でカウンターをクリア（上書き？）されているのでしょうか？

投稿プラグインの利用頻度などの目安になるので、できればカウンターはクリアしない方がよいのですが･･･。

言われてみれば最近頻繁過ぎるくらいにクリアされますね。3.5.9になった辺りから、頻度が増した気がしますが気のせいでしょうか？最近は更に更に、といった感じがします。 - あき (2006年01月23日 22時20分28秒)
ファイルが壊れているのかもしれないですね。次のバージョンでは設定ファイルの読み書き全般にファイルロックを実装しようと思います。 - たけぞう (2006年01月24日 11時58分57秒)
了解しました。意図的ではなかったのですね。てっきりメンテナンス時に上書きしてあるのかと思ってました。対応の方よろしくお願いします。 - KG (2006年01月24日 22時31分57秒)
~~FSWiki - A_M (2006年01月26日 21時02分54秒)~~ あれ、こんなところでSUBMITしていました。特に意味は無いです f(^^;

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

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