Wiki系とWikiEngineについて語るスレ Part5
■ このスレッドは過去ログ倉庫に格納されています
= 海外リンク集 =
WikiMatrix - Compare them all
http://www.wikimatrix.org/
WikiCreole: Home
http://www.wikicreole.org/ 落ちてしまっていたので立ててみました。
2 年 10 ヶ月前と状況はあまり変わっていませんが……適当に行きましょう。 ,,,,.,.,,,,
ﾐ・д・ﾐ ＜ほっしゅほっしゅ！
"""" 質問です。Hikiで
[[○○○|http://××/img/.jpg]]
http://××/img/.jpg
と記述すると勝手に画像が直接表示されてしまいます。
元の画像がかなり大きい為に、画面のバランスが崩れてしまうので困っています。
サムネイルで表示する方法、それが出来なければ直接画像を表示しない方法はないでしょうか？ バージョン管理が出来るCMSが出たら大抵Wikiなんていらんよなw >>9
Wikiの「誰でも書ける」って特性は重要だし
そもそもCMSってなんか面倒なのが多い
手軽なWikiの方がいいよ > そもそもCMSってなんか面倒なのが多い
妄想は脳内で留めておいてよ。 >>11
じゃあ日記系以外で面倒じゃないCMSを教えてくれ > じゃあ日記系以外で面倒じゃないCMSを教えてくれ
知っているがおまえの態度が（ｒｙ Wikiが誰でも書けるとか妄言はやめてくれよw
どんだけWiki文法の説明しないといけないと思ってるんだ？ WikiじゃなくてもWYSIWYGのエディタ搭載していれば編集はできる
＠Wikiが良い例
HTMLの直接入力、Wiki文法、WYSIWYGのエディタこれらを自分にあった形式で
自動的に使い分けれるCMSになってWikiのようなバージョン管理が出来ればいい
＠WikiでWYSIWYGが選択できるのは素晴らしいんだが
後からフォーマットの変更ができないために
最初にWYSIWYGモードでページ作られてると、文章が書きづらくて泣ける HTML と Wiki の両方で書けることが求められると思う テンプレにあるリンク先（消失していたところもあり・・・orz）をざっと巡ってみたのですが、
DB を使っているか否かということが分かりませんでした
PukiWiki を運用してみまして、
１．データ量が増えてくると使いものにならなくなってくる
２．Wiki 内の検索がおばか
以上の点で悲しい思いをしており、DB を使うタイプの Wiki へ移行したいのですが、
そういった DB 使用の Wiki エンジンリストはどこかにありますでしょうか？
ご存知の方がいらっしゃいましたらお教えいただきたく、どうぞよろしくお願いいたします >>22
俺が今作ってるよ！
まあそれはそれとして
MOONGIFTで「Wiki」カテゴリを表示させて
その中から「MySQL」などのカテゴリがついてるのを探せば、いくつか見つかる
ただし英語のものがほとんどだけど >>23-24
MediaWiki も運用しているのですが大層すぎますので…
PukiWiki ほどではないにせよ、もう少しライトな感じのものがあればと思っていました
と思って MOONGIFT なるところで探していたら良さそうなものが見つかりました
UTF対応で日本語編集・表記もできるようなので実装してみようと思います
# ソースとドキュメントが英語だとハードルに感じてしまって良いものを逃がしてしまうのが日本人の残念なところ？！
なにはともあれ、レスしていただきましてありがとうございました！
# 個人的には PhpTiddlyWiki / KamiWiki みたいなのが IE にも完全対応すれば、
おもしろいかなぁと思ったり思ってなかったり >>25
ライトでSQLで良さそなのは何を選んだの？
参考に教えてけろ。 >>25
DekiWikiか？
俺も入れたけど、けっこう重かったよ。
ちなみに俺のお勧めはDokuWiki。
スペル似てるけどｗ
DB使わないんで対象外かもしれないけど、いろいろ試した中で一番良いWikiだと思う。
WikiMatrixで調べれば、一番適したのが見つかるかもね。
http://www.wikimatrix.org/ あとはDB使うなら、TikiWikiあたりが面白いかもね。。 Moongift も入れれば良かったな。ちなみに matrix は足しといた >>4 Python で作られた Moinmoin や Trac の話題はここ?
書くテーマが複数あるので複数設置したい。
複数設置で Engine とかファイルを共有した人いる?
Moinmoin/ だけ使い回しして設定デイレクトリとcacheと生成ページだけ別に出来ないかな。 >>27 俺も DokuWiki 軽くていいとおもう。 DokuWikiをMySQLで使っている人いるかな？
どのWikiもテストしているうちは軽くていいんだけどページ増えると不安だ。 重くなる要素がわからんけど、何でページ増えると重くなるの？Indexのこと？
検索するとき以外はあんまり関係ないとは思うけど。
非力なNASで動かしているけど、一番軽く、高機能なWikiだと思う。
逆にMySQL使うCMSやWikiのほうが遅いよ。NASのメモリが少ないせいもあるとは思うけど。
あと、これは人によるけど、MySQLよりファイルのほうがバックアップが簡単だよね。 >>33
>何でページ増えると重くなるの？
・リンク先のページが存在するかどうかのチェック
・サイドバーでの新着表示
実際にどの辺から重くなってくるのかは環境や用途による ページに張られているリンク数によるけど、ページ毎の処理だから増えても重くならない気がする。
てか、そんなにリンクするのかな？
新着表示も、普通更新時に行うんじゃない？
ユーザー別に既読とかを分ける処理するん？
DB使うやつならWakkaｸﾛｰﾝ（UniWakka、WikkaWiki etc...）もｵﾇﾇﾒ http://127.0.0.1:8823/thread/http://pc11.2ch.net/test/read.cgi/php/1198593148/l2
DokuWiki立てました。
良かったら是非。
>>32
会社内でdokuWikiを１年間運用してます。
（Mantisと組み合わせてバグレポートとしても併用）
説明書とか手順書とかガンガン書いてるけど、重たくはならないねえ。
仮想鯖でメモリ512ぐらいなんだが余裕。
ただ、デフォの検索はちょっと悲しい。
前文検索でＭｅｃａｂ＋Sennaでもやろうかと思っているところ。
ページ量産は全然問題ないけど、一つのページに長文書くとちょっと重たい時はあるぐらい（それは、どのCMSでもそうだろうけど）
pukiWIKIは会社でみんなで使ったら１ヶ月で重たくなって止めた。 >>32
ごめん、DB使ってなかった。。。
すまんです・・・DB使用時は不明・・・ >>40-41
DB使ってなくても軽く感じるということは
DB使えばもっと軽く感じるのかも？しれませんね
PukiWiki系は自身だけでは検索が使えなさすぎてorz
Plug-inを使って外部検索を呼び出す手がありますけれど、
その手はセキュリティ的にアウトだったりして／(^o^)＼ DBがボトルネックになる場合もあるから一概には言えないと思う
検索には都合いいんだろうけど。 >>43
DB専用のサーバを立てればそんなことになりませんよ DBが効果ある場面って限られてるんでは？
同時アクセスが非常に多いケースや、検索が頻繁に行われるのでなければDB無くても大丈夫じゃないかと思う。
DokuWikiをMecab使って使用してるけど、ちゃんとINDEXしてるからDB無くても比較的検索は早いと思う。
キャッシュも個別対応しているから、レスポンスで困ることはあんまり無いよね。
DBにすれば何でもパフォーマンスアップっていう妄想は持たない方が良いかと。
で、>>32のサイトはそんなに膨大なアクセスがあるんだろうか？
> Plug-inを使って外部検索を呼び出す手がありますけれど、
> その手はセキュリティ的にアウトだったりして／(^o^)＼
なにそれ？言ってる意味が分からない。 なんか目的と手段が自分自身でも明確になってないんじゃない？
ちゃんと整理した方が良いよ。
本当にDB使ったWikiなら悩みが全て解決するのかね？？
そうであるなら、WikiMatrixでDB対応のWikiを探せばいいじゃん。
http://www.wikimatrix.org/
どれくらいの規模のシステムの話してるんだ？
ページビューや更新の頻度は？
要求スペックは何msのレスポンスなんだ？
てか、速度を要求されるのはViewなのか検索なのか？
せめて現状のシステムスペックや環境と、改善したい内容の詳細を
明確にしたほうが、期待した回答が返ってくると思うよ。 てか、DBが嫌いなだけなんじゃね？
PukiWikiみたいにページ数が増えたらとたんに重くなるんじゃ、不安になると思うけど。 つか、>22に少しは書いてあったのね。
１．データ量が増えると。。。ってのはDBだから解決されるか冷静に考えてみた方が良いかと。
遅くなる原因は明確になってるん？ 原因あっての解決策だから。<-重要
なんとなく、そんな気がするでは駄目ですｗ
２．検索の方は、精度を改善したいのであればDBとか関係なくて、INDEXの方法だよね。
詳しい方々、ツッコミよろしく。
>>52
22は>>25で解決してるみたいだから、
ここ最近の流れは>>32が発端だと思うよ？ なるほど。そうみたいですね。すみません。
既に回答もあるみたいだけど、DokuwikiはDBサポートしていないですね。
でも、ページ増えても重いと感じたことは無いです。（といっても2000ページ程度の内部用ですが）
P3 1Gで512MB, Debian/Apacheです。
重いの定義は人によるだろうけど。
>>51の例に出てるPukiWikiはちゃんと見てないけど、重くなる原因は設計にあるんではないかな？
DekiWikiとか高機能なWikiも試したけど、DB対応でもそれ以前にLogic部分が重くてストレスだった。
>>54
MySQL版のDokuWikiもあるよ
ttp://www.marssoft.de/doku.php?id=software:sqlwiki > P3 1Gで512MB, Debian/Apacheです。
それ恥ずかしくないの？ >>56=>>47=>>13
年末年始はゆっくりストレス発散できるといいね！＼(^o^)／ ページのタイトル(HTMLのtitleタグやh1タグ)とURLを
別管理しているWikiがあれば教えて下さい。
タイトルは日本語にしてURLは英語にしたいんですが、
いまのところHikiしか見たことないです。 プログラムに関係してはいないのですが、
WIKI全般に関わることなのでこちらに書き込みました。
WIKIにおいて、うまくユーザーに記事をたくさん投稿してもらうにはどうしたらいいのでしょうか？
また皆様が行っている工夫も聞かせてもらえたら嬉しいです。 投稿用フォームを作っておくと情報量はとりあえず増えますね
Wiki の編集って、結局大なり小なりその Wiki 特有の編集ルールを覚える必要があって
多くの利用者はそのようなルールのハードルが高いと感じるようです >>59
上の方で話題に出ているDokuWikiは、設定でそういう風に変えられるっぽいよ。 >>61
ありがとうございます。
投稿用フォームですか。
たしかに文書を書くルールが垣根になりますね。
>>62
設定ってこれかな？平仮名と片仮名だけみたいですね。
ttp://wiki.splitbrain.org/wiki:romanization
漢字も使えるよ。
簡単だから導入してみれば分かるさ。 >>65
useheadingを使うと目的のことができました。
DokuWiki初めて使いましたがなかなか良さそうです。
ありがとうございました。
>>66
目的達成できたみたいで良かった。
Dokuwikiはテンプレートもいっぱいあるから、デフォのシンプルなのじゃなくて
多機能なWiki風にすることもできるよ（実際多機能だけど）
DokuWikiに、blogのようにコメントできる機能はないんですか？
公式のプラグインサイトにあった2つは違う機能のようですし・・・
本当はDekiWiki使いたいんですが、レンタルでは無理っぽいですね
Moongiftが「次の結果」というリンクが機能していないんだけど、みんなも機能してないの？
もしかして俺だけだったりするの？ 質問させてください。
DokuWikiで「<=」を入力したら自動で左矢印に変換されてしまいます。
どうすれば「<=」を表示させれますかっ？ ttp://wiki.splitbrain.org/wiki:ja:syntax#記号 質問なので上げます
Hikiでgoogle-sitemapsプラグインを使っているのですが、
googleウェブマスターツールで必ずエラーになってしまいます。
Hiki使いの方、上手くいってますか？ やり方探していたら自分の書き込みが引っ掛かってﾜﾗﾀ
ありもしないアドレスにアクセスしたとき、
404エラーを返さないっぽいのが原因なのかな…？ >>75
HikiのMLで質問してみてはいかがでしょ。 打ち消し線というのは日本の文化なのかね？
どうもwikiでも日本人は他人の書いた部分を消したがらない傾向があるような気がする。
訂正したい時はその下にコメントを追加して、さらに原著者が返事をして…と
掲示板のようなやりとりになり、さらに結論が出た後もそれを消さないから
読者は最後まで追わないといけなくなる。
あと、情報が更新されたときも打ち消し線はやめてほしい。
読者が知りたいのは最新で正確な情報だけであって、討論ページや更新履歴は
本文とは分けてほしい。
…と、最近打ち消し線だらけの仕様書を見て怒りがこみ上げたので思った。 自分専用のスタイルシートを設定して非表示にすればいい >>77 と >>79 から導かれる結論→打ち消し線というのは日本の責任逃れ 質問ageさせていただきます。
スキルアップのためにwikiエンジンを作っているのですが
行頭に+で番号付きリスト、-で通常のリストという文法をしているとき
+ リスト1
- リスト2
+ リスト3
のリスト3は、「2. リスト3」か「1. リスト3」のどちらがユーザにとっては
親切なのか判断がつきません。
実装的には後者のほうが楽なのですが、前者もできないわけではないので
多い方を採用しようと考えています。
みみっちい話で申し訳ありませんが、よろしくお願いします。 >>81
そもそも「前者の方が親切かも」と思った理由は何なんだ
olとulを交互に使いたくて、しかも番号を続けて欲しいときなんて、そう無いと思うんだが >>82
PukiWikiModのところでたまたま見かけたバグトラックの内容です。
ttp://xoops.hypweb.net/modules/pukiwiki/2458.html
こういう考え方もあるのか、と開発の参考にしようと考えていたのですが
ほとんどのwikiは番号振り直しで、結局どっちなんだ…と悶々としていた経緯がありまして…。 便利だとか便利じゃないとかいう問題じゃなくて、あるブロック要素の内容が
別の（以前の）ブロック要素の内容に依存するってありえないだろ。 >>84
やっぱりその考え方はマズいですか…。
>>85
リスト2とリスト3の間に改行があるかということで判別、ということでしょうか？
いろいろ考えた末、>>84さんの方針に合わせる仕様にします。
参考にさせて頂きます。>>85さんも、ありがとうございました。 WalWikiの2.1.0を使っています。
更新履歴のページは 画像 や &ruby(,) の展開が有効になっていますが、
一覧のページ(IndexPage)はそのままのWikiのソースが表示されます。
これは自分でなんとかしたほうがよいんでしょうか？
もし先人がすでになんとかしているなら教えていただきたいんですが、、 87です。解決したかも？
473 #print qq(<li><a href="$url_cgi?@{[&encode($page)]}">@{[&escape($page)]}</a>@{[&escape(&g et_subjectline($page))]}</li>);
474 print qq(<li><a href="$url_cgi?@{[&encode($page)]}">@{[&escape($page)]}</a>@{[&inline(&ge t_subjectline($page))]}</li>);
なんか文字化けがひどい。。すみません
473 #print qq(<li><a href="$url_cgi?@{[&encode($page)]}">@{[&escape($page)]}</a>@{[&escape(&get_subjectline($page))]}</li>);
474 print qq(<li><a href="$url_cgi?@{[&encode($page)]}">@{[&escape($page)]}</a>@{[&inline(&get_subjectline($page))]}</li>);
すべての漢字に振り仮名を振れるようなやつで
携帯端末のようなモバイルブラウザからもみられるように
簡単にコンテンツの切り替えができるようなウィキってありますか？
なかったら自分で作るしかないかな。。 寡聞だけど興味あるな
ルビ定義を青空文庫形式とかで記述できると嬉しい
携帯でもルビ表現するとなると、ぎちぎちにテーブル組むしかねえかな >>87-89だけど今作ってるよ。
コード汚いけど、、 ひらがなに変換するサービスがいろいろあるからそれ使った方が
効率も良いし楽だし見やすくﾈ？ たしかにルビを打つのってめんどくさいよね。。
http://www.hiragana-gateway.com/
こういうのもあるけど、変換ミスもあるからなあ。。 wikiの質問はここでいいのかな
今、pukiwiki以外のwikiを使ってみようと思ってpmwiki、dokuwiki、mediawikiをUTF-8モードで評価中
その中で気づいたことに数日つまづいてる
新規ページ作成方法のひとつ「URLに存在しないページ名の入力」があるよね？
これ、Windows上でIE6、IE7、Firefox2から日本語を入力するとShift-jisで送信してしまい、文字化けしたページを生成してしまう
だから、pukiwikiのように弾くか、文字化けを修正して正常なページを作成したい
これを対策してる人はどんな方法を使ってるかご教授願いたいです
Wikipediaも未対策で文字化けするんだよね、Linuxだと問題ないけど…
文字コードの問題なら
該当箇所のファイルをチェックして、修正すればいいんじゃね？
OSの問題じゃないよ
「文字コード (wiki名)」でググれば、なんか出てくるカモよ WindowsXPにて cygwin + lighttpd + php5 + dokuwiki を使っているのですが、
wikiそのものは動作するのですが、スタイルシート動的生成が巧く動きません。
単独でphpが動作するか確認した所、
動作する場合と、動作しない場合を確認できました。
×
cd /
php-cgi /var/www/dokuwiki/lib/exe/css.php
×
cd /var/www
php-cgi /dokuwiki/lib/exe/css.php
×
cd /var/www/dokuwiki
php-cgi ./lib/exe/css.php
○
cd /var/www/dokuwiki/lib/exe
php-cgi ./css.php
良い処方をご存じの方、ヒント等教えてください。 ■ このスレッドは過去ログ倉庫に格納されています
