FreeStyleWikiスレ
無いので立ててみました。
FreeStyle WikiはPerlによるWikiクローンです。以下のような特徴があります。
* 徹底されたモジュール化により、プラグインによる拡張が容易
* Perlで書かれておりDBも使用しないため、CGIが動作する多くのサーバに設置可能
* mod_perlでの動作にも対応(3.4.1以降)
* 全ページ共通のヘッダ、フッタ、サイドバーを表示可能
* ファイルの添付やPDFの生成などが可能
* tDiaryのテーマを使用可能
* 簡単なユーザ認証機能を備えている
FreeStyle WikiはGNU GPLライセンスの元で配布、改変が許可されるフリーソフトウェアです
公式：http://fswiki.poi.jp/wiki.cgi FastCGIに対応してくれると貧弱なサーバ上でもLighttpdベースでさくさく動かせていいんだけどなあ。 最近のマシンなら低速マシンでも CGI で十分速いから、
高速化対策は労多くして益少ない。 >>230
つまり、最近のではないマシンで動かす（動かさざるを得ない）場合は労力に見合った益が十分にある。 >>231
それはレアケースでしょ？
最近、Web上で「FSWikiが遅い」という意見をほとんど見ない気がする。
マシンの性能が十分向上したからでは？
それとも、単に使われてなくて「遅い」と言われないだけなのかな？ >>232
> それはレアケースでしょ？
まあそうでしょうね。
たまたま超非力なサーバしか使えない状況になってしまったもんで。
Lighttpdを導入してみたんだけど、その軽さをFSWikiには活かせず…。
mod_perlには対応しているのになんでFastCGIは無視されたままなのかなあ、と。
公式サイトにあった3.5.10向けのFastCGI patchをだめ元で3.6.3に手動で当ててみたけど、
普通の更新と、ファイルの添付と添付ファイルの削除はうまくできたんだが
編集後のプレビューがどうもうまく表示されず、ページの更新もできずじまい。
原因調査中だけど技術力と知識の不足でいまだ未解決。 しばらく前からアクセスできなくなってるね。公式。このままフェードアウトはないよな? Pukiwikiといい、日本のwikiは終わってるな 開発者たちの意欲が無いんだもん。
まあ、
「利用するだけ利用しといて、声を上げるのは問題発生時のみ」
っていうユーザたちが、開発者たちの意欲を削いでいるわけだが。 公式サイトが消滅しているわけではないよ
Domainの期限が切れて一時的にアクセスできなくなっているだけ
3/21に更新されているけど、まだ反映されていないようだ
遅いね
hostsに登録すればアクセスできるけどね >>238
>hostsに登録すればアクセスできるけどね
IP 教えてください。 >>239
ほい。
74.52.221.66 fswiki.org >>240
ありがとうございました。アクセスできました!! FreeStyle Wiki、遂に開発継続を断念。
公式サイトは既に閉鎖済み。
開発者公式見解
http://d.hatena.ne.jp/takezoe/20100323 >>243
エイプリルフールって午前中までなんだってさ。ちょっと出遅れちゃったね。 まだ見れないですね・・・（URLで）
更新手続きに不備があったんでは？ｗ 単なる管理ミスでしょ。
こんな基本的なサイト管理もできないなんてお粗末ですね。
あの言い訳屋さんが、今度はどんな言い訳をするのか楽しみ。
それとも言い訳すらせず、だんまりを決め込むのかな? 言い訳はするだろうな。
醜いから止めといた方がいいのだが……>>246のかーちゃんと同じになっちゃう。 教祖様が立ち上げて下さった新公式サイト
ttp://fswiki.sourceforge.jp/cgi-bin/wiki.cgi ふつうに公式継続してるようで安心した
サーバの方のトラブルみたいだね
ピヴォットテーブルプラグイン を再度入手出来る場所はどこかにないでしょうか
sourceforceから本体だけはダウンロードできたんですけど 公式サイト騒動以外には話題が皆無とは。
相変わらず、平和なスレだ。 ttp://fswiki.org にアクセスすると...
Suspended
This server is suspended. Move your documents to other server quick, please.
This server will be destroy in early days.
fswiki.org 復活はなさそう?
新公式 ttp://fswiki.sourceforge.jp/cgi-bin/wiki.cgi が
早く広まるといいね。
英語、ちょっと変 まあ、fswikiはもう「捨て」ってことでいいんじゃね 同意。
でも、fswiki.* のドメインを軒並み掴んだまま消えるなよ、と言いたい。
URL 短くてよかったのに...。残念。 脆弱性の対応だけちゃんとしてくれれば使い続けるよ
プラグイン投稿も普通に続いてるし
個人的には<div class="day"><div class="body"><div class="section">のあたりがあんまり好きじゃなくて
もっとプレーンなHTMLを出力する切り替え設定があればな、ぐらいは思うけど 3.6.4きたけど…
3.6.3で使えなくなったindexcalendarプラグイン
それ自体が消えてる…
カレンダーの過去ログ見るときって結局
延々と<<をたどらないとだめなん？
それか手動で各年月のカレンダーリンクを
作っておかないとだめなん？ カレンダーは使ってないからわからんが
テンプレート指定して{{category calendar}}とかpager_index使うとか
まあ既存のファイルは自力で直すことになるけど
今さら質問しても半年くらいは回答が戻ってくる期待もないのだけど質問させてください。
「ページの一覧」を選んだ際にデフォルト設定では各ページ名の横に西暦年月日が表示されます。
携帯電話で見ても同じように表示されてしまい、せっかく利用してくれた利用者の電話代（パケット代）が
余分に掛かってしまい申し訳なく思っています。
できれば、ページ名の横に表れる西暦年月日を表示しないようにしたいのですが、どのファイルをいじれば良いのか
教えてくれませんか？
とりあえず、総当りで全部のファイルを調べているのですが、$dateに関係する部分が多くて
こちらのスレで教えて頂いたほうが早いかなと思いました。
よろしくお願いします。 /plugin/core/ListPage.pm 41行目?ぐらいのこれをコメントアウト
" - ".Util::format_date($wiki->get_last_modified2($_)).
>>264
個別解答は、>>265 の通りですが、探すべき *.pm がどれなのかを探す方法は次の通りです。
「一覧」の URL は、
http://*/wiki.cgi?action=LIST
でありますので、「一覧」は、アクション ID が「LIST」であるアクションであることが分かります。
アクション ID と、それを処理する *.pm を関連付けるのは、
wiki.cgi のあるフォルダから見て plugin/*/Install.pm な位置にあるファイル内で使用されている
$wiki->add_handler()
$wiki->add_user_handler()
$wiki->add_admin_handler()
のいずれかのメソッドですので、基本的には、plugin/*/Install.pm 内を探すとよいでしょう。 >>264
LIST の場合、wiki.cgi のあるフォルダ内の全階層の *.pm について単純に "LIST" で検索してみると、
% cd (wiki.cgi のあるフォルダ)
% find . -name '*.pm' -print | xargs grep LIST | grep 'add_.*handler'
./plugin/core/Install.pm: $wiki->add_handler("LIST","plugin::core::ListPage");
%
という結果になりますので、LIST を実際に処理するのは、
plugin/core/ListPage.pm
であることが分かります。 >>265-267
思いのほか素早いレスに感謝です。
無事に日付け部分を表示せずに済むようになりました。
加えて .pm の探し方まで丁寧にご教示いただき重ねて御礼申し上げます。
FSWiki の存在を数年前に知り、当時は色々とカスタマイズしていました。
FSWikiは登録してある項目名が文章中で自動リンクできるところが便利なので、ここにきて
足掛け３年かけて作成した膨大なコンテンツを整理するために再び FSWiki を引っ張り出しています。
すべての項目を登録しおわりますとおそらくはLIST表示の下段に5000個くらいのリンクが表示予定なので
今回お教えいただいたList.pmを元に段組表示や下段リンクを全て表示しないように研究してみます。 メモ用の Farm を作ってメモしています。ある程度育ってきたら、そのページを
公開用の Farm に移したいのですが、ファイル名がわけわかりません。画像などの
添付ファイルも同様にわけわかりません。文章はともかく、ファイルを別ページに添付しなおすのは
非常に面倒です。どの程度育つかわからないメモ毎にはいちいち Farm 立ち上げてられないし、
みなさんどのようにしてますか？運用のアイディアなど聞かせてもらえるとありがたいです。 Farm とは、全く異なる複数の Wiki サイトを運営するための仕組みです。複数の Wiki として使えるのに、FSWiki の system は 1 個で済ますことができるのがメリットです。
しかし、Farm 間でデータを連携する機能は基本的に持っていません。したがって「ある程度育ってきたら、そのページを公開用の Farm に移す」というのは非常に困難です。
そこで、「ページを未公開で作成し、完成したら公開」するには、ページ毎の公開/非公開設定を利用するのが一般的と思います。すなわち、「環境設定」において
ページの閲覧：誰でも可能
ページの参照権限のデフォルト値：ログインユーザのみ可能
と設定しておいて、ページ作成開始時はログインユーザのみ閲覧可能になるようにしておき、編集はログインして行います。
ページが完成したら、ページ編集フォームでそのページの「ページの参照・更新権限」を「全員に公開」に設定変更してページを公開します。
アドバイスありがとうございます。そうですか、Farm 間の移動は難しいですか。
ファイルさえわかれば結構きれいに移せるんですけどね。残念。
権限の設定で隠すというのは、なぜか一覧には全部出てしまうと信じて疑ってませんでした。
試してみたらちゃんと隠されるんですね。新しいカテゴリだと、カテゴリリストにカテゴリ名だけは
出てしまうのが困りものですが、ダミーのページを置くなどしてごまかす工夫をしてみます。
ありがとうございました。 ファイル名は分かりますよ。
farm 名が abc/def/ghi,
ページ url が http://*/wiki.cgi/abc/def/ghi?page=ABCDEFGH
であるとき、その Wiki ページソースファイルは下記にあります。
./data/abc/def/ghi/ABCDEFGH.wiki
また、そのページに添付された添付ファイル qwerty.jpg は下記にあります。
./attach/abc/def/ghi/ABCDEFGH.qwerty%2Ejpg
日本語ファイル名の場合、ABCDEFGH は url エンコードされていますが、対応は上記のままです。
ただ、ファイル名が分かって farm 間で手動コピーしたとしても、
コピー先の farm での管理ファイルの整合性がどこまで自動で再構成されるかは
十分検証してから運用する必要があるでしょう。 ページはともかく、添付ファイルがわけわからなくなると思ってたんですが、
そうか、ページ名も下書きのうちはアルファベットで書いとけばいいのか。
でも面倒なんで権限の設定でやります。 ログイン時に入力するパスワードが気になるんですが、Digest 認証のような感じで行われているのでしょうか。
まさか平文？ joycityなんだけどアンインスコしてダウンロードしなおしたら日本語にできなくなった
なぜだろう？ 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
SEDPW7N3M6 
