リクエスト広場

リクエスト広場

1522 コメント
views
9 フォロー
1,449 件中 121 から 160 までを表示しています。
5
名前なし 2025/09/19 (金) 23:19:59 修正 080d6@626b9 >> 3

私はページ名の規制を利用していないので詳しいことは分かりません。
一度設定してみて、期待通りの動作になっているかご確認ください。
該当するページ名で作成しようとした際、SMS認証画面が表示されれば有効です。
[追記]管理者ログイン状態では規制の影響を受けないため、ログアウトした状態で検証してください。

3
名前なし 2025/09/19 (金) 14:26:20 d7b7b@541bc >> 2

特定のページ名の作成を制限する場合、規制ルールはどのように作成すれば良いでしょうか？

対象項目:ページ名
パターン種別:いずれかを含む
パターン:(禁止するキーワード),(禁止するキーワード),...

で良いでしょうか？

2
名前なし 2025/09/19 (金) 10:02:51 080d6@626b9

コントロールパネル/規制ルールの設定により特定ページの作成・編集を制限することができます。

1
名前なし 2025/09/19 (金) 04:30:04 7424d@9ef95

コントロールパネルで管理できる管理者限定の機能で、NGワードのようにできるなら私も賛成いたします。
具体的には売春斡旋業者にLINE IDや未成年に見せたくないキーワードを含むページ名でページ作成されて困っており、それらのキーワードを含むページの作成を禁止したいと考えています。
30
款冬華 2025/09/16 (火) 17:56:50

日常の合間でトピックを閲覧された方、ならびに投稿してくださった匿名d9d8f@6728cさん、副管理人(WoTBWiki) さん、はやしさん、匿名01062@e41b5 & fc709@e41b5さん、01vさん、ceptさん、お疲れ様でした。(投稿順)

@wikiwiki
>> 29副管理人(WoTBWiki) さんのおっしゃる通り、議論し尽くしたと認識しています。運営さんからの回答をもちまして、どのような回答であってもトピック主にしかできない「解決済」タグ付けを行って一旦、締めさせていただく予定でいます。

運営さんからの次の回答以降も議論の余地があると判断される方はお手数ですが、新たなトピックを建ててからお話しください。

参考URL
29
副管理人(WoTBWiki) 2025/09/14 (日) 21:44:27

傍目には、既に十二分に必要性、あるいは不必要性が述べられているかと思います。
これ以上必要性の議論をしても平行線でしょうし、あとは運営チームに判断を委ねる形でよいのではないでしょうか。

28
はやし 2025/09/14 (日) 13:44:07 70b72@f53e0 >> 27

よくまとまっていると思いますが、補強する余地がいくつかあるようなので、お話させてください。

したがって、総数と直近では差別化がなされています。

はい、総数と直近は中身が違います。これは間違いなく正しいことです。
しかし中身が違うということから、有益であると主張するのは理論の飛躍があります。なぜなら「唯一無二であるが無用なもの」であることを否定できていないからです。
「直近と違うから総数は有用だ」よりも「総数を見ることでしか得られない、こういうメリットがあるので有用だ」という説明のほうが、説得力があるはずです。

今日100と人気100はあらかじめ用意されており

たしかに、そのはずです。
しかし長く運用されてきたシステムは往々にして、「あまり要らないけど外すのも手間だし、何か起こったら嫌だから触らずにそのままにしておく」機能も多いのです。
「昔からあって今もある」ということは必ずしも、積極的に提供する意思があることや有益であることを証明しません。
論拠の一部として添えることは無駄ではありませんが、弱みがある論拠なので尊重されないかもしれません。

Googleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり

Googleアナリティクスに関する「専門知識」とは、いったい何のことでしょうか。
私が使い始めたときの話をすると、事前の学習や訓練に費やした時間はゼロです。
サーバOSの知識やネットワークプロトコルなどの知識は、要求されません。
もっと具体的にハードルの高さを示さないと、いわゆる「食わず嫌い」と見なされて説得力がないように思われます。
27
cept 2025/09/14 (日) 12:16:42

これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わるため、機能追加の是非については 引き続き議論が必要 になると考えています。

という部分は「利用者の個々の事情に基づく議論が活発に継続されたのち、挙げられた要望や案についてwikiwiki運営が公平性・システム負荷・運営方針をベースに総合的に判断する」と解釈しております。したがって壁打ちのような様相になっても、各利用者のそれぞれの立場からの発言は重要だと認識しております。

