-PukiWiki Adv. 1.0.1.tar.xz がダウンロード出来ない。 -- [[初心者]] &epoch{1351310985,comment_date};
-アップロードしなおしておきました。こんどは大丈夫です。 -- [[Logue]] &epoch{1351312683,comment_date};
-ありがとうございます。ダウンロードできました。index.phpの37行コメントアウト忘れているような気がします。 -- [[初心者]] &epoch{1351323490,comment_date};
- すみません!中国語版のWebサイトはhttp://weiji.meyito.com/に変更されました。ご清聴ありがとうございました!私は中国語の翻訳に貢献して頑張りたいと思います。 -- [[迪艾維爾]] &epoch{1352074912,comment_date};
-ありがとうございます。利用者が増えるとフィードバックが多くなり開発の参考になるため助かります。 -- [[Logue]] &epoch{1352118359,comment_date};
-wikiに共通してあって欲しいんですけれど。ページ単位にデータを保持する為の領域を持ってはいけないもんなんでしょうか。プラグインも記事内からマッチさせて探し、書き換えみたいな徒労が多く。また、膨大なデータになるとmatch自体が速度のボトルネックになって来ますよね。そしてプラグインも作りにくい・メンテしにくい・カスタマイズしにくい。プラグイン次第でwiki以外の形式(例えばBlog形式やBBS形式)も実装し易く、応用も多く出来ると思うんです。実装としてDBを実際に使うか、それともwikiページデータに内包するかはどっちでもいいと思いますが。編集側についてはwikiのコンセプトどおり上部タブの「編集|凍結|差分|~」の序列からそのデータ自体を編集者が書きかえれる事も出来たほうが良い(場合によってはデータ部分のみの凍結とかも)。製作的には、記事内で#plugin_hoge('keyName');のような形式で設置させて。プラグイン内でその情報をハッシュにでもして渡してくれれば記事を作って返すだけ。後はwikiが#plugin_hogeを表示上置き換えれば適用も問題ないと踏んでいるんですけど。実装が面倒とか、もう既にあるよとか、コンセプト的におかしい、って感じあるんすかね? そもそも要望強すぎですか?w -- [[豆]] &epoch{1356625094,comment_date};
--ついでに。送信時にえらい重い環境だからか、二重送信をついしてしまいがちです。これは環境依存の問題ではありますが、UIの観点から防止すべきと思います。「変更をサーバーに反映しますか?」と聞くぐらいなら、送信中を明示させる程度の対応がWeb2.0的ではないでしょうか。 -- [[豆]] &epoch{1356630219,comment_date};
---つうか、「変更をサーバーに反映しますか?」でキャンセルしても適用されてません? -- [[豆]] &epoch{1356630476,comment_date};
---一応、二重送信を禁止するシステムは備わっています。他にも送信ボタンを押したあと、送信ボタンを無効化するってことも考えていましたが、不具合が多かったので見送ってますが。&br;ソースを見る限り、重たい処理はアンチスパム関係ですね。ページ内の追加されたURLをチェックする処理とか重いようです。このへんは、設定内容をキャッシュ化したり、ロジックを変える方向で考えています。 -- [[Logue]] &epoch{1356648427,comment_date};
--ええ。マッチさせてrequireで読み込む形式なので、確かにボトルネックが多いと感じていました。今回autoloadを用いた実装((参考:http://havelog.ayumusato.com/develop/php/e269-bench_autoload_require.html))に変えている理由がまさにそれです。必要となったタイミングで読み込まれるためその分ボトルネックが減ると考えています。(いささかリソース不足なので開発が遅くなっていますが・・・) -- [[Logue]] &epoch{1356648238,comment_date};
---いや、そこでなくってですね… 例えば顕著な例ですと、そのBugTrack。これはリストを作るときイチイチ記事を読んできて、内容をマッチさせて値を拾ってくるもんだから、100件を超える内容を抱えると、恐ろしいぐらいリソースを食う。なんというか構造的に超不毛ですよね。ならばどこかにインデックスをファイル出力するか、隠しページにでも書きこんどきゃいいか、って方法に(自分の低脳では)なるんですが。これも根本的解決には程遠いというか美しくないんですよね。じゃあいっその事、『記事単位でDBライクな領域を持っとけばいいんじゃないの?』ってのが個人的見解なんです。ページタイトル。タグやカテゴリ情報。カウンタなんかのプラグインで利用する値・データ。やり方によってはファイル自体もバイナリで(あくまで例)。そういうものを統一的に置ける領域。そうすれば、アクセスしやすく、記事とデータをほぼ完全に分離でき、Blog方式のようなwiki書法外にも比較的融通がしやすい「かも」な、と。ライトユーザーの敷居は上がるかもしれませんが。(そしてここまで言っといてBugTrackのような特殊な構造にはmatchを封印できるという「かも」でしかないんですが…)そこまで求めるならWikiじゃなくていいじゃん。とかそこまでやるならガチDB使うわ。とか思うとは思うんですが… 要は疑問。明確な要望になるというのならBugTrack出します。駄文失礼。 -- [[豆]] &epoch{1356713023,comment_date};
---要は、BugTrackやTrackerでページごとに必要な内容を別に保存するという話でしょうか?現在のところ、リストで使う内容をキャッシュするという発想でどうにかしようと考えています。リストが呼び出されたタイミングで、そのページのキャッシュを作成し、次回からはそこの情報を取得する。あとは、キャッシュの日時とページの日時を比較してキャッシュが古かった場合にキャッシュを作りなおすって実装になるとおもいます。 -- [[Logue]] &epoch{1356736979,comment_date};
-とりあえず、要望であればBugTrackのほうにお願いします。 -- [[Logue]] &epoch{1356682593,comment_date};
-FastCGIで動かしているのですが、malformed header from script. Bad header=IE=edge: index.phpとのエラーが出力され500エラーが発生します。1.0.1.tar.xzです。 --  &epoch{1357620223,comment_date};
--環境によって起こるバグみたいです。参考:[[BugTrack/22]] -- [[Logue]] &epoch{1357649823,comment_date};
---ありがとうございます。 --  &epoch{1357699049,comment_date};
-“代码转换的简体中文拼音”で、どのようなコードをしたいですか?例をしたいと思います...たぶん私は助けることができます。 -- [[迪艾維爾]]  &epoch{1359341522,comment_date};
--一覧の索引付の処理を中国語にも対応させようと考えていて、そのために漢字熟語をPinYinに変換するコードが必要になっています。&br;中国語での索引のつけ方はよくわかりませんが、簡体字、繁体字など、異字体が多い((例えば日本語の「広」は、簡体字では「广」、繁体字では「廣」になる。この漢字の発音はgwong2なので、この漢字の繁体字と簡体字の読みはGにカテゴライズされるべきである。))ので、おそらくPinYinで処理したほうがいいと考えています。 -- [[Logue]] &epoch{1359358316,comment_date};
--結局自力で作ってしまった→[[PinYin.php>https://github.com/logue/pukiwiki_adv/blob/e1172dd76019753e9d81811cd5775f38f07a2579/wiki-common/lib/PukiWiki/Lib/Text/PinYin.php]] -- [[Logue]] &epoch{1360071279,comment_date};
-各ページにある、facebookやtwitterのボタンを表示させないようにするにはどうしたらいいでしょうか。Skinを見てみたのですが、見つけることができませんでした。(1.0.2を使用) -- [[KK]] &epoch{1360931333,comment_date};
--スキンではなくskin.jsで実行しています。これは、ハードコーディングされているので、skin.original.jsの該当箇所をいじってrun.batを実行するしかありません。 -- [[Logue]] &epoch{1360999698,comment_date};
---返信ありがとうございます。run.batにはjavaなどが必要のようなので、現環境では実施できませんでした。設定で各ボタンの有効・無効が選べるようになるとありがたいのですが、ご検討いただけると幸いです。 -- [[KK]] &epoch{1361769946,comment_date};
---[[5687d2bf94>https://github.com/logue/pukiwiki_adv/commit/5687d2bf94c9ebcbc9044b75c75949350484e9d2]]の修正で、テキストエリアで右クリックしたときのバグを修正するついでに“とりあえず”変更できるようにしました。スキンファイルのJavaScriptでpukiwiki.custom.socialの名前空間で、設定をオーバーライドしたりできます。例えば、twitterを無効にしたい場合は、@@pukiwiki.custom.social.twitter.use = false;@@、GREEを有効にしたい場合は、@@pukiwiki.custom.social.gree.use = true;@@というようにスキンのJavaScriptに入れます。 -- [[Logue]] &epoch{1361803765,comment_date};
-管理サイトURLはどこで変更できます?get_script_absuri();でつまずいてます。 -- [[XYZ]] &epoch{1363352803,comment_date};
-v1.0.3で通常の読み書きができるようになったのですが一覧が表示できません、&type=sitemapは出てきます。何の設定が悪いことが考えられますか? --  &epoch{1365909954,comment_date};
-2.0-betaで一覧を表示させようとすると「Fatal error: Class 'PukiWiki\Text\MeCab_Tagger' not found in /home/public_html/wiki-common/lib/PukiWiki/Text/MeCab.php on line 119」と表示されます。
どのように対処すればよろしいでしょうか? -- [[ほし]] &epoch{1388893609,comment_date};
-バグのようです。pukiwiki.ini.phpは2.0のものを使用していますか? -- [[Logue]] &epoch{1388985078,comment_date};
-2.0のものを使用し、デフォルト状態での動作を確認していたので、特に編集したという部分はありません。 -- [[ほし]] &epoch{1389008602,comment_date};
-ちなみにMeCabのパスもデフォルトのままの状態です。(デフォルトのパスで導入済み) -- [[ほし]] &epoch{1389011712,comment_date};
-上記のことではないですが、現在pukiwiki plus をメインに使っていますが
移行するにあたって現状の環境とほぼ同程度まで持っていきたいので、
2.0の仕様、特にプログラム関係の記述方法なんかが分かればなと思います。
改造するにしても機能を追加するにしても仕様が分からないと手がつけられないので(´・ω・`) -- [[ほし]] &epoch{1389012160,comment_date};
-とりあえず、Mecabを無効化してみてください。もともとPukiWikiではMecabはページ名の読みを取得する目的でしか使用していません。2.xではこの機能をMecabなしで本体に内蔵しました。若干精度は落ちるものの、デフォルトで、リストはページ名の読みの順に表示されます。 -- [[Logue]] &epoch{1389049160,comment_date};
-2.0の最大の特徴はオブジェクト指向でコア部分が書きなおされているところです。新旧対応表はlegacy.phpを参照してください。簡単に説明すると、Wikiデーターを基準に設計しているためWiki.phpあたりを確認するといいかもしれません。また、実際のデーターの入出力はWikiFile.phpで行っています。(AbstractFile.phpも参考にしてください。これはSplFileInfoクラスの拡張です。)convert_html.phpに相当する機能は、Rendererディレクトリ内のファイルが行っています。 -- [[Logue]] &epoch{1389049609,comment_date};
-MeCabに関して以下の環境でエラーが吐き出され使用できないことが判明しました。&br;
Apache 2.4.7 にて php-fpm で運用する場合以下のエラーが出ます。&br;
Fatal error: Class 'PukiWiki\Text\MeCab_Tagger' not found in /home/public_html/wiki-common/lib/PukiWiki/Text/MeCab.php on line 119&br;
&br;
ちなみに php-fpm を無効にしたら正常動作しました。(一覧ページ)&br;
またMeCabを無効にしても上記のエラーが出るため Apache 2.4.7 でのphp-fpmの運用は現状できません。(自分の環境のため他の方の環境で同様のエラーが出るかは不明)&br;
ちなみにPukiWiki Advance しか試していないので他のPHPスクリプトに影響があるかどうかは不明です。 -- [[ほし]] &epoch{1390386648,comment_date};
-質問箱がまだ作成されてないのでこっちで・・・&br;
現在デバッグモードで動作させていますがphp-mecabをインストールしてあるにも関わらず以下の文が表示されます。&br;
Mecab is stdio mode. Please concider to install php-mecab in your server.&br;

これって解決策ってあるのでしょうか?
ちなみにMeCabもphp-mecabも最新バージョンを入れてあります。 -- [[ほし]] &epoch{1390391951,comment_date};
-おそらく、[[php.iniでphp-mecabを読み込む設定>http://weble.org/2011/09/26/php-mecab]]になっていないと思われます。MeCabTaggerのエラーについては、MeCab.phpの先頭にuse MeCab_Tagger;の行を加えてみてください。 -- [[Logue]] &epoch{1390451131,comment_date};
-いくつかMeCab関係で分かったことを・・・&br;
Apacheでmpmをpreforkで動作させた場合のみMeCabが有効に、&br
workerおよびeventで動作させるとMeCabが無効になる模様です。&br;
よってデバッグモードでMecab is stdio mode. Please concider to install php-mecab in your server.が出ていたのは正常だった模様です。&br;
eventで動作させていたので上記メッセージが出たようです。&br;
ただ、自身の環境での状態なのでコンパイル時の設定によってはprefork以外でも動きそうではあります。&br;
&br;
ちなみにMeCab.phpの先頭にuse MeCab_Tagger;を加えたところ以下のように出ました&br;
Fatal error: Call to undefined method MeCab_Tagger::keyword() in /home/public_html/wiki-common/lib/PukiWiki/Text/MeCab.php on line 122&br;
keywordメソッドが存在しないようなので110行目と122行目を以下のように変更したら動きました。&br;
return $mecab->keyword($input);→return $mecab->parse($input);&br;
&br;
行数はuse MeCab_Tagger;追加後の状態での行数です。 -- [[ほし]] &epoch{1390497887,comment_date};
-サイトマップを表示させようとすると以下のエラーがでます。&br;
This page contains the following errors:&br;
&br;
error on line 3 at column 13: XML declaration allowed only at the start of the document&br;
Below is a rendering of the page up to the first error.&br;
 「&」や「<」「>」等の処理がしっかりとなされていないと表示されるようです。&br;
 ちなみにAdvの公式サイトのサイトマップを表示しようとしても上記のエラーがでます。&br;
&br;
Warning: Invalid argument supplied for foreach() in wiki-common/plugin/list.inc.php on line 42&br;
 配列でないときに表示されるようです。 -- [[ほし]] &epoch{1392822222,comment_date};
-Listingクラスの仕様変更したときに昔のコードのままだったようです。鯖移転工事が終了したら取り掛かりたいと思います。 -- [[Logue]] &epoch{1392896761,comment_date};