雑談/12

雑談の過去ログその12

フッター部分のpukiwikiのバージョンとphpのバージョンについて
雑談
Behaviourで判別する spam blocking, etc
PukiWiki 2.0?
commentスパムについて

フッター部分のpukiwikiのバージョンとphpのバージョンについて†

はじめまして。pukiwikiのデフォルトでフッターにpukiwikiのバージョンとphpのバージョンを表示していますが、セキュリティ的に問題ないでしょうか？攻撃者に攻略方法を教えているようなものに思えるのですが。 -- mashiki 2007-07-07 (土) 04:44:04
- こんにちは、ApacheやPHPのバージョンを外部に通知するかどうか、という話題と同様に扱って下さい。 -- henoheno 2007-07-09 (月) 00:26:31
- コメントありがとうございます。Apacheのバージョンはpukiwikiデフォルトでフッタについていないので問題ないと思いますが、PHPのバージョンを外部に通知するかどうかという話題はどちらでされているのでしょうか。思いつくキーワードでofficial／devを検索してみましたが見つかりませんでした。 -- mashiki 2007-07-10 (火) 01:40:40
- 伝わっておりますでしょうか。ApacheならApacheでバージョンを公開するかしないか選択するオプションがあります。PHP expose_php のような設定があります。それを出すのかどうか、という話題と同様にPukiWikiも扱ってください。 -- henoheno 2007-07-10 (火) 07:34:35
- 回答ありがとうございます。phpバージョンが出てくる意図が分からないことと、導入/バージョンアップの度に消すのも面倒だったので、デフォルトで表示されない、もしくは、pukiwiki.ini.phpの設定でワンタッチで非表示にできると、いろいろな人が助かるのではないかと思ったのですが、skin直接修正でも十分簡単ですね。PHP expose_phpの設定は知らなかったので勉強になりました。ありがとうございます。 -- mashiki 2007-07-11 (水) 00:24:19
- 参考になるかどうか分りませんが。
  【PHP TIPS】 10. PHPのイースターエッグを見つけ出そう： ITpro -- hirokasa 2007-07-11 (水) 21:02:04

↑

雑談†

PHP4の終わり
(概略)2007-12-31以降、PHP4.4へのアップデートリリースはされません。重大なセキュリティーに関する修正も、基本的には2008-08-08までしか行いません。 -- ぃぉぃぉ 2007-07-15 (日) 04:13:01
- PHP4についてはちょっと驚きです。PukiWiki 1.4.x のスタンスに変化がないという点は触れておくべきかな。折角なので明日にでも、1.3.x の話と一緒にアナウンスします。 -- henoheno 2007-07-16 (月) 00:51:22
ini.php他諸々に入ってるコメント文、英文ばかりなので設定変更とかが勘任せ…。出来れば、コメント文の日本語版も用意して貰えると、物凄く嬉しいですわ。どうぞよろしくお願いいたしますｍｍ -- ぽち 2007-07-15 (日) 21:42:47
- ふむ。こういう文書(まだ完全ではない)を見た後で印象は変わりますか? プログラムのコメントを各言語ごとに維持するのはとても大変だし、概要や基礎知識を説明する場所が無い(そこでやるべきでない)ので、ドキュメントとして分離させるのが本来あるべき形だと思います。それこそApacheやPHPのように。もちろん以前のsambaの設定ファイル(euc版)のように、外部のグループが各国語版を作るのもいいとは思います。-- henoheno 2007-07-16 (月) 00:44:17
  - 早速の回答、ありがとうございます。例文見せてもらいましたが、もうちょっと分かりやすく簡潔な方が助かるかなぁ…なんて、思ったりしなくもなく。なんというか、ユーザ向けというより、プログラマ向けな感じの印象？　ですが、やっぱりあると違いますね。機械翻訳とは全く違う意味だった箇所とかも結構ありますし…orz -- ぽち 2007-07-16 (月) 08:21:06