この解釈と利用者のあるべき議論スタンスについて討論したいわけではないので、popularプラグインに関する意見を述べさせていただきます。
はやしさんが整理された、「popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは」「Googleアナリティクスを使えばよいのでは」という２つの論点について、某スマホゲームのwikiの管理者として意見を表明します。

「popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは」

「今日100があるのだから人気100の重要性は薄く、削除されたページにはアクセスカウンターが増えていかないのだから、カウンターリセット等の機能がなくとも十分で、新機能の開発のリターンが薄い」という旨の主張と理解しています。
私が管理しているwikiの今日100には、最近更新されたページや、ゲーム側で追加された新要素・新キャラクター、直近で開催されるイベントがリストアップされます。
一方、人気100では、登場するキャラクターの一覧ページや、日課・週課の攻略情報が集約されたページ、ゲームシステムの解説ページなど、長期間に渡って一定数の需要があるページが上位に並んでおります。
したがって、総数と直近では差別化がなされています。両方をリストアップするページを置くことに意味があるのであれば、人気100に残りやすい、削除前・リネーム前の人気ページのカウンター数への対処を実現していただきたいのが要望です。
（wikiwikiで新しくwikiを立てるとき、今日100と人気100はあらかじめ用意されており、メニューバーにもリンクが設置されていたものと記憶していますので、wikiwiki運営側もこの２つの差別化については認識されていると考えています）

Googleアナリティクスを使えばよいのでは

過去の款冬華さんからの発言が、十分に理論的に利用価値を説明していると思います。

編集の優先順位を決める手がかりになります。編集者はそのページの品質向上に注力できます。ボランティアベースの編集に頼っている大半のWikiは重要な動機付けとなります。閲覧者にとって、PV数が多いページは信頼性や関心度が高いと映る場合があり、さらなるサイトの探索や利用者のエンゲージメント(愛着や深い繋がり)を促進します。

すべてのWiki管理者が高度な分析ツールを導入するための技術的知識を新たに吸収して実践できるとは私自身は到底、思えません。popularプラグインは簡易な指標として価値があります。設定やアクセス解析ツールであるGoogleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり、すべてのWiki管理者が利用できる環境を整えたり、普及活動のために技術的知識を手に入れたいとは限りません。私自身も含みますが、PCを持たずしてモバイル端末だけで管理する者もいます。

（前略）Pukiwiki1.4(2003年リリース)で標準搭載され、利用者のアクセス傾向を簡単に知ることができます。todayとtotalは共に長年、どのWikiでも作成当初からMenuBar最下部にリンク表示されて使われてきたプラグインですので有用性は十分に裏付けされているでしょう。

上記の発言に全面的に同意します。
また、専門知識に疎い管理者・編集者以外にも、利用者にも恩恵がある旨の主張も付け加えさせてください。
長期間にわたって運用されるwikiでは、どうしてもメニューバーが複雑化したり利便性が低下したりする傾向があると考えています（こちらについて事例が必要であれば挙げることもできます）。
その中で、サイト内のカウンター統計が機能している人気100は、新しくサイトを利用したユーザに対してMenuBar・サイト内検索に各ページへ遷移するためのもう一つの選択肢を付け加えることとなり、一定の利用価値がないでしょうか。
ここがリネーム等で十分に機能していない・リンク先が存在しないと表示されるのであれば、やはり修正の意義があると思います。

26
はやし 2025/09/14 (日) 11:19:08 70b72@f53e0 >> 19

今の運営さんの話を元にしても議論にならない、という点については確かにそうかもしれません。
しかし最終的な判断を下すのは結局のところ、運営さんなのです。
なんとかしてもう少し運営さんから話を引き出さないと、お互い（運営さん＆機能追加を求める意見）の話がかみ合わない可能性があります。
25
01v 2025/09/14 (日) 11:07:00 修正 >> 19

いいえ違います。
そこの主語は不明確ですが運営であるべきです。そうでないなら運営の認識が誤りであるというのが私の意見です。
ユーザーには利用状況も内部の原理や負荷も見えないので議論になりません。何をもって公平かなど、気持ち次第でなんとでも言えるので、そこをに注力して話をしても発散するだけです。
24
01v 2025/09/14 (日) 10:46:01 修正 >> 8

popularは有用です。
私の例で言えば、popularやcounterのアクセス数からメニューの掲載基準や位置の決定に活用しました。
当時メニューが無法地帯だったので私はそれを整理しようとしました。
そのとき私は管理者ではなく来たばかりの新人でしたが、提案を数値に基づいて示したので話がスムーズだったと思います。

23
はやし 2025/09/14 (日) 10:34:45 70b72@f53e0 >> 19

