現在私のところで削除済みのページが上位に表示されたりpopularで困っていたりするわけではない、という立場での意見ですが。
popularの結果には現存しないページを表示しないほうが良いです。ノイズであり、誤クリックを誘発します。
これはあえて表示しているというより、popularが原始的な仕様で色々な状況に対応できてないという印象です。ただ稼働負荷的にはシンプルさに優位性であるのかなと。
うちのアクアちゃんにpopuralrの仕様を調べてもらったところ、基本的なpopularの動作は以下のように理解しました。
例えばCOUNTER_DIRに各ページ名のcounterファイルが格納されpopularはこれを読み取って集計する。
counterファイルには削除済みやリネーム済みのファイルも含まれるが、popularはこれを見分けてないので全部拾ってくる。
ページ削除と連動してcounterファイル削除させると、それが誤操作だったり悪意によるもだったとき復旧できなくなる問題がある。
安全側に倒してとりあえず残しておこうという感じに見えます。しかしそうなるとここには過去のファイルが残り続けて、現存ページに加えてどんどん増大していきます。
ただ https://z.wikiwiki.jp/wikiwiki/topic/13 によればwikiwikiは独自仕様なので異なる部分があるかもしれません。
上記の前提で具体的にどうなればいいか、個別の案を列記すると。
popular集計を現存ページのみにフィルターする
popular2やpopularxは現存ページだけ表示されるようなので、その処理を噛ませればいいように思います。
ただこれをするとサーバー負荷が増える問題があるのかもしれません。
また結局古いcounterファイルが溜まり続ける問題は解消しません。popularの表示動作として、現存しないページはリンクしない
現存ページと見分けが付かないし、クリックしてもページエラーになるだけなので。
ただ結局、現存ページとマッチするかの処理が入るので前案と大差ない気もします。管理者メニューでページ名counterファイルを削除できるようにする
管理人が誤操作や荒らしを判断。
popularに単純集計されなくなるので問題が根本的に解決する。
COUNTER_DIRをダイエットすればサーバー負荷が減る。
ただ実装の大変さがあるのかもしれません。
UIとしては以下のようなものが望まれます。- 現存しないcounterファイルをリスト表示して、チェックボックスでまとめて消せるようにする
- 可能ならテーブルにして、カウンター数、最終アクセスを横並びにする、できればソートも
- 可能なら全てのcounterファイルをテーブルにして、カウンター数を変更できるようにする(リネームで引き継げない問題対応)
- UIが色々大変なら代替えとして、各ページ(存在しないページも)にcounterファイルの編集リンクを設置する(管理者用)
実体はスペース区切りの単純なテキストファイルと思われる。
数値を変更したり、全消しでファイル自体を削除できるようにする。
- 現存しないcounterファイルをリスト表示して、チェックボックスでまとめて消せるようにする
リネームしたときにカウンターを引き継げるようにする
これは本来あるべき動作だと思います。
>> 14に同意です。
変更はplugin_rename_get_files()で簡単にできると、アクアちゃんが提案しています。バックアップを取れるようにする
色々いじれるようになって事故の恐れを考慮するなら
色々書いてみましたがこれを活用できる場面は限定的と思われ、以下あたりなら程よく実現できるのではないかと思います。
- リネームしたときにカウンターを引き継ぐ(counterファイルもリネームして前のファイルは残さない)
- 各ページにcounterファイルの編集リンクを設置する(管理者用)
counterの仕様はそのようになっているんですね、勉強になります。
(アクアちゃんとは？と思いましたが...)
その上で、counterファイルを手動で弄れるようにする(管理者によるカウンターのリセットや編集を許可する)というのは反対です。
>> 14さんが仰っている通り管理者の無用な手間を増やすことになるうえ、結局の所管理者が荒らしてしまえば元も子もなく、任意リセットはcounterの価値を無くすものと思います。
そうした点では、ページ削除の操作によってcounterファイルに任意の識別子を付与し、popular側ではその識別子を元にフィルターすることを提案します。
リネームに関してはどのような手法を取っても復元不可能となるリスクがありますが、「ページ名の変更」操作を行った場合のみ自動でcounterを書き換えるような処理を追加すればよいのではないでしょうか。
アクアちゃん
今のお話の中にあったリンク の先のページの一番下に、重要な情報が見られます。
つまり、今の動作（削除済みのページも表示される、名前変更後に値が継承されない）は不具合でも想定外でもなく、すべて承知の上での仕様だということです。
また、「数ページ程度であれば手動で反映いたします」ともあります。推測になりますが、利用されることがほとんどないと見込まれるので、削除機能を提供するよりも手動で応じたほうが楽、という判断である可能性があります。
不具合でも想定外でもない意図どおりの仕様に変更を迫ることは、もちろん容易ではありません。周到な準備が必要です。
注目すべきは、運営さんからの返信にある「これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わる」という部分です。
これらをクリアした上での提案でないと、変更には応じてもらえないわけです。ひとつひとつ、考えてみましょう。
利用者全体の公平性
話題の対象が利用者全体なので、「私が必要としている理由はこれです」のような話をしても意味がない、ということです。（逆に「私には全然必要ありません」も無意味です）
新しい機能が自分にとって無縁の機能であっても、他人にとって利用価値がある機能なら、使わない人にとっても納得できます。
逆に、ごく一部の人しか喜ばない機能を作るようでは、不公平感が高まります。
つまり、使う人が多いということを示す必要があります。
これは容易ではありません。簡単に思いつく手段はアンケートですが、統計的に意味のある量のデータを集めることはほとんど不可能に思えます。
となれば、「ほとんど誰も使わないのでは？」という懸念となるような事案をひとつひとつ丁寧に、単なる決めつけではなく確かな理論的背景をもつ説明をしていくしかないように思います。
ここまでの話の中で上がっている懸念を簡単にまとめると、以下のとおりです。
システム負荷
負荷の量やメカニズムについては、私などより01vさんのほうがよほど詳しいようです。
すこし目線を変えると、「負荷をどう減らすか」も重要ですが別のアプローチとして「要望する機能の価値を明らかにする」という手段も視野に入ります。
負荷が同じでも価値が高いなら、「しない」から「する」に傾かせることができます。
やみくもに「使う・要る・欲しい」と言うのではなく、具体的にどう役立つかを示せれば、提案に有利に働くでしょう。
運営方針
これはちょっと、私には意味がよく分かりません。
ただ、今回の要望が運営方針に対する悪影響の懸念がある、というのは確かに思えます。
この辺を明らかにし、その対策を含んだ提案をする必要があります。
いいえ。自分が必要している話をすべきです。
私は必要ありませんの意見も意味があります。
公平性は気にするべきですが、それが本論ではありません。それは色々な意見をみて決定と実行をする運営が考える事です。
私は現在困ってませんが、提示されたpopularの結果をみれば機能として使えないし、その回避策は煩雑で無駄な負荷をかけてることがわかります。この状況は多量のリネームや削除で自分にも容易に起こるとに気が付いたので、意見を述べています。一方でpopularなんて重要では無い立場の人も居るでしょうから、それはそう言えばいいです。例えば使ってないからコストや負荷かける価値を感じないという意見も良いと思います。
二つの意見は論点が交わらないので、言いっぱなしでいいです。無理に議論や説得をしなくていいです。
運営さんからの応答をもう一度読み直してほしいのですが、公平性に対する懸念は私一人の判断や価値観から出てきたものではなく、運営さんから指摘されていることです。
「様々な意見を見て決定する」という部分にはある程度同意しますが、「それが本論ではありません」の部分は経緯に対する誤解が見られるので同意しません。
いいえ違います。
そこの主語は不明確ですが運営であるべきです。そうでないなら運営の認識が誤りであるというのが私の意見です。
ユーザーには利用状況も内部の原理や負荷も見えないので議論になりません。何をもって公平かなど、気持ち次第でなんとでも言えるので、そこをに注力して話をしても発散するだけです。
今の運営さんの話を元にしても議論にならない、という点については確かにそうかもしれません。
しかし最終的な判断を下すのは結局のところ、運営さんなのです。
なんとかしてもう少し運営さんから話を引き出さないと、お互い（運営さん＆機能追加を求める意見）の話がかみ合わない可能性があります。
これは&counter_editみたいなプラグインを作って、必要に応じ各ページやメニューに仕込めばよいと考えました。現在の標準レイアウトに手を入れずに、必要な時だけ表に出し、不要になったら外せばいいです。