win11 edgeにてかな入力だと二重に入力されるというこれまた違う不具合が 基本的に日本語入力には対応してないのだろうか、ios使ってる編集者の人は特に問題なさそうだったんだけどなぁ
迅速なご対応、誠にありがとうございます。WIKIWIKI様には大変お世話になっています、これからも応援しております。 万が一また似たような事象が発生した場合はこちらの項目リストを基に情報提供させていただきます。 改めて、迅速に対応していただきありがとうございました。今後ともよろしくお願い致します。
ご連絡ありがとうございます。
問題のあった広告の配信元と思われるドメインをブロックしました。 ご迷惑をおかけしてしまい、本当に申し訳ありません。
現在は、再発防止に向けて 調査を続けています。 もし同じような現象が再び発生した場合は、原因を特定するために、次の情報を教えていただけると助かります。
みなさんからのご報告をもとに、より安全で快適に使える環境づくりを進めていきます。 引き続きご協力をよろしくお願いします。
情報ありがとうございます。やはり別環境・別リンク先でも事例が存在するんですね…。
追記: 自分が遭遇したリンク先は starprize.za.com でした(履歴に残ってた)。
自分はPC版(ちなみに2回ともチュウニズム攻略Wiki、Xbox Series Sで確認)で「ページを表示したその瞬間にauの名を騙った詐欺サイトに飛ぶ」というものに2度遭遇してます。
ありがとうございます。助かりました。感謝感激です。
&tag(,);としてみても消えないでしょうか おそらくこれで消えると思います
現時点での需要の無さによっても否定されていますので、「いやいや今すぐに再検討せよ」という意見を出すのであれば、現時点で需要があるという数字も出すべきではないでしょうか？ たとえば、贔屓にしている編集中のWikiでAVIFに関する提案をし、賛同件数100件/125件で80%だ、とか。
議題が放置されつづけ、2年経ってから結果として曖昧な理由で断られたことによる憤りも分かりますが。
AVIF形式への対応に賛成です。 先日Windows10のサポートも終了したため、再度ご検討いただければ幸いです。
>> 6
新管理者が移転の提案を行うことが禁止されているのは問題
いいえ、自分はそう思いません。
自分が作ったWikiであれば、登録ユーザー（＝管理者）は自由にWikiを閉鎖（移転含む）でき、 運営は、管理放棄されたWikiを閉鎖できます。 管理権限移譲のシステムは、諸事情で閉鎖が見込まれるWikiへの救済策であり、 救済策である以上、無条件という訳にはいかないということでしょう。
利用規約に「引き継いだ管理者は、元の運営方針を尊重すべき」とあるように、 新管理者に求められるのは、前任者の意思を継いで （引き続きWIKIWIKIで）Wikiを管理・維持していくことです。
そのつもりがない人に管理権限は譲渡されるべきではありませんし、 数ヵ月後、数年後に気が変わった？ということであれば、 その人がすべきはWikiの移転提案ではなく、別の誰かに管理権限を譲渡することです。
若干別軸かもしれませんが、議論の中で生じた疑問を書き込ませて頂きました。
個人的に思うのは、「新管理人は移転の提案不可だが、議論への参加は可能」なのか、「新管理人は移転の提案も議論の参加も不可」なのか、「管理人交代が起こったwikiは移転不可」なのか、そこははっきりさせて欲しい所ですね。 いずれにせよ新管理人がやや蚊帳の外になってしまう感は否めませんが…。
他の編集者が移転の提案を行うことが認められているにも関わらず、新管理者が移転の提案を行うことが禁止されているのは問題な気がします。 既に自分が言及していますが、そもそも、移転の提案自体が私物化行為に該当するとは考えられません。 その提案自体が私物化が目的だったり、その他悪意のある理由なのであれば問題ですが、そうでないのなら正当な提案だと自分は思います。 管理人も編集者の一人であり、一編集者として他の編集者と対等な立場でwikiの方針の話し合いに参加する権利はあるはずです。
どうも勘違いされているようですね。
そもそも Wikiの移転を運営が禁止しているという事実はありません。 （そんなことをすれば、独占禁止法に抵触してしまう可能性があります）
運営が禁じているのは「譲渡されたWikiを新管理者が私物化する行為」であり、 私物化行為の一例として「移転の 提案や誘導を（新管理者が）行うこと」が挙げられているに過ぎません。
新管理者が全く関知せずに、（もしくは反対した）結果として ユーザーの総意で移転が決まったのであれば移転はOKですし、 自分が作ったWikiならば、自分だけの判断で移転も閉鎖も自由です。
元々15歳以下向けのコンテンツを扱っていた
規約違反になりますので、速やかに違反部分を削除するか、 Wikiを移転するか、閉鎖するかしてください。
確かに、最近ルールの更新がありましたし、それにより根底からWIKIWIKI本体の方針とずれてしまい、修正が難しい場合は(元々15歳以下向けのコンテンツを扱っていた等)当然ながら、WIKIWIKIでずっと運営することは出来ないため、移転が必要になります。そのため、運営や利用者と相談の上で移転を行うのは許容していただきたいと思います。
音楽付き広告ほんとに迷惑。採用しているサイトは閲覧を避けてます。表示されたらすぐ閉じます。
あまり公式コミュニティで話すことではないですが、どんな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認証画面が表示されれば有効です。 [追記]管理者ログイン状態では規制の影響を受けないため、ログアウトした状態で検証してください。
特定のページ名の作成を制限する場合、規制ルールはどのように作成すれば良いでしょうか？
対象項目:ページ名 パターン種別:いずれかを含む パターン:(禁止するキーワード),(禁止するキーワード),...
で良いでしょうか？
win11 edgeにてかな入力だと二重に入力されるというこれまた違う不具合が
基本的に日本語入力には対応してないのだろうか、ios使ってる編集者の人は特に問題なさそうだったんだけどなぁ
迅速なご対応、誠にありがとうございます。WIKIWIKI様には大変お世話になっています、これからも応援しております。
万が一また似たような事象が発生した場合はこちらの項目リストを基に情報提供させていただきます。
改めて、迅速に対応していただきありがとうございました。今後ともよろしくお願い致します。
ご連絡ありがとうございます。
問題のあった広告の配信元と思われるドメインをブロックしました。
ご迷惑をおかけしてしまい、本当に申し訳ありません。
現在は、再発防止に向けて 調査を続けています。
もし同じような現象が再び発生した場合は、原因を特定するために、次の情報を教えていただけると助かります。
みなさんからのご報告をもとに、より安全で快適に使える環境づくりを進めていきます。
引き続きご協力をよろしくお願いします。
情報ありがとうございます。やはり別環境・別リンク先でも事例が存在するんですね…。
追記: 自分が遭遇したリンク先は starprize.za.com でした(履歴に残ってた)。
自分はPC版(ちなみに2回ともチュウニズム攻略Wiki、Xbox Series Sで確認)で「ページを表示したその瞬間にauの名を騙った詐欺サイトに飛ぶ」というものに2度遭遇してます。
ありがとうございます。助かりました。感謝感激です。
&tag(,);としてみても消えないでしょうか
おそらくこれで消えると思います
現時点での需要の無さによっても否定されていますので、「いやいや今すぐに再検討せよ」という意見を出すのであれば、現時点で需要があるという数字も出すべきではないでしょうか？
たとえば、贔屓にしている編集中のWikiでAVIFに関する提案をし、賛同件数100件/125件で80%だ、とか。
議題が放置されつづけ、2年経ってから結果として曖昧な理由で断られたことによる憤りも分かりますが。
AVIF形式への対応に賛成です。
先日Windows10のサポートも終了したため、再度ご検討いただければ幸いです。
>> 6
いいえ、自分はそう思いません。
自分が作ったWikiであれば、登録ユーザー（＝管理者）は自由にWikiを閉鎖（移転含む）でき、
運営は、管理放棄されたWikiを閉鎖できます。
管理権限移譲のシステムは、諸事情で閉鎖が見込まれるWikiへの救済策であり、
救済策である以上、無条件という訳にはいかないということでしょう。
利用規約に「引き継いだ管理者は、元の運営方針を尊重すべき」とあるように、
新管理者に求められるのは、前任者の意思を継いで
（引き続きWIKIWIKIで）Wikiを管理・維持していくことです。
そのつもりがない人に管理権限は譲渡されるべきではありませんし、
数ヵ月後、数年後に気が変わった？ということであれば、
その人がすべきはWikiの移転提案ではなく、別の誰かに管理権限を譲渡することです。
若干別軸かもしれませんが、議論の中で生じた疑問を書き込ませて頂きました。
個人的に思うのは、「新管理人は移転の提案不可だが、議論への参加は可能」なのか、「新管理人は移転の提案も議論の参加も不可」なのか、「管理人交代が起こったwikiは移転不可」なのか、そこははっきりさせて欲しい所ですね。
いずれにせよ新管理人がやや蚊帳の外になってしまう感は否めませんが…。
他の編集者が移転の提案を行うことが認められているにも関わらず、新管理者が移転の提案を行うことが禁止されているのは問題な気がします。
既に自分が言及していますが、そもそも、移転の提案自体が私物化行為に該当するとは考えられません。
その提案自体が私物化が目的だったり、その他悪意のある理由なのであれば問題ですが、そうでないのなら正当な提案だと自分は思います。
管理人も編集者の一人であり、一編集者として他の編集者と対等な立場でwikiの方針の話し合いに参加する権利はあるはずです。
どうも勘違いされているようですね。
そもそも Wikiの移転を運営が禁止しているという事実はありません。
（そんなことをすれば、独占禁止法に抵触してしまう可能性があります）
運営が禁じているのは「譲渡されたWikiを新管理者が私物化する行為」であり、
私物化行為の一例として「移転の 提案や誘導を（新管理者が）行うこと」が挙げられているに過ぎません。
新管理者が全く関知せずに、（もしくは反対した）結果として
ユーザーの総意で移転が決まったのであれば移転はOKですし、
自分が作ったWikiならば、自分だけの判断で移転も閉鎖も自由です。
規約違反になりますので、速やかに違反部分を削除するか、
Wikiを移転するか、閉鎖するかしてください。
確かに、最近ルールの更新がありましたし、それにより根底からWIKIWIKI本体の方針とずれてしまい、修正が難しい場合は(元々15歳以下向けのコンテンツを扱っていた等)当然ながら、WIKIWIKIでずっと運営することは出来ないため、移転が必要になります。そのため、運営や利用者と相談の上で移転を行うのは許容していただきたいと思います。
音楽付き広告ほんとに迷惑。採用しているサイトは閲覧を避けてます。表示されたらすぐ閉じます。
あまり公式コミュニティで話すことではないですが、どんな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認証画面が表示されれば有効です。
[追記]管理者ログイン状態では規制の影響を受けないため、ログアウトした状態で検証してください。
特定のページ名の作成を制限する場合、規制ルールはどのように作成すれば良いでしょうか？
で良いでしょうか？