公平性は気にするべきですが、それが本論ではありません。それは色々な意見をみて決定と実行をする運営が考える事です。

運営さんからの応答をもう一度読み直してほしいのですが、公平性に対する懸念は私一人の判断や価値観から出てきたものではなく、運営さんから指摘されていることです。
「様々な意見を見て決定する」という部分にはある程度同意しますが、「それが本論ではありません」の部分は経緯に対する誤解が見られるので同意しません。
22
01v 2025/09/14 (日) 10:16:46 >> 19

話題の対象が利用者全体なので、「私が必要としている理由はこれです」のような話をしても意味がない、ということです。（逆に「私には全然必要ありません」も無意味です）

いいえ。自分が必要している話をすべきです。
私は必要ありませんの意見も意味があります。
公平性は気にするべきですが、それが本論ではありません。それは色々な意見をみて決定と実行をする運営が考える事です。

私は現在困ってませんが、提示されたpopularの結果をみれば機能として使えないし、その回避策は煩雑で無駄な負荷をかけてることがわかります。この状況は多量のリネームや削除で自分にも容易に起こるとに気が付いたので、意見を述べています。一方でpopularなんて重要では無い立場の人も居るでしょうから、それはそう言えばいいです。例えば使ってないからコストや負荷かける価値を感じないという意見も良いと思います。
二つの意見は論点が交わらないので、言いっぱなしでいいです。無理に議論や説得をしなくていいです。
21
01v 2025/09/14 (日) 09:41:04 >> 17

各ページにcounterファイルの編集リンクを設置する(管理者用)

これは&counter_editみたいなプラグインを作って、必要に応じ各ページやメニューに仕込めばよいと考えました。現在の標準レイアウトに手を入れずに、必要な時だけ表に出し、不要になったら外せばいいです。

19
はやし 2025/09/14 (日) 08:40:34 70b72@f53e0 >> 17

今のお話の中にあったリンク の先のページの一番下に、重要な情報が見られます。

負荷の高いカウンター関連プラグインの非同期処理を行いました。カウンター向けの専用サーバーに集約しております。
WIKIとカウンターを切り離して動いておりますので、削除されたページのカウントも人気のページ表示されます。
また、renameプラグインでページ名を変更してもカウンターは引き継がれません。

どうしても修正したい方
数ページ程度であれば手動で反映いたしますのでお問い合わせください。

つまり、今の動作（削除済みのページも表示される、名前変更後に値が継承されない）は不具合でも想定外でもなく、すべて承知の上での仕様だということです。
また、「数ページ程度であれば手動で反映いたします」ともあります。推測になりますが、利用されることがほとんどないと見込まれるので、削除機能を提供するよりも手動で応じたほうが楽、という判断である可能性があります。

不具合でも想定外でもない意図どおりの仕様に変更を迫ることは、もちろん容易ではありません。周到な準備が必要です。
注目すべきは、運営さんからの返信にある「これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わる」という部分です。
これらをクリアした上での提案でないと、変更には応じてもらえないわけです。ひとつひとつ、考えてみましょう。

利用者全体の公平性

話題の対象が利用者全体なので、「私が必要としている理由はこれです」のような話をしても意味がない、ということです。（逆に「私には全然必要ありません」も無意味です）
新しい機能が自分にとって無縁の機能であっても、他人にとって利用価値がある機能なら、使わない人にとっても納得できます。
逆に、ごく一部の人しか喜ばない機能を作るようでは、不公平感が高まります。
つまり、使う人が多いということを示す必要があります。

これは容易ではありません。簡単に思いつく手段はアンケートですが、統計的に意味のある量のデータを集めることはほとんど不可能に思えます。
となれば、「ほとんど誰も使わないのでは？」という懸念となるような事案をひとつひとつ丁寧に、単なる決めつけではなく確かな理論的背景をもつ説明をしていくしかないように思います。
ここまでの話の中で上がっている懸念を簡単にまとめると、以下のとおりです。

  • popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは
  • Googleアナリティクスを使えばよいのでは

システム負荷

負荷の量やメカニズムについては、私などより01vさんのほうがよほど詳しいようです。
すこし目線を変えると、「負荷をどう減らすか」も重要ですが別のアプローチとして「要望する機能の価値を明らかにする」という手段も視野に入ります。
負荷が同じでも価値が高いなら、「しない」から「する」に傾かせることができます。
やみくもに「使う・要る・欲しい」と言うのではなく、具体的にどう役立つかを示せれば、提案に有利に働くでしょう。

運営方針

