Wiki系とWikiEngineについて語るスレ Part5
簡易に更新が行えることからBlog的な使い方もされているプログラム。
コラボレーションが容易であることもその重要な利点。
比較的プログラムがシンプルなため改造等も盛ん。
そんなWikiについてﾏﾀｰﾘ語っていきましょう。
= 過去スレ =
Part1 http://pc2.2ch.sc/test/read.cgi/php/1060739206/
Part2 http://pc2.2ch.sc/test/read.cgi/php/1014252667/
Part3 http://pc5.2ch.sc/test/read.cgi/php/1079702729/
Part4 http://pc11.2ch.sc/test/read.cgi/php/1106478373/
>>2-4 に続く
PukiWikiスレ Part6
http://pc11.2ch.sc/test/read.cgi/php/1173615817/
=== MediaWiki 管理者の集い 第2版 ===
http://pc11.2ch.sc/test/read.cgi/php/1183501450/
FreeStyleWikiスレ
http://pc11.2ch.sc/test/read.cgi/php/1151389730/
【BLOG】CMS総合スレ2【Wiki,XOOPS】
http://pc11.2ch.sc/test/read.cgi/hp/1162287963/
Blog/Wiki関連技術総合
http://pc11.2ch.sc/test/read.cgi/php/1085471483/
ホスティング型無料Wikiサービス
http://pc11.2ch.sc/test/read.cgi/esite/1106932023/
Wiki
http://pc11.2ch.sc/test/read.cgi/friend/1108531582/
日本発の Wiki Wiki Web リンク集
http://www9.ocn.ne.jp/~ymt/wiki/
日本発の wiki クローンリスト
http://www1.neweb.ne.jp/wa/yamdas/column/technique/clonelist.html
http://www1.neweb.ne.jp/wa/yamdas/column/technique/clonelist2.html
Wiki Wiki Web リンク集
http://folksonomy.sakura.ne.jp/wiki/wikiengines.html
日本発Wikiエンジン - コンパクトなWikiエンジンリンク集
http://www.hyuki.com/yukiwiki/wiki.cgi?%C6%FC%CB%DC%C8%AFWiki%A5%A8%A5%F3%A5%B8%A5%F3
資料/Wiki関連/Wikiエンジン/インデックス - Walrus, Digit.
http://digit.que.ne.jp/work/index.cgi?%e8%b3%87%e6%96%99%2fWiki%e9%96%a2%e9%80%a3%2fWiki%e3%82%a8%e3%83%b3%e3%82%b8%e3%83%b3%2f%e3%82%a4%e3%83%b3%e3%83%87%e3%83%83%e3%82%af%e3%82%b9
WikiYallow
http://wiki.yallow.info/
Wiki ばな（参加者募集中）
http://wikibana.socoda.net/
WikiMatrix - Compare them all
http://www.wikimatrix.org/
WikiCreole: Home
http://www.wikicreole.org/
2 年 10 ヶ月前と状況はあまり変わっていませんが……適当に行きましょう。
ﾐ・д・ﾐ ＜ほっしゅほっしゅ！
""""
[[○○○|http://××/img/.jpg]]
http://××/img/.jpg
と記述すると勝手に画像が直接表示されてしまいます。
元の画像がかなり大きい為に、画面のバランスが崩れてしまうので困っています。
サムネイルで表示する方法、それが出来なければ直接画像を表示しない方法はないでしょうか？
Wikiの「誰でも書ける」って特性は重要だし
そもそもCMSってなんか面倒なのが多い
手軽なWikiの方がいいよ
妄想は脳内で留めておいてよ。
じゃあ日記系以外で面倒じゃないCMSを教えてくれ
知っているがおまえの態度が（ｒｙ
どんだけWiki文法の説明しないといけないと思ってるんだ？
誰でも「習得すれば」書ける、に訂正だな
ほかにも何だって
外部から編集できなけりゃ意味ないだろ
＠Wikiが良い例
HTMLの直接入力、Wiki文法、WYSIWYGのエディタこれらを自分にあった形式で
自動的に使い分けれるCMSになってWikiのようなバージョン管理が出来ればいい
後からフォーマットの変更ができないために
最初にWYSIWYGモードでページ作られてると、文章が書きづらくて泣ける
http://hp.vector.co.jp/authors/VA007799/viviProg/doc5.htm
DB を使っているか否かということが分かりませんでした
PukiWiki を運用してみまして、
１．データ量が増えてくると使いものにならなくなってくる
２．Wiki 内の検索がおばか
以上の点で悲しい思いをしており、DB を使うタイプの Wiki へ移行したいのですが、
そういった DB 使用の Wiki エンジンリストはどこかにありますでしょうか？
ご存知の方がいらっしゃいましたらお教えいただきたく、どうぞよろしくお願いいたします
俺が今作ってるよ！
まあそれはそれとして
MOONGIFTで「Wiki」カテゴリを表示させて
その中から「MySQL」などのカテゴリがついてるのを探せば、いくつか見つかる
ただし英語のものがほとんどだけど
MediaWiki も運用しているのですが大層すぎますので…
PukiWiki ほどではないにせよ、もう少しライトな感じのものがあればと思っていました
と思って MOONGIFT なるところで探していたら良さそうなものが見つかりました
UTF対応で日本語編集・表記もできるようなので実装してみようと思います
# ソースとドキュメントが英語だとハードルに感じてしまって良いものを逃がしてしまうのが日本人の残念なところ？！
なにはともあれ、レスしていただきましてありがとうございました！
# 個人的には PhpTiddlyWiki / KamiWiki みたいなのが IE にも完全対応すれば、
おもしろいかなぁと思ったり思ってなかったり
ライトでSQLで良さそなのは何を選んだの？
参考に教えてけろ。
DekiWikiか？
俺も入れたけど、けっこう重かったよ。
ちなみに俺のお勧めはDokuWiki。
スペル似てるけどｗ
DB使わないんで対象外かもしれないけど、いろいろ試した中で一番良いWikiだと思う。
WikiMatrixで調べれば、一番適したのが見つかるかもね。
http://www.wikimatrix.org/
書くテーマが複数あるので複数設置したい。
複数設置で Engine とかファイルを共有した人いる?
Moinmoin/ だけ使い回しして設定デイレクトリとcacheと生成ページだけ別に出来ないかな。
どのWikiもテストしているうちは軽くていいんだけどページ増えると不安だ。
検索するとき以外はあんまり関係ないとは思うけど。
非力なNASで動かしているけど、一番軽く、高機能なWikiだと思う。
逆にMySQL使うCMSやWikiのほうが遅いよ。NASのメモリが少ないせいもあるとは思うけど。
あと、これは人によるけど、MySQLよりファイルのほうがバックアップが簡単だよね。
>何でページ増えると重くなるの？
・リンク先のページが存在するかどうかのチェック
・サイドバーでの新着表示
実際にどの辺から重くなってくるのかは環境や用途による
てか、そんなにリンクするのかな？
新着表示も、普通更新時に行うんじゃない？
ユーザー別に既読とかを分ける処理するん？
DokuWiki立てました。
良かったら是非。
会社内でdokuWikiを１年間運用してます。
（Mantisと組み合わせてバグレポートとしても併用）
説明書とか手順書とかガンガン書いてるけど、重たくはならないねえ。
仮想鯖でメモリ512ぐらいなんだが余裕。
ただ、デフォの検索はちょっと悲しい。
前文検索でＭｅｃａｂ＋Sennaでもやろうかと思っているところ。
ページ量産は全然問題ないけど、一つのページに長文書くとちょっと重たい時はあるぐらい（それは、どのCMSでもそうだろうけど）
pukiWIKIは会社でみんなで使ったら１ヶ月で重たくなって止めた。
ごめん、DB使ってなかった。。。
すまんです・・・DB使用時は不明・・・
DB使ってなくても軽く感じるということは
DB使えばもっと軽く感じるのかも？しれませんね
PukiWiki系は自身だけでは検索が使えなさすぎてorz
Plug-inを使って外部検索を呼び出す手がありますけれど、
その手はセキュリティ的にアウトだったりして／(^o^)＼
検索には都合いいんだろうけど。
DB専用のサーバを立てればそんなことになりませんよ
同時アクセスが非常に多いケースや、検索が頻繁に行われるのでなければDB無くても大丈夫じゃないかと思う。
DokuWikiをMecab使って使用してるけど、ちゃんとINDEXしてるからDB無くても比較的検索は早いと思う。
キャッシュも個別対応しているから、レスポンスで困ることはあんまり無いよね。
DBにすれば何でもパフォーマンスアップっていう妄想は持たない方が良いかと。
で、>>32のサイトはそんなに膨大なアクセスがあるんだろうか？
SENNAどうよ？
http://qwik.jp/senna/FrontPageJ.html
> その手はセキュリティ的にアウトだったりして／(^o^)＼
なにそれ？言ってる意味が分からない。
ちゃんと整理した方が良いよ。
本当にDB使ったWikiなら悩みが全て解決するのかね？？
そうであるなら、WikiMatrixでDB対応のWikiを探せばいいじゃん。
http://www.wikimatrix.org/
どれくらいの規模のシステムの話してるんだ？
ページビューや更新の頻度は？
要求スペックは何msのレスポンスなんだ？
てか、速度を要求されるのはViewなのか検索なのか？
せめて現状のシステムスペックや環境と、改善したい内容の詳細を
明確にしたほうが、期待した回答が返ってくると思うよ。
どこのコンサルよ？
PukiWikiみたいにページ数が増えたらとたんに重くなるんじゃ、不安になると思うけど。
１．データ量が増えると。。。ってのはDBだから解決されるか冷静に考えてみた方が良いかと。
遅くなる原因は明確になってるん？ 原因あっての解決策だから。<-重要
なんとなく、そんな気がするでは駄目ですｗ
２．検索の方は、精度を改善したいのであればDBとか関係なくて、INDEXの方法だよね。
詳しい方々、ツッコミよろしく。
22は>>25で解決してるみたいだから、
ここ最近の流れは>>32が発端だと思うよ？
既に回答もあるみたいだけど、DokuwikiはDBサポートしていないですね。
でも、ページ増えても重いと感じたことは無いです。（といっても2000ページ程度の内部用ですが）
P3 1Gで512MB, Debian/Apacheです。
重いの定義は人によるだろうけど。
>>51の例に出てるPukiWikiはちゃんと見てないけど、重くなる原因は設計にあるんではないかな？
DekiWikiとか高機能なWikiも試したけど、DB対応でもそれ以前にLogic部分が重くてストレスだった。
MySQL版のDokuWikiもあるよ
ttp://www.marssoft.de/doku.php?id=software:sqlwiki
それ恥ずかしくないの？
年末年始はゆっくりストレス発散できるといいね！＼(^o^)／
プギャー m9（＾o＾）
別管理しているWikiがあれば教えて下さい。
タイトルは日本語にしてURLは英語にしたいんですが、
いまのところHikiしか見たことないです。
WIKI全般に関わることなのでこちらに書き込みました。
WIKIにおいて、うまくユーザーに記事をたくさん投稿してもらうにはどうしたらいいのでしょうか？
また皆様が行っている工夫も聞かせてもらえたら嬉しいです。
Wiki の編集って、結局大なり小なりその Wiki 特有の編集ルールを覚える必要があって
多くの利用者はそのようなルールのハードルが高いと感じるようです
上の方で話題に出ているDokuWikiは、設定でそういう風に変えられるっぽいよ。
ありがとうございます。
投稿用フォームですか。
たしかに文書を書くルールが垣根になりますね。
設定ってこれかな？平仮名と片仮名だけみたいですね。
ttp://wiki.splitbrain.org/wiki:romanization
簡単だから導入してみれば分かるさ。
useheadingを使うと目的のことができました。
DokuWiki初めて使いましたがなかなか良さそうです。
ありがとうございました。
目的達成できたみたいで良かった。
Dokuwikiはテンプレートもいっぱいあるから、デフォのシンプルなのじゃなくて
多機能なWiki風にすることもできるよ（実際多機能だけど）
公式のプラグインサイトにあった2つは違う機能のようですし・・・
本当はDekiWiki使いたいんですが、レンタルでは無理っぽいですね
もしかして俺だけだったりするの？
DokuWikiで「<=」を入力したら自動で左矢印に変換されてしまいます。
どうすれば「<=」を表示させれますかっ？
なんかあった？
Hikiでgoogle-sitemapsプラグインを使っているのですが、
googleウェブマスターツールで必ずエラーになってしまいます。
Hiki使いの方、上手くいってますか？
ありもしないアドレスにアクセスしたとき、
404エラーを返さないっぽいのが原因なのかな…？
HikiのMLで質問してみてはいかがでしょ。
どうもwikiでも日本人は他人の書いた部分を消したがらない傾向があるような気がする。
訂正したい時はその下にコメントを追加して、さらに原著者が返事をして…と
掲示板のようなやりとりになり、さらに結論が出た後もそれを消さないから
読者は最後まで追わないといけなくなる。
あと、情報が更新されたときも打ち消し線はやめてほしい。
読者が知りたいのは最新で正確な情報だけであって、討論ページや更新履歴は
本文とは分けてほしい。
…と、最近打ち消し線だらけの仕様書を見て怒りがこみ上げたので思った。
スキルアップのためにwikiエンジンを作っているのですが
行頭に+で番号付きリスト、-で通常のリストという文法をしているとき
+ リスト1
- リスト2
+ リスト3
のリスト3は、「2. リスト3」か「1. リスト3」のどちらがユーザにとっては
親切なのか判断がつきません。
実装的には後者のほうが楽なのですが、前者もできないわけではないので
多い方を採用しようと考えています。
みみっちい話で申し訳ありませんが、よろしくお願いします。
そもそも「前者の方が親切かも」と思った理由は何なんだ
olとulを交互に使いたくて、しかも番号を続けて欲しいときなんて、そう無いと思うんだが
PukiWikiModのところでたまたま見かけたバグトラックの内容です。
ttp://xoops.hypweb.net/modules/pukiwiki/2458.html
こういう考え方もあるのか、と開発の参考にしようと考えていたのですが
ほとんどのwikiは番号振り直しで、結局どっちなんだ…と悶々としていた経緯がありまして…。
別の（以前の）ブロック要素の内容に依存するってありえないだろ。
やっぱりその考え方はマズいですか…。
>>85
リスト2とリスト3の間に改行があるかということで判別、ということでしょうか？
いろいろ考えた末、>>84さんの方針に合わせる仕様にします。
参考にさせて頂きます。>>85さんも、ありがとうございました。
更新履歴のページは 画像 や &ruby(,) の展開が有効になっていますが、
一覧のページ(IndexPage)はそのままのWikiのソースが表示されます。
これは自分でなんとかしたほうがよいんでしょうか？
もし先人がすでになんとかしているなら教えていただきたいんですが、、
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>);
携帯端末のようなモバイルブラウザからもみられるように
簡単にコンテンツの切り替えができるようなウィキってありますか？
なかったら自分で作るしかないかな。。
ルビ定義を青空文庫形式とかで記述できると嬉しい
携帯でもルビ表現するとなると、ぎちぎちにテーブル組むしかねえかな
コード汚いけど、、
効率も良いし楽だし見やすくﾈ？
http://www.hiragana-gateway.com/
こういうのもあるけど、変換ミスもあるからなあ。。
今、pukiwiki以外のwikiを使ってみようと思ってpmwiki、dokuwiki、mediawikiをUTF-8モードで評価中
その中で気づいたことに数日つまづいてる
新規ページ作成方法のひとつ「URLに存在しないページ名の入力」があるよね？
これ、Windows上でIE6、IE7、Firefox2から日本語を入力するとShift-jisで送信してしまい、文字化けしたページを生成してしまう
だから、pukiwikiのように弾くか、文字化けを修正して正常なページを作成したい
これを対策してる人はどんな方法を使ってるかご教授願いたいです
Wikipediaも未対策で文字化けするんだよね、Linuxだと問題ないけど…
該当箇所のファイルをチェックして、修正すればいいんじゃね？
OSの問題じゃないよ
「文字コード (wiki名)」でググれば、なんか出てくるカモよ
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
良い処方をご存じの方、ヒント等教えてください。
100〜のスレッドの続きを読む