henohenoさん、spam対策プラグイン実装お疲れ様です。
個人的にはspam.inc.phpはantispam.inc.phpとかの名前だと良かったなぁ。(今のところ自分は全部認証をかけて書き込み禁止にして使っていますので、導入必要性はないですがw) -- ぃぉぃぉ 2007-07-30 (月) 13:05:17
- lib/spam.php とセットなので勘弁してやって下さい。antiなんて飾りです。偉い人には(略 -- henoheno 2007-07-31 (火) 00:14:16
- CVS追いかけていないので、lib/spam.phpとか知りませんでした。後で見てみます。
  lib/の方にもantiの飾り付けを....。まあ普段spamと入力するわけでもないし、そんなに気にしてはいませんけどｗ -- ぃぉぃぉ 2007-07-31 (火) 12:29:36
http://d.hatena.ne.jp/stealthinu/20070725/p2　の件ですが、エントリー内容一部修正しました。特にspam.ini.phpのメンテをされている方(henohenoさん、で良かったでしょうか？)にはご迷惑お掛けして申し訳なかったです。他の修正するときリファラーで気がついたのですが、コメントいただけるともう少し早く対応できたと思うので、またへんなこと書いてるようでしたらコメントいただけるとうれしいです。 -- さとう 2007-08-01 (水) 09:38:08
- Against : 開発日記/2007-07-29 anti-anti-spamのあれこれ
- spamについてあれこれ取り組まれている方のご意見を頂戴したいので、今回のフォローに関しても、「試した結果どうだったか」を書いていただけませんでしょうか。行動を伴ったコメントをいただかないと、読者として参考になりません。*1なお、既存のURI追加型spamの話題も検証いただけるとなおありがたく。*2 -- henoheno 2007-08-02 (木) 00:58:19
- 確かにhenohenoさんの言われてることはもっともな話だと思います。なので、最新版での環境整えて、いくつかのパターンで検証してレポートしたいと思います。(最初、URI追加型spamがわからなかったのですが、BugTrack2/200見てなにを指しているのか理解しました。) -- さとう 2007-08-02 (木) 13:16:01
PukiWikiとAdobe Flex 2を組み合わせて何かやりたくてウズウズしています。どなたか既にやっている方はいらっしゃいませんか？ -- 2007-08-07 (火) 12:18:46
- 外していてしかもありきたりかもしれませんが、画像やリッチな方面のニーズを書いておきます。簡単なテキスト文法から、図をレンダリングするやつが欲しいです。「図もまじえて会話する」までには色々あって至らないかもしれませんが、目標はそういう方向です。テキスト文法は、ソースを見るだけでもその意味が解り、ついでに~~通信料~~通信量が削減できるのが望ましいです。例えば電車の路線図を表現するとすると -- henoheno 2007-08-07 (火) 23:37:41
```
#graph(network,border=1){東京周辺の路線図}
[[山手線]]: -[[新宿]]--[[神田|20,55]]-[[東京]]-[[有楽町]]-[[新橋|90]]--[[新宿]]- line=stripe,greenyellow&something
[[中央線]]; -[[]]-[[三鷹]]--[[新宿]]--[[東京|pin]] line=stripe,orange
```
- ・・・とでも preformatted の文法で書いておいたのを見て、flashなどが有効なユーザーに対しては良きに計らってくれると有り難い。本当はモデリング機構も欲しいけれど、単発作成ソフトならともかく、まだそんな時代じゃないしCMS側のバックエンドも貧弱(ASPでもない限りね)。そして実は高コストなのでWikiのスタイルがいいです。ページ全体をflashにするのも強すぎるし*3。・・・危ないのは見飽きているので、危なくないやつがいいです。 -- henoheno 2007-08-07 (火) 23:40:43
開発日記/2007-08-13の「実行例と称しアフィリエイトつきリンクを張る行為はお断りしています」とは、自作プラグインのソース／実行例を公開しているサイトにアフィリエイトがあることを制限しているのでしょうか？それとも、実行例で示しているリンクが直にアフィリエイトのURLという解釈でしょうか？(経緯を知らないもので、すいません。) -- 2007-08-14 (火) 16:53:20
- 例えば、amazonのある商品に対する検索結果のまとめやblog記事などをまとめただけのページはダメみたいな意味なのでは？ -- Logue 2007-08-14 (火) 18:36:48
- 「リンク先の状態」もいずれ取り扱わなければならないかもしれませんが、この下りはofficialのページに、amazonのアフィリエイトつきリンクを貼り付けられたという事例をふまえたものです。 -- henoheno 2007-08-16 (木) 00:15:55
  - 了解しました。そのような事があったとは知りませんでした。 -- 2007-08-16 (木) 10:02:53
変数と型について。
一つの変数を複数の型にして使用することの是非。(BugTrack2/266より) -- ぃぉぃぉ 2007-08-30 (木) 01:52:05
- とりあえず、E_ALLでも何も警告されないので、仕様上その使い方は間違っていない。 -- ぃぉぃぉ 2007-08-30 (木) 01:56:59
- 同じ変数を異なる型で使うというのは、一つの変数が場合によって異なる意味を持つと言うことで、あまり望ましくないのでは? -- ぃぉぃぉ 2007-08-30 (木) 01:56:22
- http://www.php.net/manual/ja/language.variables.php マニュアルをみても、その使い方がいけないとは書いていないが、よいとも書いていない。
  一つの変数を複数の型にキャストして使用することは可能であるとは読める) -- ぃぉぃぉ 2007-08-30 (木) 01:59:19