これはちょっと、私には意味がよく分かりません。
ただ、今回の要望が運営方針に対する悪影響の懸念がある、というのは確かに思えます。
この辺を明らかにし、その対策を含んだ提案をする必要があります。
18
副管理人(WoTBWiki) 2025/09/14 (日) 02:42:25 修正 >> 17

counterの仕様はそのようになっているんですね、勉強になります。
(アクアちゃんとは？と思いましたが...)

その上で、counterファイルを手動で弄れるようにする(管理者によるカウンターのリセットや編集を許可する)というのは反対です。
>> 14さんが仰っている通り管理者の無用な手間を増やすことになるうえ、結局の所管理者が荒らしてしまえば元も子もなく、任意リセットはcounterの価値を無くすものと思います。
そうした点では、ページ削除の操作によってcounterファイルに任意の識別子を付与し、popular側ではその識別子を元にフィルターすることを提案します。
リネームに関してはどのような手法を取っても復元不可能となるリスクがありますが、「ページ名の変更」操作を行った場合のみ自動でcounterを書き換えるような処理を追加すればよいのではないでしょうか。
17
01v 2025/09/14 (日) 01:20:42

現在私のところで削除済みのページが上位に表示されたり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ファイルの編集リンクを設置する(管理者用)
      実体はスペース区切りの単純なテキストファイルと思われる。
      数値を変更したり、全消しでファイル自体を削除できるようにする。

  • リネームしたときにカウンターを引き継げるようにする
    これは本来あるべき動作だと思います。
    >> 14に同意です。
    変更はplugin_rename_get_files()で簡単にできると、アクアちゃんが提案しています。

  • バックアップを取れるようにする
    色々いじれるようになって事故の恐れを考慮するなら

色々書いてみましたがこれを活用できる場面は限定的と思われ、以下あたりなら程よく実現できるのではないかと思います。

  • リネームしたときにカウンターを引き継ぐ(counterファイルもリネームして前のファイルは残さない)
  • 各ページにcounterファイルの編集リンクを設置する(管理者用)
16
款冬華 2025/09/13 (土) 22:05:15 >> 10

失礼いたしました。利用規約に違反しない程度に誤ったWiki運営の仕方をしていると決めつけた物言いやトピックに関係ない発言に対する揚げ足取りに気を取られて不必要な発言をしてしまいました。この投稿以降、私からの発言は控えます。

15
名前なし 2025/09/13 (土) 21:06:14 fc709@e41b5 >> 10

お言葉ですが一度貴方も落ち着いて自らの発言に客観性があるか見つめ直すべきではないでしょうか。
傍目にはあなたの発言も中々の挑発に見えますし、発言に一部矛盾も見られます。
落ち着きを持ち広い視野で様々な可能性を考えながら議論できる場となる事を望みます。
14
cept 2025/09/13 (土) 16:30:26

本リクエスト広場は一機能に対し一トピックの原則があり、かつ他の利用者さんが立てられたトピックに相乗りする形で恐縮なのですが、
おそらく趣旨がほとんど同じですので一つ意見を述べさせていただきたいです。

「管理人による特定ページのカウンターリセット機能」に強く同意するとともに、「ページ名を変更した場合、カウンターが引き継がれる仕様」も合わせて実装していただきたいです。

前提として、このケースは一定のアクセス数があるページを削除・リネームするときに生じるものです。
「ページがなくなった後もpopular中にリストアップされるカウンター数の多い記事」というのは、利用者が多くwikiにおいて重要なページなわけですから、純粋にページを消去するケースより、款冬華さんのような管理上の都合で別のページに移転したケースがほとんどのはずです。
管理上の都合として、私が経験したことがあるのは、
・記事立て時のページ名にミスがある
・取り扱うコンテンツの原作側の表記変更に合わせる
・記事の増加に伴い、wikiを整理するため階層化やページ命名法則の統一を行う
といったもので、いずれも既存のページから移行先のページにカウンターを引き継ぎたいものでした。

実際のところwikiwikiではページ名を変更した場合それまでのカウンターが引き継がれず、かつ存在しないページもpopularでリストアップする仕様です。
これによりリネームからかなりの期間、人気100には移転前のページが移転後のページより上位にリストアップされていました。

すでに消去したページや、別記事に移転せず完全に削除する記事に対しては、「管理人による特定ページのカウンターリセット機能」でしか対応し難いと思われますので、この機能をマストとしたうえで、
リネームするたびに「管理人による特定ページのカウンターリセット機能」で処理するのは管理側の負担を増やすことになりますから、「ページ名を変更した場合、カウンターが引き継がれる仕様」により、本件のような事例が発生しないよう仕様変更をお願いしたいです。
1
cept 2025/09/13 (土) 15:52:56

