あまり公式コミュニティで話すことではないですが、どんなwikiプラットフォーマーでも収益減とサーバーリソースのアンバランス化に直結するwiki移転をおいそれと認めるわけにはいかないでしょう。 トラブルが頻発しているとか、収益が上がらない割にリソース喰らいになっているといった、むしろ出ていってくれた方が厄介払いになるケースを除いて移転の提案が上がること自体がwiki運営にとって有害です。 信用の安定をとるか収益の安定を取るかの違いだと思います。いい顔ばかりして運営自身と他wikiの首を締めるのも困ります。
そのルールが定められた経緯は分かりませんが 記載されている以上、相応の理由があります。
過去に移転前提でデータ抽出だけ行うような管理者がいたのかもしれません。
何らかの事情でWiki管理が難しい場合は 運営に相談してください、と管理権限譲渡の条件に記載されています。
どうしても移転しなければ解決しない問題であるならば その旨を相談すればよいのではないでしょうか。
※現時点で自分が管理するwikiの移転の予定はありません。
たしかにそうですね 全員に使い方を公開してないけど誰でも使える状態なら制限という言葉は誤解を生む表現ですね いずれにしても>> 17さんの意見に賛同です。
一方で、アニメーション利用が可能であることから、乱用によって転送量が増加し
GIF・WebPでもアニメーション可能ですので、的を射ているとは思えません。 現状のサイズ制限はアニメーション画像に対する制限としては割と厳しいので、AVIFを解禁したからと言ってアニメーション画像の乱用が増えるとは思えません。 アニメーションを乱用している人は、上述の通り既にGIFやWebPでやっているでしょう。 AVIFになったからといって新規でアニメーションを乱用する人が続出するというのはどのような考えに基づくものでしょうか？ むしろ、GIF・WebPで画質・フレームレート・サイズを落として現状のサイズ制限ギリギリまでに収めていたアニメーション画像の画質がいくらかマシになり、閲覧体験の上昇が期待できます。 OSでの閲覧環境も整いつつあり、Windows 11では標準の画像ビューワーで閲覧可能です。一昔前は何だこの画像形式ダウンロードしたのに見れねえじゃねえかよという文句がよくありましたが、緩和の流れになっています。 再検討をお願いします。
全面的に賛成します。 最近自分でwikiを建てたことは無かったため、新規に作成したwikiの実際の導線については分かりませんが、この文章の内容を考慮すると改善は必須だと感じます。
一部の編集者にのみ公開するというのも不自然じゃありませんか…？(誰でも利用可能なことに変わりはないのでしょうし。) >> 20の通りとなりますが、そうするくらいなら非推奨であることを明記して全ユーザーへ公開してほしいものです。
賛同します。使えるにも関わらずマニュアルに掲載されていないと混乱を招く原因になります。(一般論としてマニュアルに記載されていないのに使えるというのも意味不明ですし。) 仮に非推奨や今後廃止される予定があるならその旨記載されていればすんなりと受け入れることができます。(むしろ廃止予定ものを明示することで該当Wikiで早めに対処することが可能です。)
また、他のWikiを参考にすればいいというのもいささか乱暴に思えます。マニュアルを整備したうえで活用事例として紹介する分には自然ですが、不完全なマニュアルのまま「他のWikiを参考にしてください」はいかがなものでしょうか。言い方は悪くなってしまいますが、現在の姿勢はユーザーに対する透明性に欠けるものだと感じます。
@wikiwiki 制限付きプラグインについて、該当のWikiの管理者や積極的な編集者などに向けて発信していただくのは難しいでしょうか？ 対処が必要な場合に限り該当のWikiの掲示板などでご発言いただく等の対応になると思います。
というのも個別のWikiの事情にはなりますがインクルードを１３０回ほど使用して構成しているページがあり、負荷をさげるためにできることがあるのか不明な状態です。
https://wikiwiki.jp/sample/左・中・右寄せ
↑改善を……
せめて音を無くしたりバックグラウンドの音楽が流れなくなるだけでも……
運営にあまり期待できないのであれば、 有志で非公式プラグインマニュアルWikiを作るのが現実的だろうと思います。 実際（諦めて？）独自に非掲載プラグインの説明記事を載せているWikiもあります。
プラグインマニュアル、さんぷるWiki掲載分については、 運営にコピペの承諾が貰えれば、割とスムーズに整備できるのではと思います。 （全部独自記載となると大変かもですが…）
多用されると負荷が大きくなるため、あまり使用して欲しくない、一部のブラウザで動作しない、 将来機能しなくなる可能性がある、将来廃止することを検討している、お試しで実装している、 忙しくて記載する時間が取れない（さんぷるWikiの方には掲載されていたり※1、未完成下書きがあったり※2）… …そんなところだろうと思っていましたが、概ねそのようですね。
※1 font、jumplist、shadowheader、showrss2、table_edit、tag、tvote、など ※2 tomorrow_schedule、など
問題は、全て運営側の一方的な都合であることと、 ユーザーには非掲載の理由が不明なことです。 （サービス業でありながら、どちらを向いて仕事しているかという話になってしまいます）
標準プラグインと拡張プラグインに分けて掲載したいならそれでも構いませんが、 マニュアルには、実装されている全てのプラグインを掲載いただき、 非推奨の場合は、非推奨である旨とその理由、自己責任で使用する旨を記載すれば、 よろしいのではないかと思います。
現状ママでは、例えばcontentsxやinclude2、includexは積極使用OKなのか、 それとも使用はできるだけ控えた方が良いのかすら（その理由を含めて）判断できませんが、 例えば「MenuBarでの使用は、負荷が大きくなるため非推奨」など具体的なアドバイスが書かれていれば、 大いに役立つだろうと思われます。
これ、zawazawa以外のサービスのコメント欄でも見かけるようになってきたので、zawazawaの問題じゃなく、firefox自体の問題かもです
アカウントの形式自体は「匿名の権限アカウント」で十分だと考えています(但し管理者権限がある方には、荒らし対策のためどのアカウントからの編集かを閲覧出来る機能が必要な気がします。)が、アカウント制について、Fandomのビューロクラットシステムのような機能が存在することを望みます。
現状wikiwikiではメインパスワードの所持者が最高権限者となり、サブパスワードの所持者が下に付くような形になっていますが、このシステムではメイン管理者に問題が生じた場合にwikiの維持が滞ってしまうリスクがあるほか、wikiはみんなで作成する物ですが、現行のシステムだとメイン管理者一人に全責任が集約されてしまい、みんなで作るというwikiの方針から逸脱しているように感じます。 一方、Fandomのビューロクラットシステムのような機能があれば、最高権限者を複数用意することが出来、誰か一人に問題が生じてもwikiの維持に掛かる影響を最小限に抑えられるため、みんなで作るというwikiの方針とぴったり合うと考えられています。
なお、ビューロクラットシステムを実装する場合、wikiの削除に関するシステムを修正する必要があると思われます。(誰かが勝手にwikiを削除できないよう、正当な理由(サイトの移転等)があるかつ削除にwikiwiki運営の承認が必要にする。また、必要に応じて移転先のサイトへのリダイレクトに置き換える等の対応を行う等。なお、そもそもFandomにはwikiの削除機能が無いため、荒らしに勝手にwikiが消される心配は無い。)
こちらのトピックで言われている機能があれば柔軟に実現できそうです https://z.wikiwiki.jp/wikiwiki-request/topic/421
他の要望でも運営さんからの回答待ちが幾つかある中で早めにご回答いただきまして、どうもありがとうございます。
以上をもちまして、トピックは締め切りとさせていただきます。以前にお伝えしたとおり、さらに議論を要すると認識される方は新たなトピック作成をお願いいたします。
様々なご意見をいただき、ありがとうございました。
ご要望ありがとうございます。
AVIF 形式の画像については、高い圧縮率や画質面でのメリットがあり、 静止画用途としては魅力的な形式であると認識しております。
一方で、アニメーション利用が可能であることから、 乱用によって転送量が増加し、サーバーや利用者の環境に負担をかける可能性が高い点を懸念しております。
現時点では、需要もまだ限定的であることから、今回は対応を見送らせていただきます。 今後の利用状況やブラウザ対応の動向を注視しつつ、ニーズが明確になった段階で改めて検討してまいります。
ご理解のほどよろしくお願いいたします。
ご指摘ありがとうございます。
マニュアルの整備や動線についてご不便をおかけして申し訳ありません。 プラグインにはいくつかのステータスがあり、すべてを公開前提としているわけではありません。
標準公開プラグイン 一般的に利用されることを想定しており、マニュアルにも掲載しています。
制限付きプラグイン 管理用・検証用・負荷軽減・特定のWIKI向けなど。広く公開すると誤用による負荷や不具合につながる可能性があるため、限定的に利用されています。
廃止予定または移行対象のプラグイン 内部的には動作しますが、将来的に終了や置き換えを予定しているものです。新規利用は推奨していないため、マニュアルには記載していません。
このような理由から、あえて全プラグインをマニュアルに掲載していない場合があります。 とくに「使えるけれど記載がない」ものは、安定性や互換性の観点から広く推奨できません。
一方で、マニュアル不足やアクセスのしづらさは課題と認識しています。 主要プラグインの追加や、リンク配置の改善についても課題と認識しており、できるところから順次対応していく予定です。
また、補足的な学び方として他のWIKIのソースを参考にするのも有効です。 実例を見ることで、マニュアルだけでは分かりにくい工夫や応用を理解しやすくなります。
マニュアルは今後も整備を進めますので、実例とあわせてご活用いただければ幸いです。
ご意見ありがとうございます。
仕組みについて
WIKIWIKI の counter、online、popular は、PukiWiki に標準で搭載されている counter 系のプラグイン とは仕組みが異なり、Go 言語で独自に開発したカウンターサーバー で動作しています。 Amazon DynamoDB をストレージに使い、非同期で分散処理する仕組みによって、アクセスが殺到しても counter 数を壊さず、WIKI の基盤システムに負担をかけずに動かせるようになっています。
ただし、このカウンターサーバーは WIKI のページ情報そのものを持っていないため、存在していないページかどうかを判断することはできません。処理をシンプルに保つことで、大規模アクセスにも耐えられるようにしています。
公平性について
「popular の通算をリセットする機能（いわゆる counter リセット）」を導入すると、ユーザーが counter の数字を操作できることになり、各 WIKI の公平性や将来のアクセス数の目安としての信頼性が揺らぐ可能性があります。 また、rename によって counter の数字を 引き継ぐ ことも、人気ページのアクセス数を別のページへ移せてしまうため、望ましくないと考えています。
対応について
現時点で counter の数字をリセットできるようにする予定はありません。
その代わり、popular の仕組み自体を見直していて、非同期処理から半同期処理に切り替えることを検討しています。いまは非同期のリクエスト数がかなり多く、これを減らしたい狙いがあります。
仕組みとしては、WIKI の基盤システムから内部経路でカウンターサーバーの情報を取ってきて、ページの内容と一緒に出力するやり方です。最近では zrecent もこの半同期処理に移行しました。
この方法なら、WIKI の基盤で存在しないページを除外した集計が可能になります。ただし、集計の負荷がページ生成に乗ってくるため、その点は検討中です。
もしこの仕組みを導入する場合は、「負荷パネル」を見ながらユーザーの方に調整してもらう必要も出てくるかもしれません。
popular プラグインの廃止検討について
popular は、負荷の大きい集計系プラグインです。 現在では Google Analytics も利用できるため、必ずしも popular に依存する必要はありません。必要に応じて REST API を使って Google Analytics のデータを取得し、集計結果を定期的に WIKI ページとして生成する方法も可能です。
また、popular を必要以上に多用してランキングを作成するケースもあり、その結果ページ表示が重くなったり、期待通りの結果が得られないことがあります。こうした事情から、popular は 非同期処理として実装されてきました。
以上の背景を踏まえ、popular の提供方法を見直し、場合によっては廃止も視野に入れています。
私はページ名の規制を利用していないので詳しいことは分かりません。 一度設定してみて、期待通りの動作になっているかご確認ください。 該当するページ名で作成しようとした際、SMS認証画面が表示されれば有効です。 [追記]管理者ログイン状態では規制の影響を受けないため、ログアウトした状態で検証してください。
特定のページ名の作成を制限する場合、規制ルールはどのように作成すれば良いでしょうか？
対象項目:ページ名 パターン種別:いずれかを含む パターン:(禁止するキーワード),(禁止するキーワード),...
で良いでしょうか？
コントロールパネル/規制ルールの設定により特定ページの作成・編集を制限することができます。
コントロールパネルで管理できる管理者限定の機能で、NGワードのようにできるなら私も賛成いたします。 具体的には売春斡旋業者にLINE IDや未成年に見せたくないキーワードを含むページ名でページ作成されて困っており、それらのキーワードを含むページの作成を禁止したいと考えています。
日常の合間でトピックを閲覧された方、ならびに投稿してくださった匿名d9d8f@6728cさん、副管理人(WoTBWiki) さん、はやしさん、匿名01062@e41b5 & fc709@e41b5さん、01vさん、ceptさん、お疲れ様でした。(投稿順)
@wikiwiki >> 29副管理人(WoTBWiki) さんのおっしゃる通り、議論し尽くしたと認識しています。運営さんからの回答をもちまして、どのような回答であってもトピック主にしかできない「解決済」タグ付けを行って一旦、締めさせていただく予定でいます。
運営さんからの次の回答以降も議論の余地があると判断される方はお手数ですが、新たなトピックを建ててからお話しください。
参考URL
傍目には、既に十二分に必要性、あるいは不必要性が述べられているかと思います。 これ以上必要性の議論をしても平行線でしょうし、あとは運営チームに判断を委ねる形でよいのではないでしょうか。
よくまとまっていると思いますが、補強する余地がいくつかあるようなので、お話させてください。
したがって、総数と直近では差別化がなされています。
はい、総数と直近は中身が違います。これは間違いなく正しいことです。 しかし中身が違うということから、有益であると主張するのは理論の飛躍があります。なぜなら「唯一無二であるが無用なもの」であることを否定できていないからです。 「直近と違うから総数は有用だ」よりも「総数を見ることでしか得られない、こういうメリットがあるので有用だ」という説明のほうが、説得力があるはずです。
今日100と人気100はあらかじめ用意されており
たしかに、そのはずです。 しかし長く運用されてきたシステムは往々にして、「あまり要らないけど外すのも手間だし、何か起こったら嫌だから触らずにそのままにしておく」機能も多いのです。 「昔からあって今もある」ということは必ずしも、積極的に提供する意思があることや有益であることを証明しません。 論拠の一部として添えることは無駄ではありませんが、弱みがある論拠なので尊重されないかもしれません。
Googleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり
Googleアナリティクスに関する「専門知識」とは、いったい何のことでしょうか。 私が使い始めたときの話をすると、事前の学習や訓練に費やした時間はゼロです。 サーバOSの知識やネットワークプロトコルなどの知識は、要求されません。 もっと具体的にハードルの高さを示さないと、いわゆる「食わず嫌い」と見なされて説得力がないように思われます。
これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わるため、機能追加の是非については 引き続き議論が必要 になると考えています。
という部分は「利用者の個々の事情に基づく議論が活発に継続されたのち、挙げられた要望や案についてwikiwiki運営が公平性・システム負荷・運営方針をベースに総合的に判断する」と解釈しております。したがって壁打ちのような様相になっても、各利用者のそれぞれの立場からの発言は重要だと認識しております。
この解釈と利用者のあるべき議論スタンスについて討論したいわけではないので、popularプラグインに関する意見を述べさせていただきます。 はやしさんが整理された、「popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは」「Googleアナリティクスを使えばよいのでは」という２つの論点について、某スマホゲームのwikiの管理者として意見を表明します。
「今日100があるのだから人気100の重要性は薄く、削除されたページにはアクセスカウンターが増えていかないのだから、カウンターリセット等の機能がなくとも十分で、新機能の開発のリターンが薄い」という旨の主張と理解しています。 私が管理しているwikiの今日100には、最近更新されたページや、ゲーム側で追加された新要素・新キャラクター、直近で開催されるイベントがリストアップされます。 一方、人気100では、登場するキャラクターの一覧ページや、日課・週課の攻略情報が集約されたページ、ゲームシステムの解説ページなど、長期間に渡って一定数の需要があるページが上位に並んでおります。 したがって、総数と直近では差別化がなされています。両方をリストアップするページを置くことに意味があるのであれば、人気100に残りやすい、削除前・リネーム前の人気ページのカウンター数への対処を実現していただきたいのが要望です。 （wikiwikiで新しくwikiを立てるとき、今日100と人気100はあらかじめ用意されており、メニューバーにもリンクが設置されていたものと記憶していますので、wikiwiki運営側もこの２つの差別化については認識されていると考えています）
過去の款冬華さんからの発言が、十分に理論的に利用価値を説明していると思います。
編集の優先順位を決める手がかりになります。編集者はそのページの品質向上に注力できます。ボランティアベースの編集に頼っている大半のWikiは重要な動機付けとなります。閲覧者にとって、PV数が多いページは信頼性や関心度が高いと映る場合があり、さらなるサイトの探索や利用者のエンゲージメント(愛着や深い繋がり)を促進します。
すべてのWiki管理者が高度な分析ツールを導入するための技術的知識を新たに吸収して実践できるとは私自身は到底、思えません。popularプラグインは簡易な指標として価値があります。設定やアクセス解析ツールであるGoogleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり、すべてのWiki管理者が利用できる環境を整えたり、普及活動のために技術的知識を手に入れたいとは限りません。私自身も含みますが、PCを持たずしてモバイル端末だけで管理する者もいます。
（前略）Pukiwiki1.4(2003年リリース)で標準搭載され、利用者のアクセス傾向を簡単に知ることができます。todayとtotalは共に長年、どのWikiでも作成当初からMenuBar最下部にリンク表示されて使われてきたプラグインですので有用性は十分に裏付けされているでしょう。
上記の発言に全面的に同意します。 また、専門知識に疎い管理者・編集者以外にも、利用者にも恩恵がある旨の主張も付け加えさせてください。 長期間にわたって運用されるwikiでは、どうしてもメニューバーが複雑化したり利便性が低下したりする傾向があると考えています（こちらについて事例が必要であれば挙げることもできます）。 その中で、サイト内のカウンター統計が機能している人気100は、新しくサイトを利用したユーザに対してMenuBar・サイト内検索に各ページへ遷移するためのもう一つの選択肢を付け加えることとなり、一定の利用価値がないでしょうか。 ここがリネーム等で十分に機能していない・リンク先が存在しないと表示されるのであれば、やはり修正の意義があると思います。
今の運営さんの話を元にしても議論にならない、という点については確かにそうかもしれません。 しかし最終的な判断を下すのは結局のところ、運営さんなのです。 なんとかしてもう少し運営さんから話を引き出さないと、お互い（運営さん＆機能追加を求める意見）の話がかみ合わない可能性があります。
いいえ違います。 そこの主語は不明確ですが運営であるべきです。そうでないなら運営の認識が誤りであるというのが私の意見です。 ユーザーには利用状況も内部の原理や負荷も見えないので議論になりません。何をもって公平かなど、気持ち次第でなんとでも言えるので、そこをに注力して話をしても発散するだけです。
popularは有用です。 私の例で言えば、popularやcounterのアクセス数からメニューの掲載基準や位置の決定に活用しました。 当時メニューが無法地帯だったので私はそれを整理しようとしました。 そのとき私は管理者ではなく来たばかりの新人でしたが、提案を数値に基づいて示したので話がスムーズだったと思います。
公平性は気にするべきですが、それが本論ではありません。それは色々な意見をみて決定と実行をする運営が考える事です。
運営さんからの応答をもう一度読み直してほしいのですが、公平性に対する懸念は私一人の判断や価値観から出てきたものではなく、運営さんから指摘されていることです。 「様々な意見を見て決定する」という部分にはある程度同意しますが、「それが本論ではありません」の部分は経緯に対する誤解が見られるので同意しません。
話題の対象が利用者全体なので、「私が必要としている理由はこれです」のような話をしても意味がない、ということです。（逆に「私には全然必要ありません」も無意味です）
いいえ。自分が必要している話をすべきです。 私は必要ありませんの意見も意味があります。 公平性は気にするべきですが、それが本論ではありません。それは色々な意見をみて決定と実行をする運営が考える事です。
私は現在困ってませんが、提示されたpopularの結果をみれば機能として使えないし、その回避策は煩雑で無駄な負荷をかけてることがわかります。この状況は多量のリネームや削除で自分にも容易に起こるとに気が付いたので、意見を述べています。一方でpopularなんて重要では無い立場の人も居るでしょうから、それはそう言えばいいです。例えば使ってないからコストや負荷かける価値を感じないという意見も良いと思います。 二つの意見は論点が交わらないので、言いっぱなしでいいです。無理に議論や説得をしなくていいです。
各ページにcounterファイルの編集リンクを設置する(管理者用)
これは&counter_editみたいなプラグインを作って、必要に応じ各ページやメニューに仕込めばよいと考えました。現在の標準レイアウトに手を入れずに、必要な時だけ表に出し、不要になったら外せばいいです。
アクアちゃん
今のお話の中にあったリンク の先のページの一番下に、重要な情報が見られます。
負荷の高いカウンター関連プラグインの非同期処理を行いました。カウンター向けの専用サーバーに集約しております。 WIKIとカウンターを切り離して動いておりますので、削除されたページのカウントも人気のページ表示されます。 また、renameプラグインでページ名を変更してもカウンターは引き継がれません。 どうしても修正したい方 数ページ程度であれば手動で反映いたしますのでお問い合わせください。
負荷の高いカウンター関連プラグインの非同期処理を行いました。カウンター向けの専用サーバーに集約しております。 WIKIとカウンターを切り離して動いておりますので、削除されたページのカウントも人気のページ表示されます。 また、renameプラグインでページ名を変更してもカウンターは引き継がれません。
どうしても修正したい方 数ページ程度であれば手動で反映いたしますのでお問い合わせください。
つまり、今の動作（削除済みのページも表示される、名前変更後に値が継承されない）は不具合でも想定外でもなく、すべて承知の上での仕様だということです。 また、「数ページ程度であれば手動で反映いたします」ともあります。推測になりますが、利用されることがほとんどないと見込まれるので、削除機能を提供するよりも手動で応じたほうが楽、という判断である可能性があります。
不具合でも想定外でもない意図どおりの仕様に変更を迫ることは、もちろん容易ではありません。周到な準備が必要です。 注目すべきは、運営さんからの返信にある「これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わる」という部分です。 これらをクリアした上での提案でないと、変更には応じてもらえないわけです。ひとつひとつ、考えてみましょう。
話題の対象が利用者全体なので、「私が必要としている理由はこれです」のような話をしても意味がない、ということです。（逆に「私には全然必要ありません」も無意味です） 新しい機能が自分にとって無縁の機能であっても、他人にとって利用価値がある機能なら、使わない人にとっても納得できます。 逆に、ごく一部の人しか喜ばない機能を作るようでは、不公平感が高まります。 つまり、使う人が多いということを示す必要があります。
これは容易ではありません。簡単に思いつく手段はアンケートですが、統計的に意味のある量のデータを集めることはほとんど不可能に思えます。 となれば、「ほとんど誰も使わないのでは？」という懸念となるような事案をひとつひとつ丁寧に、単なる決めつけではなく確かな理論的背景をもつ説明をしていくしかないように思います。 ここまでの話の中で上がっている懸念を簡単にまとめると、以下のとおりです。
負荷の量やメカニズムについては、私などより01vさんのほうがよほど詳しいようです。 すこし目線を変えると、「負荷をどう減らすか」も重要ですが別のアプローチとして「要望する機能の価値を明らかにする」という手段も視野に入ります。 負荷が同じでも価値が高いなら、「しない」から「する」に傾かせることができます。 やみくもに「使う・要る・欲しい」と言うのではなく、具体的にどう役立つかを示せれば、提案に有利に働くでしょう。
これはちょっと、私には意味がよく分かりません。 ただ、今回の要望が運営方針に対する悪影響の懸念がある、というのは確かに思えます。 この辺を明らかにし、その対策を含んだ提案をする必要があります。
counterの仕様はそのようになっているんですね、勉強になります。 (アクアちゃんとは？と思いましたが...)
その上で、counterファイルを手動で弄れるようにする(管理者によるカウンターのリセットや編集を許可する)というのは反対です。 >> 14さんが仰っている通り管理者の無用な手間を増やすことになるうえ、結局の所管理者が荒らしてしまえば元も子もなく、任意リセットはcounterの価値を無くすものと思います。 そうした点では、ページ削除の操作によってcounterファイルに任意の識別子を付与し、popular側ではその識別子を元にフィルターすることを提案します。 リネームに関してはどのような手法を取っても復元不可能となるリスクがありますが、「ページ名の変更」操作を行った場合のみ自動でcounterを書き換えるような処理を追加すればよいのではないでしょうか。
現在私のところで削除済みのページが上位に表示されたり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としては以下のようなものが望まれます。
リネームしたときにカウンターを引き継げるようにする これは本来あるべき動作だと思います。 >> 14に同意です。 変更はplugin_rename_get_files()で簡単にできると、アクアちゃんが提案しています。
バックアップを取れるようにする 色々いじれるようになって事故の恐れを考慮するなら
色々書いてみましたがこれを活用できる場面は限定的と思われ、以下あたりなら程よく実現できるのではないかと思います。
失礼いたしました。利用規約に違反しない程度に誤ったWiki運営の仕方をしていると決めつけた物言いやトピックに関係ない発言に対する揚げ足取りに気を取られて不必要な発言をしてしまいました。この投稿以降、私からの発言は控えます。
あまり公式コミュニティで話すことではないですが、どんなwikiプラットフォーマーでも収益減とサーバーリソースのアンバランス化に直結するwiki移転をおいそれと認めるわけにはいかないでしょう。
トラブルが頻発しているとか、収益が上がらない割にリソース喰らいになっているといった、むしろ出ていってくれた方が厄介払いになるケースを除いて移転の提案が上がること自体がwiki運営にとって有害です。
信用の安定をとるか収益の安定を取るかの違いだと思います。いい顔ばかりして運営自身と他wikiの首を締めるのも困ります。
そのルールが定められた経緯は分かりませんが
記載されている以上、相応の理由があります。
過去に移転前提でデータ抽出だけ行うような管理者がいたのかもしれません。
何らかの事情でWiki管理が難しい場合は
運営に相談してください、と管理権限譲渡の条件に記載されています。
どうしても移転しなければ解決しない問題であるならば
その旨を相談すればよいのではないでしょうか。
※現時点で自分が管理するwikiの移転の予定はありません。
たしかにそうですね
全員に使い方を公開してないけど誰でも使える状態なら制限という言葉は誤解を生む表現ですね
いずれにしても>> 17さんの意見に賛同です。
GIF・WebPでもアニメーション可能ですので、的を射ているとは思えません。
現状のサイズ制限はアニメーション画像に対する制限としては割と厳しいので、AVIFを解禁したからと言ってアニメーション画像の乱用が増えるとは思えません。
アニメーションを乱用している人は、上述の通り既にGIFやWebPでやっているでしょう。
AVIFになったからといって新規でアニメーションを乱用する人が続出するというのはどのような考えに基づくものでしょうか？
むしろ、GIF・WebPで画質・フレームレート・サイズを落として現状のサイズ制限ギリギリまでに収めていたアニメーション画像の画質がいくらかマシになり、閲覧体験の上昇が期待できます。
OSでの閲覧環境も整いつつあり、Windows 11では標準の画像ビューワーで閲覧可能です。一昔前は何だこの画像形式ダウンロードしたのに見れねえじゃねえかよという文句がよくありましたが、緩和の流れになっています。
再検討をお願いします。
全面的に賛成します。
最近自分でwikiを建てたことは無かったため、新規に作成したwikiの実際の導線については分かりませんが、この文章の内容を考慮すると改善は必須だと感じます。
一部の編集者にのみ公開するというのも不自然じゃありませんか…？(誰でも利用可能なことに変わりはないのでしょうし。)
>> 20の通りとなりますが、そうするくらいなら非推奨であることを明記して全ユーザーへ公開してほしいものです。
賛同します。使えるにも関わらずマニュアルに掲載されていないと混乱を招く原因になります。(一般論としてマニュアルに記載されていないのに使えるというのも意味不明ですし。)
仮に非推奨や今後廃止される予定があるならその旨記載されていればすんなりと受け入れることができます。(むしろ廃止予定ものを明示することで該当Wikiで早めに対処することが可能です。)
また、他のWikiを参考にすればいいというのもいささか乱暴に思えます。マニュアルを整備したうえで活用事例として紹介する分には自然ですが、不完全なマニュアルのまま「他のWikiを参考にしてください」はいかがなものでしょうか。言い方は悪くなってしまいますが、現在の姿勢はユーザーに対する透明性に欠けるものだと感じます。
@wikiwiki
制限付きプラグインについて、該当のWikiの管理者や積極的な編集者などに向けて発信していただくのは難しいでしょうか？
対処が必要な場合に限り該当のWikiの掲示板などでご発言いただく等の対応になると思います。
というのも個別のWikiの事情にはなりますがインクルードを１３０回ほど使用して構成しているページがあり、負荷をさげるためにできることがあるのか不明な状態です。
https://wikiwiki.jp/sample/左・中・右寄せ
↑改善を……
せめて音を無くしたりバックグラウンドの音楽が流れなくなるだけでも……
運営にあまり期待できないのであれば、
有志で非公式プラグインマニュアルWikiを作るのが現実的だろうと思います。
実際（諦めて？）独自に非掲載プラグインの説明記事を載せているWikiもあります。
プラグインマニュアル、さんぷるWiki掲載分については、
運営にコピペの承諾が貰えれば、割とスムーズに整備できるのではと思います。
（全部独自記載となると大変かもですが…）
多用されると負荷が大きくなるため、あまり使用して欲しくない、一部のブラウザで動作しない、
将来機能しなくなる可能性がある、将来廃止することを検討している、お試しで実装している、
忙しくて記載する時間が取れない（さんぷるWikiの方には掲載されていたり※1、未完成下書きがあったり※2）…
…そんなところだろうと思っていましたが、概ねそのようですね。
※1 font、jumplist、shadowheader、showrss2、table_edit、tag、tvote、など
※2 tomorrow_schedule、など
問題は、全て運営側の一方的な都合であることと、
ユーザーには非掲載の理由が不明なことです。
（サービス業でありながら、どちらを向いて仕事しているかという話になってしまいます）
標準プラグインと拡張プラグインに分けて掲載したいならそれでも構いませんが、
マニュアルには、実装されている全てのプラグインを掲載いただき、
非推奨の場合は、非推奨である旨とその理由、自己責任で使用する旨を記載すれば、
よろしいのではないかと思います。
現状ママでは、例えばcontentsxやinclude2、includexは積極使用OKなのか、
それとも使用はできるだけ控えた方が良いのかすら（その理由を含めて）判断できませんが、
例えば「MenuBarでの使用は、負荷が大きくなるため非推奨」など具体的なアドバイスが書かれていれば、
大いに役立つだろうと思われます。
これ、zawazawa以外のサービスのコメント欄でも見かけるようになってきたので、zawazawaの問題じゃなく、firefox自体の問題かもです
アカウントの形式自体は「匿名の権限アカウント」で十分だと考えています(但し管理者権限がある方には、荒らし対策のためどのアカウントからの編集かを閲覧出来る機能が必要な気がします。)が、アカウント制について、Fandomのビューロクラットシステムのような機能が存在することを望みます。
現状wikiwikiではメインパスワードの所持者が最高権限者となり、サブパスワードの所持者が下に付くような形になっていますが、このシステムではメイン管理者に問題が生じた場合にwikiの維持が滞ってしまうリスクがあるほか、wikiはみんなで作成する物ですが、現行のシステムだとメイン管理者一人に全責任が集約されてしまい、みんなで作るというwikiの方針から逸脱しているように感じます。
一方、Fandomのビューロクラットシステムのような機能があれば、最高権限者を複数用意することが出来、誰か一人に問題が生じてもwikiの維持に掛かる影響を最小限に抑えられるため、みんなで作るというwikiの方針とぴったり合うと考えられています。
なお、ビューロクラットシステムを実装する場合、wikiの削除に関するシステムを修正する必要があると思われます。(誰かが勝手にwikiを削除できないよう、正当な理由(サイトの移転等)があるかつ削除にwikiwiki運営の承認が必要にする。また、必要に応じて移転先のサイトへのリダイレクトに置き換える等の対応を行う等。なお、そもそもFandomにはwikiの削除機能が無いため、荒らしに勝手にwikiが消される心配は無い。)
こちらのトピックで言われている機能があれば柔軟に実現できそうです
https://z.wikiwiki.jp/wikiwiki-request/topic/421
他の要望でも運営さんからの回答待ちが幾つかある中で早めにご回答いただきまして、どうもありがとうございます。
以上をもちまして、トピックは締め切りとさせていただきます。以前にお伝えしたとおり、さらに議論を要すると認識される方は新たなトピック作成をお願いいたします。
様々なご意見をいただき、ありがとうございました。
ご要望ありがとうございます。
AVIF 形式の画像については、高い圧縮率や画質面でのメリットがあり、
静止画用途としては魅力的な形式であると認識しております。
一方で、アニメーション利用が可能であることから、
乱用によって転送量が増加し、サーバーや利用者の環境に負担をかける可能性が高い点を懸念しております。
現時点では、需要もまだ限定的であることから、今回は対応を見送らせていただきます。
今後の利用状況やブラウザ対応の動向を注視しつつ、ニーズが明確になった段階で改めて検討してまいります。
ご理解のほどよろしくお願いいたします。
ご指摘ありがとうございます。
マニュアルの整備や動線についてご不便をおかけして申し訳ありません。
プラグインにはいくつかのステータスがあり、すべてを公開前提としているわけではありません。
標準公開プラグイン
一般的に利用されることを想定しており、マニュアルにも掲載しています。
制限付きプラグイン
管理用・検証用・負荷軽減・特定のWIKI向けなど。広く公開すると誤用による負荷や不具合につながる可能性があるため、限定的に利用されています。
廃止予定または移行対象のプラグイン
内部的には動作しますが、将来的に終了や置き換えを予定しているものです。新規利用は推奨していないため、マニュアルには記載していません。
このような理由から、あえて全プラグインをマニュアルに掲載していない場合があります。
とくに「使えるけれど記載がない」ものは、安定性や互換性の観点から広く推奨できません。
一方で、マニュアル不足やアクセスのしづらさは課題と認識しています。
主要プラグインの追加や、リンク配置の改善についても課題と認識しており、できるところから順次対応していく予定です。
また、補足的な学び方として他のWIKIのソースを参考にするのも有効です。
実例を見ることで、マニュアルだけでは分かりにくい工夫や応用を理解しやすくなります。
マニュアルは今後も整備を進めますので、実例とあわせてご活用いただければ幸いです。
ご意見ありがとうございます。
仕組みについて
WIKIWIKI の counter、online、popular は、PukiWiki に標準で搭載されている counter 系のプラグイン とは仕組みが異なり、Go 言語で独自に開発したカウンターサーバー で動作しています。
Amazon DynamoDB をストレージに使い、非同期で分散処理する仕組みによって、アクセスが殺到しても counter 数を壊さず、WIKI の基盤システムに負担をかけずに動かせるようになっています。
ただし、このカウンターサーバーは WIKI のページ情報そのものを持っていないため、存在していないページかどうかを判断することはできません。処理をシンプルに保つことで、大規模アクセスにも耐えられるようにしています。
公平性について
「popular の通算をリセットする機能（いわゆる counter リセット）」を導入すると、ユーザーが counter の数字を操作できることになり、各 WIKI の公平性や将来のアクセス数の目安としての信頼性が揺らぐ可能性があります。
また、rename によって counter の数字を 引き継ぐ ことも、人気ページのアクセス数を別のページへ移せてしまうため、望ましくないと考えています。
対応について
現時点で counter の数字をリセットできるようにする予定はありません。
その代わり、popular の仕組み自体を見直していて、非同期処理から半同期処理に切り替えることを検討しています。いまは非同期のリクエスト数がかなり多く、これを減らしたい狙いがあります。
仕組みとしては、WIKI の基盤システムから内部経路でカウンターサーバーの情報を取ってきて、ページの内容と一緒に出力するやり方です。最近では zrecent もこの半同期処理に移行しました。
この方法なら、WIKI の基盤で存在しないページを除外した集計が可能になります。ただし、集計の負荷がページ生成に乗ってくるため、その点は検討中です。
もしこの仕組みを導入する場合は、「負荷パネル」を見ながらユーザーの方に調整してもらう必要も出てくるかもしれません。
popular プラグインの廃止検討について
popular は、負荷の大きい集計系プラグインです。
現在では Google Analytics も利用できるため、必ずしも popular に依存する必要はありません。必要に応じて REST API を使って Google Analytics のデータを取得し、集計結果を定期的に WIKI ページとして生成する方法も可能です。
また、popular を必要以上に多用してランキングを作成するケースもあり、その結果ページ表示が重くなったり、期待通りの結果が得られないことがあります。こうした事情から、popular は 非同期処理として実装されてきました。
以上の背景を踏まえ、popular の提供方法を見直し、場合によっては廃止も視野に入れています。
私はページ名の規制を利用していないので詳しいことは分かりません。
一度設定してみて、期待通りの動作になっているかご確認ください。
該当するページ名で作成しようとした際、SMS認証画面が表示されれば有効です。
[追記]管理者ログイン状態では規制の影響を受けないため、ログアウトした状態で検証してください。
特定のページ名の作成を制限する場合、規制ルールはどのように作成すれば良いでしょうか？
で良いでしょうか？
コントロールパネル/規制ルールの設定により特定ページの作成・編集を制限することができます。
コントロールパネルで管理できる管理者限定の機能で、NGワードのようにできるなら私も賛成いたします。
具体的には売春斡旋業者にLINE IDや未成年に見せたくないキーワードを含むページ名でページ作成されて困っており、それらのキーワードを含むページの作成を禁止したいと考えています。
日常の合間でトピックを閲覧された方、ならびに投稿してくださった匿名d9d8f@6728cさん、副管理人(WoTBWiki) さん、はやしさん、匿名01062@e41b5 & fc709@e41b5さん、01vさん、ceptさん、お疲れ様でした。(投稿順)
@wikiwiki
>> 29副管理人(WoTBWiki) さんのおっしゃる通り、議論し尽くしたと認識しています。運営さんからの回答をもちまして、どのような回答であってもトピック主にしかできない「解決済」タグ付けを行って一旦、締めさせていただく予定でいます。
運営さんからの次の回答以降も議論の余地があると判断される方はお手数ですが、新たなトピックを建ててからお話しください。
参考URL
傍目には、既に十二分に必要性、あるいは不必要性が述べられているかと思います。
これ以上必要性の議論をしても平行線でしょうし、あとは運営チームに判断を委ねる形でよいのではないでしょうか。
よくまとまっていると思いますが、補強する余地がいくつかあるようなので、お話させてください。
はい、総数と直近は中身が違います。これは間違いなく正しいことです。
しかし中身が違うということから、有益であると主張するのは理論の飛躍があります。なぜなら「唯一無二であるが無用なもの」であることを否定できていないからです。
「直近と違うから総数は有用だ」よりも「総数を見ることでしか得られない、こういうメリットがあるので有用だ」という説明のほうが、説得力があるはずです。
たしかに、そのはずです。
しかし長く運用されてきたシステムは往々にして、「あまり要らないけど外すのも手間だし、何か起こったら嫌だから触らずにそのままにしておく」機能も多いのです。
「昔からあって今もある」ということは必ずしも、積極的に提供する意思があることや有益であることを証明しません。
論拠の一部として添えることは無駄ではありませんが、弱みがある論拠なので尊重されないかもしれません。
Googleアナリティクスに関する「専門知識」とは、いったい何のことでしょうか。
私が使い始めたときの話をすると、事前の学習や訓練に費やした時間はゼロです。
サーバOSの知識やネットワークプロトコルなどの知識は、要求されません。
もっと具体的にハードルの高さを示さないと、いわゆる「食わず嫌い」と見なされて説得力がないように思われます。
という部分は「利用者の個々の事情に基づく議論が活発に継続されたのち、挙げられた要望や案についてwikiwiki運営が公平性・システム負荷・運営方針をベースに総合的に判断する」と解釈しております。したがって壁打ちのような様相になっても、各利用者のそれぞれの立場からの発言は重要だと認識しております。
この解釈と利用者のあるべき議論スタンスについて討論したいわけではないので、popularプラグインに関する意見を述べさせていただきます。
はやしさんが整理された、「popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは」「Googleアナリティクスを使えばよいのでは」という２つの論点について、某スマホゲームのwikiの管理者として意見を表明します。
「popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは」
「今日100があるのだから人気100の重要性は薄く、削除されたページにはアクセスカウンターが増えていかないのだから、カウンターリセット等の機能がなくとも十分で、新機能の開発のリターンが薄い」という旨の主張と理解しています。
私が管理しているwikiの今日100には、最近更新されたページや、ゲーム側で追加された新要素・新キャラクター、直近で開催されるイベントがリストアップされます。
一方、人気100では、登場するキャラクターの一覧ページや、日課・週課の攻略情報が集約されたページ、ゲームシステムの解説ページなど、長期間に渡って一定数の需要があるページが上位に並んでおります。
したがって、総数と直近では差別化がなされています。両方をリストアップするページを置くことに意味があるのであれば、人気100に残りやすい、削除前・リネーム前の人気ページのカウンター数への対処を実現していただきたいのが要望です。
（wikiwikiで新しくwikiを立てるとき、今日100と人気100はあらかじめ用意されており、メニューバーにもリンクが設置されていたものと記憶していますので、wikiwiki運営側もこの２つの差別化については認識されていると考えています）
Googleアナリティクスを使えばよいのでは
過去の款冬華さんからの発言が、十分に理論的に利用価値を説明していると思います。
上記の発言に全面的に同意します。
また、専門知識に疎い管理者・編集者以外にも、利用者にも恩恵がある旨の主張も付け加えさせてください。
長期間にわたって運用されるwikiでは、どうしてもメニューバーが複雑化したり利便性が低下したりする傾向があると考えています（こちらについて事例が必要であれば挙げることもできます）。
その中で、サイト内のカウンター統計が機能している人気100は、新しくサイトを利用したユーザに対してMenuBar・サイト内検索に各ページへ遷移するためのもう一つの選択肢を付け加えることとなり、一定の利用価値がないでしょうか。
ここがリネーム等で十分に機能していない・リンク先が存在しないと表示されるのであれば、やはり修正の意義があると思います。
今の運営さんの話を元にしても議論にならない、という点については確かにそうかもしれません。
しかし最終的な判断を下すのは結局のところ、運営さんなのです。
なんとかしてもう少し運営さんから話を引き出さないと、お互い（運営さん＆機能追加を求める意見）の話がかみ合わない可能性があります。
いいえ違います。
そこの主語は不明確ですが運営であるべきです。そうでないなら運営の認識が誤りであるというのが私の意見です。
ユーザーには利用状況も内部の原理や負荷も見えないので議論になりません。何をもって公平かなど、気持ち次第でなんとでも言えるので、そこをに注力して話をしても発散するだけです。
popularは有用です。
私の例で言えば、popularやcounterのアクセス数からメニューの掲載基準や位置の決定に活用しました。
当時メニューが無法地帯だったので私はそれを整理しようとしました。
そのとき私は管理者ではなく来たばかりの新人でしたが、提案を数値に基づいて示したので話がスムーズだったと思います。
運営さんからの応答をもう一度読み直してほしいのですが、公平性に対する懸念は私一人の判断や価値観から出てきたものではなく、運営さんから指摘されていることです。
「様々な意見を見て決定する」という部分にはある程度同意しますが、「それが本論ではありません」の部分は経緯に対する誤解が見られるので同意しません。
いいえ。自分が必要している話をすべきです。
私は必要ありませんの意見も意味があります。
公平性は気にするべきですが、それが本論ではありません。それは色々な意見をみて決定と実行をする運営が考える事です。
私は現在困ってませんが、提示されたpopularの結果をみれば機能として使えないし、その回避策は煩雑で無駄な負荷をかけてることがわかります。この状況は多量のリネームや削除で自分にも容易に起こるとに気が付いたので、意見を述べています。一方でpopularなんて重要では無い立場の人も居るでしょうから、それはそう言えばいいです。例えば使ってないからコストや負荷かける価値を感じないという意見も良いと思います。
二つの意見は論点が交わらないので、言いっぱなしでいいです。無理に議論や説得をしなくていいです。
これは&counter_editみたいなプラグインを作って、必要に応じ各ページやメニューに仕込めばよいと考えました。現在の標準レイアウトに手を入れずに、必要な時だけ表に出し、不要になったら外せばいいです。
アクアちゃん
今のお話の中にあったリンク の先のページの一番下に、重要な情報が見られます。
つまり、今の動作（削除済みのページも表示される、名前変更後に値が継承されない）は不具合でも想定外でもなく、すべて承知の上での仕様だということです。
また、「数ページ程度であれば手動で反映いたします」ともあります。推測になりますが、利用されることがほとんどないと見込まれるので、削除機能を提供するよりも手動で応じたほうが楽、という判断である可能性があります。
不具合でも想定外でもない意図どおりの仕様に変更を迫ることは、もちろん容易ではありません。周到な準備が必要です。
注目すべきは、運営さんからの返信にある「これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わる」という部分です。
これらをクリアした上での提案でないと、変更には応じてもらえないわけです。ひとつひとつ、考えてみましょう。
利用者全体の公平性
話題の対象が利用者全体なので、「私が必要としている理由はこれです」のような話をしても意味がない、ということです。（逆に「私には全然必要ありません」も無意味です）
新しい機能が自分にとって無縁の機能であっても、他人にとって利用価値がある機能なら、使わない人にとっても納得できます。
逆に、ごく一部の人しか喜ばない機能を作るようでは、不公平感が高まります。
つまり、使う人が多いということを示す必要があります。
これは容易ではありません。簡単に思いつく手段はアンケートですが、統計的に意味のある量のデータを集めることはほとんど不可能に思えます。
となれば、「ほとんど誰も使わないのでは？」という懸念となるような事案をひとつひとつ丁寧に、単なる決めつけではなく確かな理論的背景をもつ説明をしていくしかないように思います。
ここまでの話の中で上がっている懸念を簡単にまとめると、以下のとおりです。
システム負荷
負荷の量やメカニズムについては、私などより01vさんのほうがよほど詳しいようです。
すこし目線を変えると、「負荷をどう減らすか」も重要ですが別のアプローチとして「要望する機能の価値を明らかにする」という手段も視野に入ります。
負荷が同じでも価値が高いなら、「しない」から「する」に傾かせることができます。
やみくもに「使う・要る・欲しい」と言うのではなく、具体的にどう役立つかを示せれば、提案に有利に働くでしょう。
運営方針
これはちょっと、私には意味がよく分かりません。
ただ、今回の要望が運営方針に対する悪影響の懸念がある、というのは確かに思えます。
この辺を明らかにし、その対策を含んだ提案をする必要があります。
counterの仕様はそのようになっているんですね、勉強になります。
(アクアちゃんとは？と思いましたが...)
その上で、counterファイルを手動で弄れるようにする(管理者によるカウンターのリセットや編集を許可する)というのは反対です。
>> 14さんが仰っている通り管理者の無用な手間を増やすことになるうえ、結局の所管理者が荒らしてしまえば元も子もなく、任意リセットはcounterの価値を無くすものと思います。
そうした点では、ページ削除の操作によってcounterファイルに任意の識別子を付与し、popular側ではその識別子を元にフィルターすることを提案します。
リネームに関してはどのような手法を取っても復元不可能となるリスクがありますが、「ページ名の変更」操作を行った場合のみ自動でcounterを書き換えるような処理を追加すればよいのではないでしょうか。
現在私のところで削除済みのページが上位に表示されたり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としては以下のようなものが望まれます。
実体はスペース区切りの単純なテキストファイルと思われる。
数値を変更したり、全消しでファイル自体を削除できるようにする。
リネームしたときにカウンターを引き継げるようにする
これは本来あるべき動作だと思います。
>> 14に同意です。
変更はplugin_rename_get_files()で簡単にできると、アクアちゃんが提案しています。
バックアップを取れるようにする
色々いじれるようになって事故の恐れを考慮するなら
色々書いてみましたがこれを活用できる場面は限定的と思われ、以下あたりなら程よく実現できるのではないかと思います。
失礼いたしました。利用規約に違反しない程度に誤ったWiki運営の仕方をしていると決めつけた物言いやトピックに関係ない発言に対する揚げ足取りに気を取られて不必要な発言をしてしまいました。この投稿以降、私からの発言は控えます。