- cvs:../devel/followup_htmlを参考にベンチマークプログラムを作って試してみましたが、型変換で若干のオーバーヘッドはありそうでしたが、実用上問題になるほどではありませんでした。(Win2k) -- ぃぉぃぉ 2007-08-30 (木) 02:05:47
- 自分ならメモリによほど困っていなければ型が変わるときには変数も変えると思いますが、結局のところ好みの問題で、同じ変数を使い回してもよいと思います。 -- ぃぉぃぉ 2007-08-30 (木) 02:09:10
開発日記/2007-09-03の「添付ファイルの一覧」の件ありがとうございます。official はケアするつもりがなかった*4ので助かりました。
ついでにdev で主に手を出していたことをメモすると、
1.) 一覧が表示されていないと送付ファイルが残っているのかがわから無いので、ページ内になるべくリンクを埋めるようにした。
2.) AutoLink 設定をON にしていた時代には勝手にリンクされていたであろう、BugTrack/763 をBugTrack/763 に書き換えた*5。
の2点をメインに手を加えていました。 -- 2007-09-04 (火) 19:30:58
過去ログ: 11を作りました。（2005年7月～2007年7月の約2年間分のログ） -- 2007-09-11 (火) 22:36:54
- お疲れ様でした -- 2007-09-12 (水) 02:13:06
BugTrack/266から移動。
私としては「戻る」を押したときに必ずリロードされるのが気に入らない、と思うこともあります。初心者向けだと、古いバージョンが履歴に残らないほうがよいという考え方なのでしょうか。ちなみにOperaではリロードされなかったかも知れません。 -- pai 2007-09-12 (水) 01:25:09
- BugTrack/584とか関係ありかな? -- ぃぉぃぉ 2007-09-13 (木) 02:42:01
はじめまして。BugTrack2/62が凍結だったのでこちらに書かせていただきます。TrackBack関係で:config/plugin/referer/configがまだcvsにも残っていますが、もう削除してもいいですよね :-) -- Makichan 2007-10-03 (水) 10:15:05
「org:」を使ったInterWikiName を、「official:」にあらかた置換え完了。
今「org:」で検索して出てくるのは、凍結していて書きかえれなかったページかInterWikiName として使っていないものだけになったかと。 -- 2007-10-17 (水) 01:37:53
- 置き換えている間に、いろんなページを見たので、ついでに提案 => (BugTrack2/282)
ページ内容を書き換えているspamがあります。削除する前にバックアップを確認する事を心がけてください。 -- taru 2007-11-09 (金) 22:01:22
- どこのことですか -- 2007-11-10 (土) 00:29:07
- PukiWiki/1.3/自作プラグイン/isbnでしょう。 -- 2007-11-10 (土) 00:31:36
皆様、お久しぶりです。pukiwiki-users MLにメールが流れていますように、(財)日本情報処理開発協会というところから、「pukiwikiをベースに、新しいコラボレーションツールの研究開発をしたいので、開発メンバーの人に委員として参加して欲しい」と依頼が来ています。今年度中に、3回程度、夕方に委員会を開くとのことです。私個人的には興味があるのですが、交通費をあまり出せないとのことなので、大阪在住の身としては、ちょっと参加は無理です。どなたか、東京近郊在住の方で、興味のある方はいらっしゃいませんでしょうか？　そういえば、最近、pukiwiki開発にまったく関わっていないなーと思う、今日この頃。なんせ、忙しくって。でも、また再開したいなー。日本語索引のmecab対応あたりから、手をつけましょうか。 -- 三浦克介 2007-11-21 (水) 12:37:42
- なんだか、すでに、人数いっぱいみたいです。 -- 三浦克介 2007-11-21 (水) 15:13:40
- 誰もいなかったら、行ってみようかな～なんて思ってたんですが・・・ (^^; -- teanan 2007-11-21 (水) 20:20:53
- 応募者多数で選考なのかしら。MLの特性が活きましたね。その一方で、とりあえず現時点では、今動いているcommitter二名は本件に関与していないという事になりますから、この点では希望通りではなかろうと思いますけれども、具体的な情報はありませんから何とも言えません*6。一方的な期待としては、(PukiWikiに限定せずとも)後先考えずに表面的な場当たり対応を繰り返す事例は枚挙に暇が無いので、目先の新しさにとらわれずに、後に積み重なるような、メンテナンスと運用コストが小さい成果物を構築をしていただけると嬉しいですね。つい先日もせつない事例を見たばかりなので、Wiki Wayは必携という事でお願いします。 -- henoheno 2007-11-21 (水) 23:52:25
CVS のログを見ても昨年より更新がありませんが、活動は継続しているのですか？ -- 2008-02-10 (日) 18:14:44
- もちろん継続しています。各個人が無理の無い範囲内でやっておりますので進まないこともあります*7 (^^; -- teanan 2008-02-11 (月) 05:58:54
- コメントありがとうございます。どのプロジェクトでも、CVSリポジトリの状況まで見ていただけるような方の来訪は歓迎すると思います :) teanan さんが水面下でも着実に活動しているという事は表明させて下さい。各自が、各自のペースで、なるべく少ない労力で活動できる、というのが私にとっては理想の環境(社会人を考慮したオープンソースプロジェクト的に)です。私の方はBugTrack一本文程度の後片付が一つ、やっとできるかもしれない状況です。 -- henoheno 2008-03-05 (水) 23:03:44
- ちなみに私の生存状況はteananさんやぱんださんには解ります。 -- henoheno 2008-03-05 (水) 23:08:32
sf.jpのphpが5.2.0になるらしいです。そろそろ開発時のphp4対応はやめてもいいのかなぁ...。 -- ぃぉぃぉ 2008-03-05 (水) 17:15:24
- お疲れ様です。誰がやるとしても、1.4系が主なターゲットである「PHP4」から大きく外れる事は無いでしょう。存在意義の一つを失うだけでなく、製品としての寿命を縮め、ソースコードに混乱と矛盾を負う事などが予想されるからです。ただ、維持(特に再設計)のためのコスト削減という観点から、下限を戦略的に引き上げる試みはあって良いと思います。具体的には、現状の 1.4系列は PHP 4.1.2 を実質的なターゲットの下限としています。これを現時点で言えば PHP 4.3.0 に引き上げるのは、妥当かつ ~~一定の~~ かなり効果がある試みだと思います*8。下限を計る一つの指標としては、 サポート下にある Debian GNU/Linux や Red Hat Linux などで採用されているPHPのバージョンの下限があります*9。 -- henoheno 2008-03-05 (水) 22:42:37
- 視点を変えると、PHP5に取り組む方がいても構わないのですが、長続きしないと思います*10。仮にPukiWiki の次期コードベースを(戦略的にでも、結果的にでも何でも)作る人がいたら、その人は ~~Perl6を~~ ~~Lispを~~ PHP6を狙うと思います。 -- henoheno 2008-03-05 (水) 22:42:51
  - Debian GNU/Linuxではphp5.2.0～5.2.3、Red Hat Linuxの後継のFedora Core4以降ではphp5以降が採用されています。
    別にphp4をサポートしたらいけないとは思いませんが、サポートからはずす方が楽になると思います。(上のコメントを見ると、php5をサポートすると大変、というように読めますが、すでにサポートしているのだから、php5に絞った方が楽ですよね、と言っているだけです。) -- ぃぉぃぉ 2008-03-12 (水) 03:27:38
- PukiWiki開発のマンパワーが広いバージョンをサポートするコストを上回っているなら、サポートするPHPのバージョンの下限を下げておくのは良いと思います。
  サポートするには評価環境が必要で*11、このsf.jpが評価環境のひとつですよね。PHP5.2.0になってしまうと、PHP4系列の評価環境は別に用意しないといけなくなりますね。
  ここで主なターゲットがphp4とおっしゃられていますが、official:Q＆A/動作環境を見ると、php5もターゲットに入っています。
  新たにphp5に対応するのであれば「ソースコードの混乱や矛盾」の危険性もあるかもしれませんが、ターゲットからphp4系をはずすことでそういう問題は無いと思います。
  といっても、あえてphp4をサポート対象からはずす必要はありませんけどね。 -- ぃぉぃぉ 2008-03-06 (木) 02:13:07
- 開発が終了したphp4対応をしていくというのは、たとえばPukiWikiにおきかえると、のプラグイン作成時にPukiWiki1.3系にも対応するようなものかなぁ、と思うのです。phpを使ったアプリを開発する立場としては、php開発元が勧めに従って、ユーザーに対して最新のphpを使うように勧めるくらいでもいいのではないかなぁ。 -- ぃぉぃぉ 2008-03-06 (木) 02:21:37
- PHPプログラムを作っている方にはこの辺りの事情を抑えておいて頂きたいのですが、ターゲットの下限は、利用できる関数やその機能差についてコードベースに明確な基準をもたらします。例として PHPマニュアルの preg_grep() の第三引数の仕様をご覧下さい*12。下限を 4.3.0 にするだけでも大分楽になるはずです。 -- henoheno 2008-03-11 (火) 01:23:16
$notimeupdate = 1になっているみたいですけど、前からでしたっけ? 設定ミスなら修正お願いします。 -- ぃぉぃぉ 2008-03-06 (木) 19:00:53
- official:WebTrack/7 でofficial の方は対策されましたけど、dev はどうでしたっけ？少なくてもここ1、2年は、ずっと「$notimeupdate = 1」でdev を運用しているみたいですけど。 -- 2008-03-06 (木) 19:24:22
http://sourceforge.jp/tracker/?atid=713&group_id=166&func=browse の、リクエストID 12039 の内容ってSPAM ですよね？ -- 2008-03-27 (木) 19:27:16
最適化　http://d.hatena.ne.jp/koto2/20080518/1211070116　http://labs.unoh.net/2007/05/phptips.html -- 2008-05-22 (木) 15:01:56
- ↑を、BugTrack/779 - クリンナップのまとめに書き写す？ -- 2008-05-22 (木) 19:35:01
- コメント欄に書いておきました -- 2008-05-23 (金) 10:02:29
最近、タイムスタンプを書き換えないSPAM が多いような・・・。リスト表示がおかしくなるBugTrack, BugTrack2 の配下ページへの書き換えは、すぐ気づくからまだいいんですけど・・・。 -- 2008-09-24 (水) 00:16:38
- いつもありがとうございます。私のところにメールが飛んでいますので把握しています。:) -- teanan 2008-09-28 (日) 03:56:45
- 最近のサイトメンテナンスの全てはteananさんによるものです。 -- henoheno 2008-10-01 (水) 21:12:19
- spamの削除等は有志の方にやって頂いております。大変助かります、ありがとうございます。 -- teanan 2008-10-02 (木) 15:54:02
PHPカンファレンスの資料ミラーであるhttp://pukiwiki.sourceforge.jp/PHPconference2003/ が見れなくなっています。（sf.jpがPHP 5系になったから？）
official:PukiWiki/活用事例/研究・教育支援にもリンクがあるので、復旧の予定があるのかは知っておきたいのですが。 -- 2009-04-09 (木) 20:57:11
PHPのPearでwiki関連(wiki文法のレンダリングなど)のパッケージが開発/配布されています。pukiwiki対応の拡張ってできるのかな？調べてみたいが、pukiwik以外のwikiを知らないので敷居高い。 -- masiki 2009-06-14 (日) 10:44:28