いつ頃からかは不明ですが、現在はURLが機能しているようですので、解決済みといたします。
ご対応ありがとうございました。
13
まるね 2025/09/13 (土) 11:00:21 修正

　#table_editにて、行だけでなく列の編集がしたいと思ってるんですが、ここでいいんですかね
表組みが縦に長いのと、ゲームの表示に合わせるために横に要素を足していくような使い方をしてるんですが、このプラグインは行の編集しかできず困ってます
13
款冬華 2025/09/13 (土) 10:36:17 修正 >> 10

通常、想定されている他所様のゲームWikiが展開されているような事情と大きく異なります。

まずはじめに毎回、扱うテーマは違えど全て同じジャンルかつ、同じ基盤システムの仕組みで成り立つ小規模のゲーム作品群です。総ページ数も約1430ページと大規模Wikiと比べても、アクセス数もページ数も圧倒的に少ないです。

wikiwikiの最新の更新ランキングで表示されている似たようなWikiで例えるならば、大手VTuberまとめwiki*や大手ゲームの用語辞典wiki*に該当します。これらWiki様や1万、2万ページを超えるWiki様のようにページ作成において、例えば大手VTuberまとめwiki*ならば所属タレントが増えていき大所帯になった今でも、独立Wikiを作って分散化させずに有名無名、規模の大きさ関係なく同じ基本テンプレートを用いてWikiが形成されています。当Wikiも同じく、基本テンプレートを用いて作品ごとに形成されています。

大規模ゲーム作品のようなゲームシステムで毎回、ジャンルが違ったり基本システムが大きく仕様が異なるならばそれぞれ作品のWikiを立ち上げることに意義があります。

分散化してWikiを作ることは管理面でも毎回、ログインする必要があり迷惑行為もそれぞれのWikiで規制ルール作成が必要のため、管理が煩雑化して現実的ではありません。wikiwikiのランキングにも多数の同じメーカーが表示されることになります。

はやしさんの回答「配慮の欠落が原因で問題を起こしたwiki」とあるように、まるで配慮してこなかったとあなた様から言われるような筋合いはありません。wikiwiki運営陣とはWikiの運営面に関して、約10年という長期運営の中でこれまでにやり取りがあり、関係は良好です。

以前にご指摘しましたが繰り返し突っかかってくる言動にあなた自身、発言内容を客観視できていますか。これまでに複数の要望を提案していても、問題を起こしていると認識しておりません。これ以降、はやしさんは掲示板トップに掲げている以下の引用内容を含めてコメントポリシーを反して返信されるので一切、回答いたしません。

以下の投稿を禁止します
相手を挑発するような内容
趣旨にそぐわない内容
投稿を削除することがあります。

12
はやし 2025/09/13 (土) 08:25:46 70b72@f53e0 >> 10

当Wikiに限ると扱っている作品数83本と多くあり

ひとつのwikiで83本ものゲームの攻略を扱うという、使い方に問題があります。
利用規約に背いてはいないのでしょうが、明らかに配慮が欠けています。

運営者からの回答のなかに「これらの点は利用者全体の公平性（中略）にも関わる」とあります。
配慮の欠落が原因で問題を起こしたwikiを救済するための機能追加や仕様変更に、公平性はありません。
運営者の立場から見て「うん、それなら公平だね」と思わせるに足る何かが提示されないかぎり、今回の提案が通ることはないように思います。
11
款冬華 2025/09/13 (土) 02:43:54 >> 3

賛同いただき、どうもありがとうございます。

誰もが簡単な1行のプラグインを記述するだけで、簡易的なひとつの指標をすべての閲覧者へ即座に一覧表示させられるのは有用性が高いと思います。
10
款冬華 2025/09/13 (土) 02:22:25 修正 >> 8

popularは統計としてどの様に役立つのでしょうか。
ページ構成や閲覧者次第でページ閲覧者ののべ人数など如何様にもなりませんか。

ご指摘のように、ページ閲覧者ののべ人数（PV数）はページ構成や閲覧者の行動に依存しますが、これはpopularプラグインの統計的価値を否定しないと思います。

訪問者数を簡単に可視化できるという簡易性、即時性、これまでに利用してきた利用者の関心について、どのコンテンツが注目されているかを「統計」を通じて即座にユーザーのサイト探索を促進することができます。これは、Googleアナリティクスのようなバックエンドツールだと利用者に分かりやすい形にして案内するには相当の時間や手間が掛かります。


