通常、想定されている他所様のゲーム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年という長期運営の中でこれまでにやり取りがあり、関係は良好です。
以前にご指摘しましたが繰り返し突っかかってくる言動にあなた自身、発言内容を客観視できていますか。これまでに複数の要望を提案していても、問題を起こしていると認識しておりません。これ以降、はやしさんは掲示板トップに掲げている以下の引用内容を含めてコメントポリシーを反して返信されるので一切、回答いたしません。
以下の投稿を禁止します 相手を挑発するような内容 趣旨にそぐわない内容 投稿を削除することがあります。
当Wikiに限ると扱っている作品数83本と多くあり
ひとつのwikiで83本ものゲームの攻略を扱うという、使い方に問題があります。 利用規約に背いてはいないのでしょうが、明らかに配慮が欠けています。
運営者からの回答のなかに「これらの点は利用者全体の公平性（中略）にも関わる」とあります。 配慮の欠落が原因で問題を起こしたwikiを救済するための機能追加や仕様変更に、公平性はありません。 運営者の立場から見て「うん、それなら公平だね」と思わせるに足る何かが提示されないかぎり、今回の提案が通ることはないように思います。
賛同いただき、どうもありがとうございます。
誰もが簡単な1行のプラグインを記述するだけで、簡易的なひとつの指標をすべての閲覧者へ即座に一覧表示させられるのは有用性が高いと思います。
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の例
#popular(300)
#popular(300,RecentChanges|FrontPage|MenuBar|SandBox(/.*)?|others(/.*)?|ゲーム発展国\+\+(/.*)?|箱庭タウンズ(/.*)?|冒険キングダム島(/.*)?|大海賊クエスト島(/.*)?|こだわりラーメン館 全国編(/.*)?|創作パティシエ部(/.*)?|お住まい夢物語(/.*)?|冒険ダンジョン村2(/.*)?|まんが一本道〆(/.*)?|創作♪パティシエ部(/.*)?|お住まい夢物語(/.*)?|喫茶ブレンド物語(/.*)?|海鮮!!すし街道(/.*)?|ジャンボ空港物語(/.*)?|開拓サバイバル島(/.*)?|ソーシャル夢物語(/.*)?|フレンド募集(/.*)?|名門ポケット学院3(/.*)?|大盛グルメ食堂(/.*)?|ゆけむり温泉郷2(/.*)?|その他(/.*)?|開店コンビニ日記(/.*)?|名門ポケット学院3(/.*)?|名門ポケット学院2(/.*)?|財閥タウンズV(/.*)?|その他(/.*)?|ゆけむり温泉郷2(/.*)?|こだわりラーメン館(/.*)?|サッカークラブ物語2(/.*)?|G1牧場ステークス(/.*)?|あおぞら飛行隊(/.*)?|創造タウンズ島(/.*)?|合戦!!にんじゃ村(/.*)?|創作ハンバーガー堂(/.*)?|野球部ものがたり(/.*)?|ミリオン行進曲♪(/.*)?|ゆけむり温泉郷(/.*)?|名門ポケット学院1(/.*)?|バスケクラブ物語(/.*)?|大江戸タウンズ(/.*)?|TVスタジオ物語(/.*)?|南国バカンス島(/.*)?|常夏プールパレス(/.*)?|探検わんぱく動物園(/.*)?|ゆうえんち夢物語(/.*)?|風雲☆ボクシング物語(/.*)?|コメント(/.*)?|アニメスタジオ物語(/.*)?|きらめきスキー白書(/.*)?|開店デパート日記2(/.*)?|冒険ダンジョン村(/.*)?|開幕!!パドックGP2(/.*)?|開幕!!パドックGP(/.*)?|箱庭シティ鉄道(/.*)?|夢おこし商店街(/.*)?|森林キャンプが丘(/.*)?|洞窟ぼうけん団(/.*)?|質問コーナー(/.*)?|大盛りグルメ食堂(/.*)?|クルーズ大紀行(/.*)?|大空ヘクタール農園(/.*)?|映画スタジオ物語(/.*)?|開園ピクセル牧場(/.*)?|開店デパート日記(/.*)?|大魔法クエスト(/.*)?|名門ポケット学院(/.*)?|テニスクラブ物語(/.*)?|発見どうぶつ公園(/.*)?|アパレル洋品店(/.*)?|わいわいクエスト物語(/.*)?|ゲームセンター倶楽部(/.*)?|つくろう！ゴルフの森(/.*)?|発進!!ヒーロー基地(/.*)?|星になったカイロくん(/.*)?|サッカークラブ物語(/.*)?|ふれあい出版局(/.*)?|発掘☆ピラミッド王国(/.*)?|アストロ探検隊(/.*)?|放課後ファイタークラブ(/.*)?|冒険キングダム島(ペット)|雑談|キャラクター紹介|ゲームタイトル人気投票)
#
\
直前の投稿内容を鑑みてもpopularにおいてweeklyやmonthlyの表示を行えれば十分ではありませんか。
時間枠の柔軟性は追加されたら便利ですが、今回の要望とは別軸にそれた話です。本件はpopularプラグインの統計(通算)に対するトピックを立てています。また、現存しないオプション機能を新たに追加することで問題の根幹が解決するわけではないことをご理解いただきたいです。
既存の機能だけで実現する手段はちょっと思いつきませんが、比較的軽微と思われる機能拡張で実現できる可能性があります。 cssboxプラグインが「overflow: scroll」を使えるようになれば、ツイートに限らず縦に長い様々なものを、小さなスペースに収めることができると思います。
ちなみに、このアイディアはここで既に提案されています。
twitter_timelineを廃止するとのことですが、 今後運営からの告知はhttps://z.wikiwiki.jp/wikiwiki/ が使われるという理解で良いのでしょうか。 できれば https://wikiwiki.jp/ トップ（例えば現在の「お知らせ」や「みんなが評価しているWIKI」の位置など）に、 最新の告知（1～数件分）を表示してもらえると助かります。
そのような趣旨であれば賛同します。 当方そのようなケースに遭遇しなかったため特に気に留めていませんでしたが、簡易的なものとはいえ、残存しないページを一覧に出力する仕組みというのはプラグインとしてあまりにお粗末なものに感じます。
その上で、一般の利用者に対し(具体的なカウント数は不要としても)アクセスランキングという形を提供することは価値があると思います。Googleアナリティクスで十分だという指摘もありますが、あくまで管理者に重きをおいたサービスで、当然、一般の利用者向けにGoogleアナリティクスのデータを手動でWikiに反映するのは不毛な話です。
popularは統計としてどの様に役立つのでしょうか。 ページ構成や閲覧者次第でページ閲覧者ののべ人数など如何様にもなりませんか。 ページを編集する立場として考えた場合でもcounterの値のみが役立つケースはごく稀であり、その様なページ作りをしたければGoogleアナリティクス等のツールを使わない理由は考えられません。 仮に使えない理由が存在したとしてBAN等の限定的な話ではありませんか。
削除されたページにおいてcounterの数は原則増えない事を前提とすれば長期的に運営していくにつれ削除されたページはpopularから消えてゆく事でしょう。 短期的であればtodayオプションが存在しますから必要性に疑問が残ります。 直前の投稿内容を鑑みてもpopularにおいてweeklyやmonthlyの表示を行えれば十分ではありませんか。
私やはやしさんのように他社サービスであるGoogleアナリティクスを扱い、全員が使いこなせるのであれば必要ないと思います。
プラグインは誰でも気軽にその場で即座に使えます。そのようなWiki内サービスは管理者の手助けツールとして役立ちます。今回、私自身が困ったときに他者が管理するWikiでも使えそうと判断して要望を出しています。
今回の件で言えば、①Googleアナリティクスの利用が何らかの事情で使えていない人でも困らないような調整をしてほしい。②管理者でなくても統計を確認できるプラグインは重宝する。例え、管理者が不在となったWikiでも後継者にとって、このプラグインはページ作りに役立つと考えられます。
また、本件の要望よりも別のことを優先してほしいという意見ですが、それは要望トピックを出された方や賛同意見を出した方は皆、そう思われているのではないでしょうか。どんなに便利で使い勝手の良さそうな要望で多くの意見が飛び交っても、採用を見送りされたりしています。開発の進捗フェーズの状況で運営さんにメンションされていても都合上、未回答のままであるトピックもあります。運営側は実装後のコストの見積りや他サービス・プラグインへの影響の有無、セキュリティ面などを全てクリアできると判断してから要望を一つひとつ叶えてくれていると思います。
話の流れで本件よりも他の要望に目を向けてほしいと暗に示していますが、私は気落ちしました。私だけでなく、>> 1さんや同じく必要とする利用者には感じ悪く思います。
おっしゃられている通り、現存しないページが多くてフィルターに負荷がかかるのでどうにか軽減したいこととプラグインが『...loading』状態のまま機能しなくなることを防げるのであれば、リセット機能でなくても手段は問いません。
統計的な情報が必要であればGoogleアナリティクスを参照するので、ここを変えるよりもっと別のことを優先してほしい、というのが自分の意見です。
リクエスト広場のトップページには様々な注意書きがありますが、そのなかに「なぜそれが必要か理由を書く」とあります。 この点が少し欠けているのではないでしょうか。
個人的にはカウンターのリセット機能は不要だと思っています。本題は「削除したページをpopularから除外したい」ということであり、wikiwiki側でどのようなデータ管理となっているかは存じ上げませんが、ページ削除フラグのようなものがあればそれを目印にフィルターすればよいのではないでしょうか。
ご回答ありがとうございます。
そのため、「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直下のページはそれぞれ、指定する必要があるのでこれ以上に増えた場合は現状、回避手段はなく見直しすることはできません。
https://wikiwiki.jp/WIKIWIKI ID/
ご検討のほど、よろしくお願いいたします。
運営の意図(試験運用後置き換える予定など)は分かりませんが、個人的にも後継ではないと思っています。 工夫の余地に関しても理解しているつもりですが、問題はそれに関する手間です。 ecache利用時も、それの対応で時間を割くハメになったので他の編集者に利用を推奨しようとは思えません。 また、現状把握できている以外の他のプラグインで問題が起こるのかも不明なため、各々で調査する必要性が出てきます。
0.5という表記に関しては>> 1さんに返信後、そちらの表現をお借りして追記しました。 技術的な仕様が分からないため、詳細な説明を記載できず申し訳ありません。 自分が言うのも何ですが、意図や仕様が不明な内容に関して議論や断定をするのは不毛な気もします。 実際に利用して仕様の関係で諦めるのが無難と感じたため、改善を求めて要望しています。
@wikiwiki 利用するタイミングが適切か分かりませんが、改善可能であるか、改修予定があるかなどお答えいただけると助かります。
返信が遅くなり申し訳ありません。
popular プラグインのランキングは、各ページに記録されている counter の数から算出しています。 そのため、「popular の通算リセット機能」を設けることは、実質的に 管理者が counter をリセットできる機能 と同等の意味合いを持ちます。
また、ページの削除については一時的なものか恒久的なものか判断できないため、自動でランキングから除外することは難しい状況です。
これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わるため、機能追加の是非については 引き続き議論が必要 になると考えています。
運営からのお知らせは、内容や対象となる方に合わせて、掲載する場所を分けています。 たとえば、速報的なお知らせは公式Xに載せ、やり取りが必要な場合はzawazawaを使うことがあります。
事情により配信先を分けている点はご理解いただければと思います。
また、重要なお知らせは、Xタイムラインでの掲載をやめ、今後はトップページに直接載せることも検討しています。
前提として、lazy_foldはfoldの後継ではありません。 運営の説明に記載の"負荷軽減用プラグインは「おまじない」ではありません"という一文からも分かるかと思いますが、活用するのであれば、仕様を把握した上で見定める必要があります。 編集者・閲覧者の間で、負荷軽減と使用感を天秤にかけてどちらを使用するか考えなければならないでしょう。 よく分かっていない編集者については、コメントアウト等目に触れる箇所にfoldを選択した理由を記載するなど、工夫の余地があるかと思います。
ragさんの仰る0.5という挙動が具体性に欠けているようにも思います。 >> 1さんの仰るような仕様だとしても、ragさんの仰る"表示処理？が完全に終了する前に開いても内容を表示する"という要望は叶いません。 要望を聞く限りでは負荷軽減をあきらめた上でfoldを使用すればよろしいでしょう。
すみません、技術的な仕様は知らず都合が悪いかどうかすら分かりませんでした。 デフォルト動作にしてほしいとは思っておらず、オプション化に関しては大賛成です。 例えば、極力使用感を損なわずに負荷を軽減したいMenuBarに利用すれば効果は大きいと思います(必ず表示されるページのため)。 利用しにくい仕様のせいで利用されなければ効果が無いのと同義ではないでしょうか。
ご対応ありがとうございました！
@wikiwikiこちらの件、私もお待ちしております マニュアルがきちんと整備されていればWIKIWIKIへの信頼感と編集意欲が高まり、ゆくゆくはコミュニティ全体の活性化に繋がると思います。
Wikiはブログと異なり、複数人での編集が前提のシステムなので、 投稿内容の事前予約のようなことはできません。 常に誰かが行った最終更新に対して加筆・修正という形になります。
要望していた機能が実装されたため、解決済タグを付けました。
対応ありがとうございました。
上記の不具合を修正しました。 ご迷惑をおかけして申し訳ありません。
zrecent の反映には少し時間差が生じますが、 仕様によるものですので、あらかじめご理解いただければ幸いです。
ご連絡ありがとうございます。 対応しておりますので、今しばらくお待ちください。
Googleアナリティクスから確認可能なので、コントロールパネルに追加する意義はないかと思います。
不具合ではなく、Xの仕様変更によるものなので、 ブラウザでXへのログインを維持すれば、引き続き見れると思います。 （はやし氏のキャッシュの影響という推測はたぶん当たっています）
自分はXを利用していないため、 しばらく前からXのタイムラインは閲覧不可になっています。 （添付された画像と同じ状況。クリックすれば見れますが、 時系列順に並ばずソートもできないため、事実上使えない）
そのためこちらの要望に賛同しているのですが、 メンションが送られているにも拘らず、運営の回答無視が続いていて、 ちょっとイラっと来ているところです。
TwitterTimelineプラグインを使用したタイムラインの埋め込みは、かなり前からそのような動きになっています。 数日前までタイムラインが見えていた、とのことですが、それはキャッシュの影響でそう見えていただけかもしれません。
原因ですがwikiwiki側の障害ではなく、X（旧Twitter）側に問題があるようです。 どこのサイトでも埋め込みタイムラインが表示されなくなっており、X側に障害が起きているか、または意図的にタイムラインの提供が中断されている、と見るべき状況です。 Xの有料アカウントにログインしているユーザーだけ、埋め込みタイムラインを閲覧できる、という説もあるようですが、実態は私には分かりません。
@wikiwikiAVIF形式の画像について、既にメジャーな形式となっており、ほぼ全てのブラウザが対応していることから、AVIF画像への対応が適切だと考えています。 AVIF形式の画像への対応についての検討に関する2025年現在の状況、及び今後の対応への是非について、運営の見解をお聞きしたいです。
それは当然の動作ではないでしょうか？
0か1ではなく0.5（テキストデータだけ先行読込、HTML組立は開いたときにやる）を求めるのであれば、デフォルト動作変更は反対です。負荷軽減が薄れます。 どうしても、というのであればオプション化は反対しませんが、需要があるかは疑問符です。
素晴らしい要望です。 アンカーの名前に仮名や漢字が使えるようになって、さらにアンカーを自分で書かなかったときに自動生成される名前が見出しの名前と同じになったら、すごく便利だと思います。
これまでの意見を簡単にまとめたいと思います：
議論がある程度終わりましたので、運営からのコメントをお願いします。@wikiwiki
運営に動いてほしい という要望ということ？ であればこれ以上議論しようがないのでは？
公式のマニュアルをユーザに編集させるのは非現実的すぎるので、他の方の意見にあるように 引き続きマニュアル整備を要望し続けるか、有志で非公式プラグインマニュアルwikiを立ち上げるのが妥当かと思います。
主は「運営ができなければユーザー側で手伝いたい」とは一言も言っていないのですり替わってはいますね 自分たちでwikiを作って参加するのは>> 9の通り自由なので、ここでは>> 5のように元々あるさんぷるwikiを一般にも編集できるように要望する方がいいかと
何がすりかわったのかよくわかりませんが、マニュアルを整備してほしい→運営でできないのであればユーザが手伝います という話ですよね？
関連性があっても、話題のすり替えはあまり好ましくないです。 （木主の要望は、プラグインマニュアルの再整備・内容の充実です）
そもそも「プラグインのWikiを作る」ことは（18歳以上なら）誰にでもできますので、 運営に要望するようなことではないです。 自由に作ればいいでしょう。
認証コードを送って認証完了のメッセージが出たのに、いざ書き込もうとすると「認証のない書き込みは制限されています」だとよ。何だよこれ
通常、想定されている他所様のゲーム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年という長期運営の中でこれまでにやり取りがあり、関係は良好です。
以前にご指摘しましたが繰り返し突っかかってくる言動にあなた自身、発言内容を客観視できていますか。これまでに複数の要望を提案していても、問題を起こしていると認識しておりません。これ以降、はやしさんは掲示板トップに掲げている以下の引用内容を含めてコメントポリシーを反して返信されるので一切、回答いたしません。
ひとつのwikiで83本ものゲームの攻略を扱うという、使い方に問題があります。
利用規約に背いてはいないのでしょうが、明らかに配慮が欠けています。
運営者からの回答のなかに「これらの点は利用者全体の公平性（中略）にも関わる」とあります。
配慮の欠落が原因で問題を起こしたwikiを救済するための機能追加や仕様変更に、公平性はありません。
運営者の立場から見て「うん、それなら公平だね」と思わせるに足る何かが提示されないかぎり、今回の提案が通ることはないように思います。
賛同いただき、どうもありがとうございます。
誰もが簡単な1行のプラグインを記述するだけで、簡易的なひとつの指標をすべての閲覧者へ即座に一覧表示させられるのは有用性が高いと思います。
ご指摘のように、ページ閲覧者ののべ人数（PV数）はページ構成や閲覧者の行動に依存しますが、これはpopularプラグインの統計的価値を否定しないと思います。
訪問者数を簡単に可視化できるという簡易性、即時性、これまでに利用してきた利用者の関心について、どのコンテンツが注目されているかを「統計」を通じて即座にユーザーのサイト探索を促進することができます。これは、Googleアナリティクスのようなバックエンドツールだと利用者に分かりやすい形にして案内するには相当の時間や手間が掛かります。
編集の優先順位を決める手がかりになります。編集者はそのページの品質向上に注力できます。ボランティアベースの編集に頼っている大半のWikiは重要な動機付けとなります。閲覧者にとって、PV数が多いページは信頼性や関心度が高いと映る場合があり、さらなるサイトの探索や利用者のエンゲージメント(愛着や深い繋がり)を促進します。
すべてのWiki管理者が高度な分析ツールを導入するための技術的知識を新たに吸収して実践できるとは私自身は到底、思えません。popularプラグインは簡易な指標として価値があります。設定やアクセス解析ツールであるGoogleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり、すべてのWiki管理者が利用できる環境を整えたり、普及活動のために技術的知識を手に入れたいとは限りません。私自身も含みますが、PCを持たずしてモバイル端末だけで管理する者もいます。
2005年から運営が始まった現在の独自のwikiwikiになる前の基盤であるPukiwiki1.4(2003年リリース)で標準搭載され、利用者のアクセス傾向を簡単に知ることができます。todayとtotalは共に長年、どのWikiでも作成当初からMenuBar最下部にリンク表示されて使われてきたプラグインですので有用性は十分に裏付けされているでしょう。
トピックに記載しているとおりで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の例
記述内容:
#popular(300)記述内容:
#popular(300,RecentChanges|FrontPage|MenuBar|SandBox(/.*)?|others(/.*)?|ゲーム発展国\+\+(/.*)?|箱庭タウンズ(/.*)?|冒険キングダム島(/.*)?|大海賊クエスト島(/.*)?|こだわりラーメン館 全国編(/.*)?|創作パティシエ部(/.*)?|お住まい夢物語(/.*)?|冒険ダンジョン村2(/.*)?|まんが一本道〆(/.*)?|創作♪パティシエ部(/.*)?|お住まい夢物語(/.*)?|喫茶ブレンド物語(/.*)?|海鮮!!すし街道(/.*)?|ジャンボ空港物語(/.*)?|開拓サバイバル島(/.*)?|ソーシャル夢物語(/.*)?|フレンド募集(/.*)?|名門ポケット学院3(/.*)?|大盛グルメ食堂(/.*)?|ゆけむり温泉郷2(/.*)?|その他(/.*)?|開店コンビニ日記(/.*)?|名門ポケット学院3(/.*)?|名門ポケット学院2(/.*)?|財閥タウンズV(/.*)?|その他(/.*)?|ゆけむり温泉郷2(/.*)?|こだわりラーメン館(/.*)?|サッカークラブ物語2(/.*)?|G1牧場ステークス(/.*)?|あおぞら飛行隊(/.*)?|創造タウンズ島(/.*)?|合戦!!にんじゃ村(/.*)?|創作ハンバーガー堂(/.*)?|野球部ものがたり(/.*)?|ミリオン行進曲♪(/.*)?|ゆけむり温泉郷(/.*)?|名門ポケット学院1(/.*)?|バスケクラブ物語(/.*)?|大江戸タウンズ(/.*)?|TVスタジオ物語(/.*)?|南国バカンス島(/.*)?|常夏プールパレス(/.*)?|探検わんぱく動物園(/.*)?|ゆうえんち夢物語(/.*)?|風雲☆ボクシング物語(/.*)?|コメント(/.*)?|アニメスタジオ物語(/.*)?|きらめきスキー白書(/.*)?|開店デパート日記2(/.*)?|冒険ダンジョン村(/.*)?|開幕!!パドックGP2(/.*)?|開幕!!パドックGP(/.*)?|箱庭シティ鉄道(/.*)?|夢おこし商店街(/.*)?|森林キャンプが丘(/.*)?|洞窟ぼうけん団(/.*)?|質問コーナー(/.*)?|大盛りグルメ食堂(/.*)?|クルーズ大紀行(/.*)?|大空ヘクタール農園(/.*)?|映画スタジオ物語(/.*)?|開園ピクセル牧場(/.*)?|開店デパート日記(/.*)?|大魔法クエスト(/.*)?|名門ポケット学院(/.*)?|テニスクラブ物語(/.*)?|発見どうぶつ公園(/.*)?|アパレル洋品店(/.*)?|わいわいクエスト物語(/.*)?|ゲームセンター倶楽部(/.*)?|つくろう！ゴルフの森(/.*)?|発進!!ヒーロー基地(/.*)?|星になったカイロくん(/.*)?|サッカークラブ物語(/.*)?|ふれあい出版局(/.*)?|発掘☆ピラミッド王国(/.*)?|アストロ探検隊(/.*)?|放課後ファイタークラブ(/.*)?|冒険キングダム島(ペット)|雑談|キャラクター紹介|ゲームタイトル人気投票)時間枠の柔軟性は追加されたら便利ですが、今回の要望とは別軸にそれた話です。本件はpopularプラグインの統計(通算)に対するトピックを立てています。また、現存しないオプション機能を新たに追加することで問題の根幹が解決するわけではないことをご理解いただきたいです。
既存の機能だけで実現する手段はちょっと思いつきませんが、比較的軽微と思われる機能拡張で実現できる可能性があります。
cssboxプラグインが「overflow: scroll」を使えるようになれば、ツイートに限らず縦に長い様々なものを、小さなスペースに収めることができると思います。
ちなみに、このアイディアはここで既に提案されています。
twitter_timelineを廃止するとのことですが、
今後運営からの告知はhttps://z.wikiwiki.jp/wikiwiki/ が使われるという理解で良いのでしょうか。
できれば https://wikiwiki.jp/ トップ（例えば現在の「お知らせ」や「みんなが評価しているWIKI」の位置など）に、
最新の告知（1～数件分）を表示してもらえると助かります。
そのような趣旨であれば賛同します。
当方そのようなケースに遭遇しなかったため特に気に留めていませんでしたが、簡易的なものとはいえ、残存しないページを一覧に出力する仕組みというのはプラグインとしてあまりにお粗末なものに感じます。
その上で、一般の利用者に対し(具体的なカウント数は不要としても)アクセスランキングという形を提供することは価値があると思います。Googleアナリティクスで十分だという指摘もありますが、あくまで管理者に重きをおいたサービスで、当然、一般の利用者向けにGoogleアナリティクスのデータを手動でWikiに反映するのは不毛な話です。
popularは統計としてどの様に役立つのでしょうか。
ページ構成や閲覧者次第でページ閲覧者ののべ人数など如何様にもなりませんか。
ページを編集する立場として考えた場合でもcounterの値のみが役立つケースはごく稀であり、その様なページ作りをしたければGoogleアナリティクス等のツールを使わない理由は考えられません。
仮に使えない理由が存在したとしてBAN等の限定的な話ではありませんか。
削除されたページにおいてcounterの数は原則増えない事を前提とすれば長期的に運営していくにつれ削除されたページはpopularから消えてゆく事でしょう。
短期的であればtodayオプションが存在しますから必要性に疑問が残ります。
直前の投稿内容を鑑みてもpopularにおいてweeklyやmonthlyの表示を行えれば十分ではありませんか。
私やはやしさんのように他社サービスであるGoogleアナリティクスを扱い、全員が使いこなせるのであれば必要ないと思います。
プラグインは誰でも気軽にその場で即座に使えます。そのようなWiki内サービスは管理者の手助けツールとして役立ちます。今回、私自身が困ったときに他者が管理するWikiでも使えそうと判断して要望を出しています。
今回の件で言えば、①Googleアナリティクスの利用が何らかの事情で使えていない人でも困らないような調整をしてほしい。②管理者でなくても統計を確認できるプラグインは重宝する。例え、管理者が不在となったWikiでも後継者にとって、このプラグインはページ作りに役立つと考えられます。
また、本件の要望よりも別のことを優先してほしいという意見ですが、それは要望トピックを出された方や賛同意見を出した方は皆、そう思われているのではないでしょうか。どんなに便利で使い勝手の良さそうな要望で多くの意見が飛び交っても、採用を見送りされたりしています。開発の進捗フェーズの状況で運営さんにメンションされていても都合上、未回答のままであるトピックもあります。運営側は実装後のコストの見積りや他サービス・プラグインへの影響の有無、セキュリティ面などを全てクリアできると判断してから要望を一つひとつ叶えてくれていると思います。
話の流れで本件よりも他の要望に目を向けてほしいと暗に示していますが、私は気落ちしました。私だけでなく、>> 1さんや同じく必要とする利用者には感じ悪く思います。
おっしゃられている通り、現存しないページが多くてフィルターに負荷がかかるのでどうにか軽減したいこととプラグインが『...loading』状態のまま機能しなくなることを防げるのであれば、リセット機能でなくても手段は問いません。
統計的な情報が必要であればGoogleアナリティクスを参照するので、ここを変えるよりもっと別のことを優先してほしい、というのが自分の意見です。
リクエスト広場のトップページには様々な注意書きがありますが、そのなかに「なぜそれが必要か理由を書く」とあります。
この点が少し欠けているのではないでしょうか。
個人的にはカウンターのリセット機能は不要だと思っています。本題は「削除したページをpopularから除外したい」ということであり、wikiwiki側でどのようなデータ管理となっているかは存じ上げませんが、ページ削除フラグのようなものがあればそれを目印にフィルターすればよいのではないでしょうか。
ご回答ありがとうございます。
管理者が counter をリセットできる機能の実装を希望します。運営側はWiki発足当初からのカウントと利用者側が見れるカウントの2つを用意するなど、運営方針に影響でない形が望ましいです。機能追加していただけるならコントロールパネルにて単一ページを指定してカウントをリセットができたら助かります。システム負荷を考慮の上でテスト/*などのサブディレクトリ対応や複数ページ(hoge1/テスト、hoge2/testなどの指定)を同時にリセットできる機能があれば、さらに嬉しいです。システム的に実際の挙動はタスク同時ではなく、一つひとつ行って遅延処理するなどの対応イメージです。
Wiki利用者(Wiki管理者を含む)は現存しないページや通算カウントを一旦、リセットしたいページがあります。現状は除外しないと現存しないページも表示されて大変、不便です。
運営側も認識している通りで長く続けられているWikiほど、途中で削除されたページや不要のページも多くなるので当Wikiように除外ページの記述内容がどんどん増えていき、システム負荷も増えて使い勝手が悪くなっていきます。最終的にはカウント機能しなくなるほどに文字数も多くなります。実際に当Wikiは何度も限界に達して、その度に記述内容を見直しています。(①hoge/1、hoge/2などのページ→hoge/.
*②二度目の限界後にhoge、hoge/*→hoge(/.*)?)しかし、
https://wikiwiki.jp/WIKIWIKI ID/のようなWIKIWIKI ID直下のページはそれぞれ、指定する必要があるのでこれ以上に増えた場合は現状、回避手段はなく見直しすることはできません。ご検討のほど、よろしくお願いいたします。
運営の意図(試験運用後置き換える予定など)は分かりませんが、個人的にも後継ではないと思っています。
工夫の余地に関しても理解しているつもりですが、問題はそれに関する手間です。
ecache利用時も、それの対応で時間を割くハメになったので他の編集者に利用を推奨しようとは思えません。
また、現状把握できている以外の他のプラグインで問題が起こるのかも不明なため、各々で調査する必要性が出てきます。
0.5という表記に関しては>> 1さんに返信後、そちらの表現をお借りして追記しました。
技術的な仕様が分からないため、詳細な説明を記載できず申し訳ありません。
自分が言うのも何ですが、意図や仕様が不明な内容に関して議論や断定をするのは不毛な気もします。
実際に利用して仕様の関係で諦めるのが無難と感じたため、改善を求めて要望しています。
@wikiwiki
利用するタイミングが適切か分かりませんが、改善可能であるか、改修予定があるかなどお答えいただけると助かります。
返信が遅くなり申し訳ありません。
popular プラグインのランキングは、各ページに記録されている counter の数から算出しています。
そのため、「popular の通算リセット機能」を設けることは、実質的に 管理者が counter をリセットできる機能 と同等の意味合いを持ちます。
また、ページの削除については一時的なものか恒久的なものか判断できないため、自動でランキングから除外することは難しい状況です。
さらに、多数のフィルタをかけた場合は負荷が大きくなり、結果として「対象外とするページが多すぎると、文字数が増えてプラグインが『...loading』状態のまま機能しなくなる」ことがあります。
これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わるため、機能追加の是非については 引き続き議論が必要 になると考えています。
返信が遅くなり申し訳ありません。
運営からのお知らせは、内容や対象となる方に合わせて、掲載する場所を分けています。
たとえば、速報的なお知らせは公式Xに載せ、やり取りが必要な場合はzawazawaを使うことがあります。
事情により配信先を分けている点はご理解いただければと思います。
また、重要なお知らせは、Xタイムラインでの掲載をやめ、今後はトップページに直接載せることも検討しています。
前提として、lazy_foldはfoldの後継ではありません。
運営の説明に記載の"負荷軽減用プラグインは「おまじない」ではありません"という一文からも分かるかと思いますが、活用するのであれば、仕様を把握した上で見定める必要があります。
編集者・閲覧者の間で、負荷軽減と使用感を天秤にかけてどちらを使用するか考えなければならないでしょう。
よく分かっていない編集者については、コメントアウト等目に触れる箇所にfoldを選択した理由を記載するなど、工夫の余地があるかと思います。
ragさんの仰る0.5という挙動が具体性に欠けているようにも思います。
>> 1さんの仰るような仕様だとしても、ragさんの仰る"表示処理？が完全に終了する前に開いても内容を表示する"という要望は叶いません。
要望を聞く限りでは負荷軽減をあきらめた上でfoldを使用すればよろしいでしょう。
すみません、技術的な仕様は知らず都合が悪いかどうかすら分かりませんでした。
デフォルト動作にしてほしいとは思っておらず、オプション化に関しては大賛成です。
例えば、極力使用感を損なわずに負荷を軽減したいMenuBarに利用すれば効果は大きいと思います(必ず表示されるページのため)。
利用しにくい仕様のせいで利用されなければ効果が無いのと同義ではないでしょうか。
ご対応ありがとうございました！
@wikiwikiこちらの件、私もお待ちしております
マニュアルがきちんと整備されていればWIKIWIKIへの信頼感と編集意欲が高まり、ゆくゆくはコミュニティ全体の活性化に繋がると思います。
Wikiはブログと異なり、複数人での編集が前提のシステムなので、
投稿内容の事前予約のようなことはできません。
常に誰かが行った最終更新に対して加筆・修正という形になります。
要望していた機能が実装されたため、解決済タグを付けました。
対応ありがとうございました。
上記の不具合を修正しました。
ご迷惑をおかけして申し訳ありません。
zrecent の反映には少し時間差が生じますが、
仕様によるものですので、あらかじめご理解いただければ幸いです。
ご連絡ありがとうございます。
対応しておりますので、今しばらくお待ちください。
上記の不具合を修正しました。
ご迷惑をおかけして申し訳ありません。
ご連絡ありがとうございます。
対応しておりますので、今しばらくお待ちください。
Googleアナリティクスから確認可能なので、コントロールパネルに追加する意義はないかと思います。
不具合ではなく、Xの仕様変更によるものなので、
ブラウザでXへのログインを維持すれば、引き続き見れると思います。
（はやし氏のキャッシュの影響という推測はたぶん当たっています）
自分はXを利用していないため、
しばらく前からXのタイムラインは閲覧不可になっています。
（添付された画像と同じ状況。クリックすれば見れますが、
時系列順に並ばずソートもできないため、事実上使えない）
そのためこちらの要望に賛同しているのですが、
メンションが送られているにも拘らず、運営の回答無視が続いていて、
ちょっとイラっと来ているところです。
TwitterTimelineプラグインを使用したタイムラインの埋め込みは、かなり前からそのような動きになっています。
数日前までタイムラインが見えていた、とのことですが、それはキャッシュの影響でそう見えていただけかもしれません。
原因ですがwikiwiki側の障害ではなく、X（旧Twitter）側に問題があるようです。
どこのサイトでも埋め込みタイムラインが表示されなくなっており、X側に障害が起きているか、または意図的にタイムラインの提供が中断されている、と見るべき状況です。
Xの有料アカウントにログインしているユーザーだけ、埋め込みタイムラインを閲覧できる、という説もあるようですが、実態は私には分かりません。
@wikiwikiAVIF形式の画像について、既にメジャーな形式となっており、ほぼ全てのブラウザが対応していることから、AVIF画像への対応が適切だと考えています。
AVIF形式の画像への対応についての検討に関する2025年現在の状況、及び今後の対応への是非について、運営の見解をお聞きしたいです。
それは当然の動作ではないでしょうか？
0か1ではなく0.5（テキストデータだけ先行読込、HTML組立は開いたときにやる）を求めるのであれば、デフォルト動作変更は反対です。負荷軽減が薄れます。
どうしても、というのであればオプション化は反対しませんが、需要があるかは疑問符です。
素晴らしい要望です。
アンカーの名前に仮名や漢字が使えるようになって、さらにアンカーを自分で書かなかったときに自動生成される名前が見出しの名前と同じになったら、すごく便利だと思います。
これまでの意見を簡単にまとめたいと思います：
議論がある程度終わりましたので、運営からのコメントをお願いします。@wikiwiki
運営に動いてほしい という要望ということ？
であればこれ以上議論しようがないのでは？
公式のマニュアルをユーザに編集させるのは非現実的すぎるので、他の方の意見にあるように
引き続きマニュアル整備を要望し続けるか、有志で非公式プラグインマニュアルwikiを立ち上げるのが妥当かと思います。
主は「運営ができなければユーザー側で手伝いたい」とは一言も言っていないのですり替わってはいますね
自分たちでwikiを作って参加するのは>> 9の通り自由なので、ここでは>> 5のように元々あるさんぷるwikiを一般にも編集できるように要望する方がいいかと
何がすりかわったのかよくわかりませんが、マニュアルを整備してほしい→運営でできないのであればユーザが手伝います という話ですよね？
関連性があっても、話題のすり替えはあまり好ましくないです。
（木主の要望は、プラグインマニュアルの再整備・内容の充実です）
そもそも「プラグインのWikiを作る」ことは（18歳以上なら）誰にでもできますので、
運営に要望するようなことではないです。
自由に作ればいいでしょう。
認証コードを送って認証完了のメッセージが出たのに、いざ書き込もうとすると「認証のない書き込みは制限されています」だとよ。何だよこれ