↑

Behaviourで判別する spam blocking, etc†

すぱむ投稿週間が実施されているんでしょうか？書き戻し作業など対応されている方、お疲れ様です。 -- 2008-05-20 (火) 09:43:01
- 結構しんどいですね・・・。根本から断ち切りたいところ。 -- teanan 2008-05-20 (火) 20:35:45
普段排除されているPOSTと同じIPからであるかどうかをチェックした上、もし一致する傾向があるならば、自動的に排除できないだろうか、などと思っています。 -- henoheno 2008-05-25 (日) 23:14:48
- spamを投げる側の多くに対しては、「手段ごとにいちいちIPを使い分けない(悪用する回数が "1" の事はある)」経済的な事情を期待できるので、spamを受ける側にとっては「複数の手段による投稿者IPが、ある程度まばらに一致する(手段A、B、Cを使うspam手法が、IPの群a、b、c からまばらにやってくる)であろう」と見込みを立てられます。*13この点については、URIを含まないゴミ投稿のspamを送るIPが、URIを含むspamを送るIPに含まれているかどうか、過去の通知メールと照合すれば裏付けできます。実際におおむね一致しています。 -- henoheno 2008-05-27 (火) 00:12:28
- こうしたcontextを持つIP群は、その量や質に比例して、例えblockしたとしても、false positive な誤判定を起こしにくいであろうと期待できます。 -- henoheno 2008-05-27 (火) 00:15:37
- 前提として、どこかにヒントと推論を保存しなければなりません。spamディレクトリみたいな専用の入れ物がここで必要になります。IPだけの切り口で見た場合、サーバーあたりのIP悪用回数が1である広範囲spam(誰にも認識されていない1つのIPを利用した広範囲spam。各サーバーに1回しかpostしないものとする)に対しては、サーバー間で情報を取り持つような手法でしか減らすことができないでしょう。攻め手側の機械的/連続的な挙動を、サーバー間での(最小のコスト・・・主に帯域の)連携によって妨害するためには、birthday attack ならぬ birthday block とでも呼びたくなるような手法を取り込む事になると思います。(こんな大味な機構だけなら、別にPukiWikiでしなくてもいいと思う・・・) -- henoheno 2008-05-27 (火) 00:17:00
- 「IPアドレスによるブロック機構」だけでは、Webサーバーやファイアウォールといった、より適切な手段があり、また、将来の別のソリューションと組み合わせられるとはその時点で不明すぎるため、あまり爆発力が見込めません。そうした考え方同様に、IPをある程度キャッチするだけの機構に、簡単な排除機構を組み合わせただけでは、展開が弱いと思われます。そこで、「入力を振り分け、最適化された形で検証し、それを入力にフィードバックする」機構を、PHPに偏らないように、身の丈に合わせて考えた後、そこから生まれるニーズを個別の機構に戻して再設計する方が、トータルで見て苦しむ時間が少ないのだろうと思っています。 <= 設計に関してはいまここ -- henoheno 2008-05-27 (火) 00:23:10
それなりに文面を整理。JordanCさんの仕事にコメントしたいんですが余力が・・・＿＿。＿ﾊﾟﾀｯ -- henoheno 2008-05-28 (水) 00:47:58
It's so simple it doesn't really need explanation does it?-- JordanC 2008-06-10 (火) 04:50:46
Just to note. I mistranslated the term "moron", which is most effectively "baka" in JA, but it came out as "Retardation". I do not mean to call henoheno a retard, he is a coder, but I dislike people who require comments everywhere rather than just running the code, and seeing what it's indent was. It wasn't as if it was a huge HUGE piece of code I added that was so incomprehensively gargantuan, it was just a small bit that bundled the plugin handlers together and scraped all the crap code there was in there. -- JordanC 2008-06-10 (火) 05:24:04
if ($ignore_numeric_keys) { <-- Why does this need a comment? The variable tells you what it does -- JordanC 2008-06-10 (火) 05:27:56
- I guess JordanC-san misunderstand henoheno-san's comment. I translate it into English for JordanC-san.
  -I arranged contents somehow. I want to comment about JordanC-san's work, but I'm too busy .... -- ぃぉぃぉ 2008-06-11 (水) 22:54:38
- Another translation : "JordanCさんの仕事にコメントしたいんですが余力が・・・" => "I should investigate his works I know, but no more energy for now ... ____._ <- breakdowned" -- 2008-06-12 (木) 21:00:33
近況はいかがでしょう？「開発日記」の年内更新はありそうな気配ですか？？ -- 2008-12-26 (金) 12:53:57
- こんにちは。spam.php から届いたメールが溜まっているメールボックスを(事後分析の目的で)読むプログラムを細々作っているのですが、Common Lispのイディオムを知らなすぎて大変です。明日明後日というレベルでは、整理という意味でspam.php周りのコミットが若干入ると思います。 -- henoheno 2008-12-27 (土) 01:03:15
  - プレッシャーはかけませんので、従来通りでよろしくお願いします。名無しの身ですが陰ながら応援いたします。 -- 2009-01-07 (水) 21:39:23

↑

PukiWiki 2.0?†

Are there any definite plans for PukiWiki 2.0, that can be divulged in english? Any form of roadmap that has been set up, planned features, code changes, or is it going to be the same tit-for-tat coding style? By the way, the next code that I submit will, for each function have a long haiku explaining what it does. Afterall, comments must be in useless places just so if you're not using your brain, you can waste more time reading pointless comments. -- JordanC 2008-06-10 (火) 23:18:09
ロードマップ ? -- 2008-06-11 (水) 19:56:47
Kind of old. -- JordanC 2008-06-11 (水) 22:32:57
コミッターが関わっている中で一番新しいroadmap のページは、ロードマップだと思いますが。PukiWiki2 のページは、ユーザーの議論の場・・・ですよね？ -- 2008-06-12 (木) 00:42:54

↑

commentスパムについて†

officialで、何も変更がないのにRecentChangesの上に上がってくるので変だなぁと思ったんですが、理由の想像がついたので記載しておきます。
- commentプラグインのactionで、#commentが無いページにメッセージを書こうとすると、ページ内容は書き換わりませんが、タイムスタンプだけは更新されます。spammer達はpostだけ行ってspam書き込みしようとしているんだなぁ。 -- ぃぉぃぉ 2008-06-13 (金) 18:12:53
There is still development ongoing, but the wiki doesn't need updating - the code does. As per the spam issue, there needs to be a patch submitted to fix the direct-post issue. -- JordanC 2008-06-24 (火) 22:15:22

total:
today:
yesterday:
now: 1

フッター部分のpukiwikiのバージョンとphpのバージョンについて†

雑談†

Behaviourで判別する spam blocking, etc†

PukiWiki 2.0?†

commentスパムについて†

最新の16件