ページを編集する立場として考えた場合でもcounterの値のみが役立つケースはごく稀であり、その様なページ作りをしたければGoogleアナリティクス等のツールを使わない理由は考えられません。
仮に使えない理由が存在したとしてBAN等の限定的な話ではありませんか。

編集の優先順位を決める手がかりになります。編集者はそのページの品質向上に注力できます。ボランティアベースの編集に頼っている大半のWikiは重要な動機付けとなります。閲覧者にとって、PV数が多いページは信頼性や関心度が高いと映る場合があり、さらなるサイトの探索や利用者のエンゲージメント(愛着や深い繋がり)を促進します。

すべてのWiki管理者が高度な分析ツールを導入するための技術的知識を新たに吸収して実践できるとは私自身は到底、思えません。popularプラグインは簡易な指標として価値があります。設定やアクセス解析ツールであるGoogleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり、すべてのWiki管理者が利用できる環境を整えたり、普及活動のために技術的知識を手に入れたいとは限りません。私自身も含みますが、PCを持たずしてモバイル端末だけで管理する者もいます。

2005年から運営が始まった現在の独自のwikiwikiになる前の基盤であるPukiwiki1.4(2003年リリース)で標準搭載され、利用者のアクセス傾向を簡単に知ることができます。todayとtotalは共に長年、どのWikiでも作成当初からMenuBar最下部にリンク表示されて使われてきたプラグインですので有用性は十分に裏付けされているでしょう。

削除されたページにおいてcounterの数は原則増えない事を前提とすれば長期的に運営していくにつれ削除されたページはpopularから消えてゆく事でしょう。
短期的であればtodayオプションが存在しますから必要性に疑問が残ります。

トピックに記載しているとおりでpopularプラグインを統計表示するときの話になります。

当Wikiは2009年にatwikiに発足、2016年にwikiwikiへ移行してから10年経過しようとしています。海外利用者も多くなり、国際基準に照らし合わせて日本語URLから英語URLへ統一、変更しています。そのため、現存しない日本語URLは勘違いさせて利便性を損ない、管理がなっていないと利用者からWiki管理者へのクレームにもなり得ます。(すでに過去にpopularプラグインの統計で表示された日本語URLのリンクが存在しないページであることを理由にクレームを頂いて対処)大半の日本語URLが表示されなくなるまで当Wikiの場合は統計10件に表示制限したとしても、現状のアクセス推移では入れ替わるまでに約10〜20年ほどの歳月がかかることを見込んでいます。TOP10の内訳はFrontPageと日本語URLが独占して、現存するページは一つも含まれません。

当Wikiに限ると扱っている作品数83本と多くあり、どれも似たり寄ったりと評されることがよくあります。さらにコンスタントに毎年、3〜5本の新作が発売されます。そこでGoogleアナリティクスだけでなく、popularプラグインも使って利用者の行動心理に影響を与える要素を増やして、さらなるエンゲージメントを促進しています。

当Wikiの例

  • 統計300件(フィルタなし版)
    記述内容: #popular(300)
  • 統計300件(フィルタあり版)
    記述内容:

直前の投稿内容を鑑みてもpopularにおいてweeklyやmonthlyの表示を行えれば十分ではありませんか。

時間枠の柔軟性は追加されたら便利ですが、今回の要望とは別軸にそれた話です。本件はpopularプラグインの統計(通算)に対するトピックを立てています。また、現存しないオプション機能を新たに追加することで問題の根幹が解決するわけではないことをご理解いただきたいです。

1
はやし 2025/09/12 (金) 20:32:02 70b72@f53e0

既存の機能だけで実現する手段はちょっと思いつきませんが、比較的軽微と思われる機能拡張で実現できる可能性があります。
cssboxプラグインが「overflow: scroll」を使えるようになれば、ツイートに限らず縦に長い様々なものを、小さなスペースに収めることができると思います。

ちなみに、このアイディアはここで既に提案されています。

8
名前なし 2025/09/12 (金) 09:17:33 80f8f@06be2 >> 7

twitter_timelineを廃止するとのことですが、
今後運営からの告知はhttps://z.wikiwiki.jp/wikiwiki/ が使われるという理解で良いのでしょうか。
できれば https://wikiwiki.jp/ トップ（例えば現在の「お知らせ」や「みんなが評価しているWIKI」の位置など）に、
最新の告知（1～数件分）を表示してもらえると助かります。
9
副管理人(WoTBWiki) 2025/09/12 (金) 03:29:28 修正 >> 3

そのような趣旨であれば賛同します。
当方そのようなケースに遭遇しなかったため特に気に留めていませんでしたが、簡易的なものとはいえ、残存しないページを一覧に出力する仕組みというのはプラグインとしてあまりにお粗末なものに感じます。

その上で、一般の利用者に対し(具体的なカウント数は不要としても)アクセスランキングという形を提供することは価値があると思います。Googleアナリティクスで十分だという指摘もありますが、あくまで管理者に重きをおいたサービスで、当然、一般の利用者向けにGoogleアナリティクスのデータを手動でWikiに反映するのは不毛な話です。

8
名前なし 2025/09/11 (木) 22:25:27 01062@e41b5

popularは統計としてどの様に役立つのでしょうか。
ページ構成や閲覧者次第でページ閲覧者ののべ人数など如何様にもなりませんか。
ページを編集する立場として考えた場合でもcounterの値のみが役立つケースはごく稀であり、その様なページ作りをしたければGoogleアナリティクス等のツールを使わない理由は考えられません。
仮に使えない理由が存在したとしてBAN等の限定的な話ではありませんか。

削除されたページにおいてcounterの数は原則増えない事を前提とすれば長期的に運営していくにつれ削除されたページはpopularから消えてゆく事でしょう。
短期的であればtodayオプションが存在しますから必要性に疑問が残ります。
直前の投稿内容を鑑みてもpopularにおいてweeklyやmonthlyの表示を行えれば十分ではありませんか。
7
款冬華 2025/09/11 (木) 01:17:52 >> 5

私やはやしさんのように他社サービスであるGoogleアナリティクスを扱い、全員が使いこなせるのであれば必要ないと思います。

プラグインは誰でも気軽にその場で即座に使えます。そのようなWiki内サービスは管理者の手助けツールとして役立ちます。今回、私自身が困ったときに他者が管理するWikiでも使えそうと判断して要望を出しています。

今回の件で言えば、①Googleアナリティクスの利用が何らかの事情で使えていない人でも困らないような調整をしてほしい。②管理者でなくても統計を確認できるプラグインは重宝する。例え、管理者が不在となったWikiでも後継者にとって、このプラグインはページ作りに役立つと考えられます。

また、本件の要望よりも別のことを優先してほしいという意見ですが、それは要望トピックを出された方や賛同意見を出した方は皆、そう思われているのではないでしょうか。どんなに便利で使い勝手の良さそうな要望で多くの意見が飛び交っても、採用を見送りされたりしています。開発の進捗フェーズの状況で運営さんにメンションされていても都合上、未回答のままであるトピックもあります。運営側は実装後のコストの見積りや他サービス・プラグインへの影響の有無、セキュリティ面などを全てクリアできると判断してから要望を一つひとつ叶えてくれていると思います。

話の流れで本件よりも他の要望に目を向けてほしいと暗に示していますが、私は気落ちしました。私だけでなく、>> 1さんや同じく必要とする利用者には感じ悪く思います。
6
款冬華 2025/09/11 (木) 01:13:06 >> 3

おっしゃられている通り、現存しないページが多くてフィルターに負荷がかかるのでどうにか軽減したいこととプラグインが『...loading』状態のまま機能しなくなることを防げるのであれば、リセット機能でなくても手段は問いません。

5
はやし 2025/09/08 (月) 18:54:54 70b72@f53e0

統計的な情報が必要であればGoogleアナリティクスを参照するので、ここを変えるよりもっと別のことを優先してほしい、というのが自分の意見です。

リクエスト広場のトップページには様々な注意書きがありますが、そのなかに「なぜそれが必要か理由を書く」とあります。
この点が少し欠けているのではないでしょうか。
4
副管理人(WoTBWiki) 2025/09/08 (月) 17:54:55 >> 3

個人的にはカウンターのリセット機能は不要だと思っています。本題は「削除したページをpopularから除外したい」ということであり、wikiwiki側でどのようなデータ管理となっているかは存じ上げませんが、ページ削除フラグのようなものがあればそれを目印にフィルターすればよいのではないでしょうか。
3
款冬華 2025/09/08 (月) 01:01:27 修正 >> 2

ご回答ありがとうございます。

そのため、「popular の通算リセット機能」を設けることは、実質的に 管理者が counter をリセットできる機能 と同等の意味合いを持ちます。

管理者が counter をリセットできる機能の実装を希望します。運営側はWiki発足当初からのカウントと利用者側が見れるカウントの2つを用意するなど、運営方針に影響でない形が望ましいです。機能追加していただけるならコントロールパネルにて単一ページを指定してカウントをリセットができたら助かります。システム負荷を考慮の上でテスト/*などのサブディレクトリ対応や複数ページ(hoge1/テスト、hoge2/testなどの指定)を同時にリセットできる機能があれば、さらに嬉しいです。システム的に実際の挙動はタスク同時ではなく、一つひとつ行って遅延処理するなどの対応イメージです。

Wiki利用者(Wiki管理者を含む)は現存しないページや通算カウントを一旦、リセットしたいページがあります。現状は除外しないと現存しないページも表示されて大変、不便です。

さらに、多数のフィルタをかけた場合は負荷が大きくなり、結果として「対象外とするページが多すぎると、文字数が増えてプラグインが『...loading』状態のまま機能しなくなる」ことがあります。

運営側も認識している通りで長く続けられているWikiほど、途中で削除されたページや不要のページも多くなるので当Wikiように除外ページの記述内容がどんどん増えていき、システム負荷も増えて使い勝手が悪くなっていきます。最終的にはカウント機能しなくなるほどに文字数も多くなります。実際に当Wikiは何度も限界に達して、その度に記述内容を見直しています。(①hoge/1、hoge/2などのページ→hoge/.*②二度目の限界後にhoge、hoge/*→hoge(/.*)?
)しかし、https://wikiwiki.jp/WIKIWIKI ID/のようなWIKIWIKI ID直下のページはそれぞれ、指定する必要があるのでこれ以上に増えた場合は現状、回避手段はなく見直しすることはできません。

ご検討のほど、よろしくお願いいたします。
4
rag 2025/09/07 (日) 22:09:21 >> 2

運営の意図(試験運用後置き換える予定など)は分かりませんが、個人的にも後継ではないと思っています。
工夫の余地に関しても理解しているつもりですが、問題はそれに関する手間です。
ecache利用時も、それの対応で時間を割くハメになったので他の編集者に利用を推奨しようとは思えません。
また、現状把握できている以外の他のプラグインで問題が起こるのかも不明なため、各々で調査する必要性が出てきます。

0.5という表記に関しては>> 1さんに返信後、そちらの表現をお借りして追記しました。
技術的な仕様が分からないため、詳細な説明を記載できず申し訳ありません。
自分が言うのも何ですが、意図や仕様が不明な内容に関して議論や断定をするのは不毛な気もします。
実際に利用して仕様の関係で諦めるのが無難と感じたため、改善を求めて要望しています。

@wikiwiki
利用するタイミングが適切か分かりませんが、改善可能であるか、改修予定があるかなどお答えいただけると助かります。
2
WIKIWIKI運営 2025/09/07 (日) 17:27:28

返信が遅くなり申し訳ありません。

popular プラグインのランキングは、各ページに記録されている counter の数から算出しています。
そのため、「popular の通算リセット機能」を設けることは、実質的に 管理者が counter をリセットできる機能 と同等の意味合いを持ちます。

また、ページの削除については一時的なものか恒久的なものか判断できないため、自動でランキングから除外することは難しい状況です。

さらに、多数のフィルタをかけた場合は負荷が大きくなり、結果として「対象外とするページが多すぎると、文字数が増えてプラグインが『...loading』状態のまま機能しなくなる」ことがあります。

これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わるため、機能追加の是非については 引き続き議論が必要 になると考えています。
7
WIKIWIKI運営 2025/09/07 (日) 17:09:44

返信が遅くなり申し訳ありません。

運営からのお知らせは、内容や対象となる方に合わせて、掲載する場所を分けています。
たとえば、速報的なお知らせは公式Xに載せ、やり取りが必要な場合はzawazawaを使うことがあります。

事情により配信先を分けている点はご理解いただければと思います。

また、重要なお知らせは、Xタイムラインでの掲載をやめ、今後はトップページに直接載せることも検討しています。

3
名前なし 2025/09/07 (日) 15:05:44 b47e1@e41b5 >> 2

前提として、lazy_foldはfoldの後継ではありません。
運営の説明に記載の"負荷軽減用プラグインは「おまじない」ではありません"という一文からも分かるかと思いますが、活用するのであれば、仕様を把握した上で見定める必要があります。
編集者・閲覧者の間で、負荷軽減と使用感を天秤にかけてどちらを使用するか考えなければならないでしょう。
よく分かっていない編集者については、コメントアウト等目に触れる箇所にfoldを選択した理由を記載するなど、工夫の余地があるかと思います。

ragさんの仰る0.5という挙動が具体性に欠けているようにも思います。
>> 1さんの仰るような仕様だとしても、ragさんの仰る"表示処理？が完全に終了する前に開いても内容を表示する"という要望は叶いません。
要望を聞く限りでは負荷軽減をあきらめた上でfoldを使用すればよろしいでしょう。