該当サイトに問い合わせてください。WIKIWIKI運営には何の関係もないサイトです。
コメントありがとうございます。 利用しているWikiのゲームの特性上、同じ画像を複数ページで使いまわしているような状況で、そうではない使い方になるとページごとに同じ画像を添付していくような形になってしまい、管理上問題が発生してしまいます。 ※アイコンや画像、仕様などがアプデなどで頻繁に変わり、ページごとで最新の画像が使われたり使われなかったりが発生しました。
画像やファイルを保管するためだけの倉庫としては使っていません。
画像添付専用のページを作り、そこに大量の画像をアップして運用するというのは、 「そのWIKIでの特別な事情」に該当するのではと思います。
>> 2「ページ名指定が固定になって編集が楽」という意見ですが、 attachを使用すればページ名指定は不要ですし、 複数ページで同じ画像の使い回しを大量に行っているということであれば、 やはりそれも「そのWIKIでの特別な事情」に該当しそうです。
「複数のページにバラけさせるのは不便かつ煩雑」という意見も、 あまり一般的とは思えません。 私自身について言えば、同じ画像を複数ページで使い回すことは基本的にないため、 ページごとに使用画像を添付する方がシンプルで分かり易く、 むしろこちらが一般的でなないかと思います。
このように、どちらが使い易いと感じるかは個人の主観に左右される上、 「複数のページにバラけさせるのは不便」と言いつつ、 その運用で逆に不便が生じているからトピックを立てている訳で、 矛盾が生じています。
追加情報です。 本トピック投稿後、規制ユーザーを追加する機会が何回かありましたが、再現率は100％でした。
また、追加順ですが、下記の順に1つずつ追加される状況となっている模様です。 SMSトークン→ホスト→クッキー
起票よりそろそろ1ヶ月程度経過しますが、状況はどうなっているでしょうか？ 管理者がこの不具合に気付いていないと、荒らし対策が十分に機能しない可能性が考えられます。可及的速やかな対応を望みます。
賛成です。 自動読み込み無し、最新○件まで表示(+もっと見る)、非表示や格納、などで負荷を軽減してほしいです。 添付ファイルの確認をするために添付ページを開くのは稀ですし、毎回全てを表示させる必要はありません。
ページ名指定が固定になって編集が楽なので、用途毎などで特定のページに纏めたほうが運用する上で都合が良いです。 1ページに纏まってるから倉庫(保管用途)のように見えるだけで、倉庫(運用用途)とは異なります。 纏めてもバラけさせてもwiki全体のファイル総量は変わりませんし、禁止しているのはあくまで保管用途です。 添付ページの表示負荷を軽減するためだけに、意図的に複数のページにバラけさせるのは不便かつ煩雑です。 現状特定のページに纏めているwikiで実行すると、再添付とリンク調整で膨大な手間が掛かります。 特定のページに添付する方針になっている場合、個人の意見でそれを覆すのは非常に難しいと思われます。
自分も困っている側なので、代案や個人で対処可能な方法があれば教えていただきたいです。
それは運用方法に問題があると考えます。
以下、「本サービスに関する利用のルール」より引用
コンテンツ・広告の取り扱いに関する内容 記事に使用しない画像やファイルを大量にWIKIにアップロードして保管する行為は禁止です。 ファイルの保管にはGoogleドライブなどの便利な外部サービスをご利用ください。 ページ内に大量のYouTubeやXなどの外部サービスを埋め込む行為も禁止です。 これにより、サーバー負荷や閲覧体験の低下を招く可能性があります。 倉庫としての利用は、画像やファイルを保存するためだけの使用です。 一方、まとめ記事は情報を整理し、読者に有益な形で提供することを目的としています。WIKIはコンテンツ作成に使用されるべきものであり、 画像やファイルの保管庫としての使用は適していません。
正当な理由があるとはいえ、実質的に倉庫と同じような使われ方になってしまっていますので 大量の画像ファイルを1ページ内に添付するのは適切ではないと言えます。
従って、改善要望ではなく運用方法の見直しをするべきかと思います。
WebPよりもさらにファイルサイズを抑えられるため、wikiの軽量化に役立つと考えています。
単にファイルサイズを小さくするだけならJPEGでもWebPでもできますので、 画質を保ったまま圧縮率を大きくできるという意味だと思いますが、 現在のwikiwikiは、リミッターを超過した画像をWebPで再圧縮して表示していますので、 これに引っかかった場合、PNGだろうがWebPだろうがAVIFだろうが皆同じ画質になってしまうので、 AVIFが使えればより高画質になるという単純な話ではありません。
逆にAVIF→WebP変換で発生する負荷がマイナス要因となる可能性もあります。 （変換時の負荷の高さがAVIFのデメリットの一つとされています）
AVIFが既にメジャーな形式であり
そう断言する根拠は何でしょう？
少なくとも自分はそう思っていません。 画像関連のフリーソフトで対応済みなのは一部だけですし、 Windows 11のペイントも未対応な現状で「既にメジャー」は言い過ぎでしょう。 AVIFはロスレス圧縮にも対応していますので、本当にメジャーになれば、 JPEG、PNG程には普及していないWebPは事実上駆逐されると思います。
AVIFを解禁したからと言ってアニメーション画像の乱用が増えるとは思えません。
「AVIFに対応しても（アニメーション）利用者は増えないと思う」というのがあなたの主張ならば、 「需要もまだ限定的」という運営の判断と矛盾しません。 （実際、GIFアニメを積極的に使用しているWikiは少ないです） 逆に「自分も含め多くのユーザーが待ち望んでいる」との主張ならば、 運営の懸念をあなた自身が証明していることになります。
AVIF対応に反対する訳ではありませんが、（現時点では）判断が難しいのは想像に難くありません。 対応するのは簡単でも、一度採用したものを中止するのは簡単なことではないからです。 （最近のpopular(total)の廃止もそうですが、 そんなことを当たり前のようにされたら、利用者全員が迷惑を被ります）
AVIFはこれから普及が見込まれる画像形式です。 運営も「ニーズが明確になれば再検討する」と言っているのですから、 ニーズが明確になるのを（気長に）待ちましょう。
これってそもそもですがまだ事象が起きているということでしょうか？
AVIF方式のメリットとしてですが、WebPよりもさらにファイルサイズを抑えられるため、wikiの軽量化に役立つと考えています。 また、AVIFが既にメジャーな形式であり、非対応環境もほぼ無くなっている関係上、対応が望ましくなってくるラインを超えていると考えられます。 既に一部のサイトでは既にAVIFが導入されていることも確認済みですので、自分としては割と導入が望ましいような気がします。(無くても困らないと言えば困らないですが・・・)
どなたからも根拠が示されないので、需要を理由としている以上近々では変わらないかと思います。
この件に関して賛成も反対もしません（あってもなくても困りませんので）が、需要がある！という件に関しては私も懐疑的です。 閲覧者は「ただ情報を表示できれば良い」ので、原則として編集者側の都合になるのですが、その編集者側から何も出ないとなると。
なお、AVIF方式のメリットが圧倒的になれば、ここで言われなくても予告なく勝手に実装するかと思います。
これ進展ないですよね。機能削除のページ更新は早いのに、こういう不具合出てるのは一向に調査されてない。 運営も今何を調査してるのか、何を対応してるのか、どこかのページに出したらいいのに。 こんなにも放置され続けてたらユーザーからは何も動いていないとしか見えないし、実質動いてないんだろうけど。
VPNや比較的特殊な広告ブロッカーを使用しているならば外してみてください。
詳細リンクに記載されている以上の意味はありません。 設定が調整された結果、あなたのPCが使用している回線はアクセス禁止となっているのでしょう。 月曜日からであれば今回のCloudflareの障害は無関係です。
VPN等を外しているもしくは使用していない状況で、かつ他のどなたも異常がないということは、WIKIWIKI運営と個別相談になるかと思います。 実際不具合（設定見直しの結果余計な範囲までBANしている）なのかもしれませんが。
ネットワークの中継的な動きをしてたクラウドフレアが一応復旧して、ツイッターや各種のネットサービスが復活したわけですが、依然としてwikiwiki.jpのエラー1005は解消されておりません… ウェブサイトの所有者が、IPアドレスを含むASNからのアクセスを禁止した(拒否された)ってのが引っ掛かる…アクセスの制限にはクラウドフレアを使ってるらしいんだけど、そこの解法見るに送ったスクショを使ってサイトの所有者の方でID検索どうこうしろって書いてあるのよなぁ…
今日（11月18日）の午後9時前頃から、cloudflareで広範囲な障害が起きたことが原因のようです。 この障害が原因で、wikiwikiだけでなくさまざまなネットサービスで不具合が起きています。 お使いのパソコンの調子が悪いわけではありません。また、wikiwikiの運営さんサイドにも、非や責任は無いと思われます。
cloudflareが何なのかを知りたい場合は、「コンテンツデリバリネットワーク」で検索したりAIに聞いたりしてください。
Yahoo! JAPANアプリをご使用でしょうか？
投稿ログからご使用の端末情報を確認したところ、 Yahoo! JAPANアプリ（iOS版）からアクセスされていることが分かりました。
現在、Yahoo! JAPANアプリ内で表示される動画広告の一部で、 正しく再生されず「sync(file:///private/.../sync)」といった文字が表示される 事象が報告されています。
これは、アプリ内部の動画再生処理が一時ファイルの読み込みに失敗した際に、 一時的に内部パスが表示されてしまうもので、 Yahoo! JAPANアプリの不具合の可能性があります。
アプリ内で使用されている WebView（内蔵ブラウザ） は、 Safariなどの通常のブラウザと比べて更新が遅れることがあり、 不具合が修正されないまま残る場合があります。
公式の決定なんですね、、、よく見てませんでした。教えてくれてありがとうございます。
https://wikiwiki.jp/p/information/view?id=4
個人的には、このような仕様変更（改悪）はして欲しくなかったですが、 サーバーを提供する企業側が決めたことなので、 我々ユーザーは甘んじて受けざるを得ないでしょう。 （ホントに運営はどっち向いて仕事してるんですかねえ…）
現在は、&popular(表示件数,除外ページ,true/false)で、昨日・今日の人気が表示されます。
確認したところプライベートリレーはオフになってました。なので他の原因があるかもしれないです
参考になるかわかりませんが、apple製品を使っていて似たような事になっている人を原神wikiでも見かけました https://z.wikiwiki.jp/genshinwiki/topic/42/5621
@wikiwiki 1月半ほど現状の仕様で編集を行っていますが、やはり不便＆想定どおりの仕様かわからない、ということで再度トピックを上げさせてください。
画像内のURLからもわかるように、部分編集を行っている場面のスクリーンショットです。 このとき、編集前の状態（右部分）のに他の見出しも取り込まれてしまっています。 差分機能として、純粋に視認性が悪くなっているうえ、まるで更新すると他の見出しの内容を削除してしまうようにも感じられるため、見出し編集時の「編集前の状態」には、該当する見出しの現時点のソースコードを表示するように仕様を復元していただきたいです。
有向グラフとも言われるものですね フローチャートはもちろん、ゲームのエリア同士の繋がりや人物の関係を示す時にも便利そうです
いいですね。
自分は、チャート表をExcelで作成→PDF出力→スクリーンショットで切り出し→添付 という泥臭い方法でやりましたが、これならずっとスマートに作れるし、 表中に直接ページリンクも貼れそうです。
この機能は、ゲーム攻略でフローチャートを表示する場合など、 かなり需要がありそうな気がします。
こちら、twitter_timelineプラグインそのものが廃止されており機能しないので、事実上解消となっております。報告まで。 https://wikiwiki.jp/sample/TwitterTimeline
セキュリティ強化による確認画面についてに
と挙げられているので、検索という一見何気なく使う機能も
といった攻撃が想定されているか、実際に起きているのだと思われます いちいち確認画面が出る煩雑さは分かりますが、確認画面の出ない利便性と引き換えにサーバーが不安定になってしまうのも利便性が良くないので、難しい所なのではないかな……と思います
win11 edgeにて、ケース2の不具合は発生しましたがケース1は発生しませんでした やっぱりこの機能告知とかなかったんですね、見落としてるのかと思ってました…
この現象、Wikiwikiに限らず下位にCloudflareが絡んでいると起きるっぽい。 ※Win11のEdge(142.0.3595.41)にてWikiwikiとTrueAchievementsで発生
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の移転提案ではなく、別の誰かに管理権限を譲渡することです。
該当サイトに問い合わせてください。WIKIWIKI運営には何の関係もないサイトです。
コメントありがとうございます。
利用しているWikiのゲームの特性上、同じ画像を複数ページで使いまわしているような状況で、そうではない使い方になるとページごとに同じ画像を添付していくような形になってしまい、管理上問題が発生してしまいます。
※アイコンや画像、仕様などがアプデなどで頻繁に変わり、ページごとで最新の画像が使われたり使われなかったりが発生しました。
画像やファイルを保管するためだけの倉庫としては使っていません。
画像添付専用のページを作り、そこに大量の画像をアップして運用するというのは、
「そのWIKIでの特別な事情」に該当するのではと思います。
>> 2「ページ名指定が固定になって編集が楽」という意見ですが、
attachを使用すればページ名指定は不要ですし、
複数ページで同じ画像の使い回しを大量に行っているということであれば、
やはりそれも「そのWIKIでの特別な事情」に該当しそうです。
「複数のページにバラけさせるのは不便かつ煩雑」という意見も、
あまり一般的とは思えません。
私自身について言えば、同じ画像を複数ページで使い回すことは基本的にないため、
ページごとに使用画像を添付する方がシンプルで分かり易く、
むしろこちらが一般的でなないかと思います。
このように、どちらが使い易いと感じるかは個人の主観に左右される上、
「複数のページにバラけさせるのは不便」と言いつつ、
その運用で逆に不便が生じているからトピックを立てている訳で、
矛盾が生じています。
追加情報です。
本トピック投稿後、規制ユーザーを追加する機会が何回かありましたが、再現率は100％でした。
また、追加順ですが、下記の順に1つずつ追加される状況となっている模様です。
SMSトークン→ホスト→クッキー
起票よりそろそろ1ヶ月程度経過しますが、状況はどうなっているでしょうか？
管理者がこの不具合に気付いていないと、荒らし対策が十分に機能しない可能性が考えられます。可及的速やかな対応を望みます。
賛成です。
自動読み込み無し、最新○件まで表示(+もっと見る)、非表示や格納、などで負荷を軽減してほしいです。
添付ファイルの確認をするために添付ページを開くのは稀ですし、毎回全てを表示させる必要はありません。
ページ名指定が固定になって編集が楽なので、用途毎などで特定のページに纏めたほうが運用する上で都合が良いです。
1ページに纏まってるから倉庫(保管用途)のように見えるだけで、倉庫(運用用途)とは異なります。
纏めてもバラけさせてもwiki全体のファイル総量は変わりませんし、禁止しているのはあくまで保管用途です。
添付ページの表示負荷を軽減するためだけに、意図的に複数のページにバラけさせるのは不便かつ煩雑です。
現状特定のページに纏めているwikiで実行すると、再添付とリンク調整で膨大な手間が掛かります。
特定のページに添付する方針になっている場合、個人の意見でそれを覆すのは非常に難しいと思われます。
自分も困っている側なので、代案や個人で対処可能な方法があれば教えていただきたいです。
それは運用方法に問題があると考えます。
以下、「本サービスに関する利用のルール」より引用
正当な理由があるとはいえ、実質的に倉庫と同じような使われ方になってしまっていますので
大量の画像ファイルを1ページ内に添付するのは適切ではないと言えます。
従って、改善要望ではなく運用方法の見直しをするべきかと思います。
単にファイルサイズを小さくするだけならJPEGでもWebPでもできますので、
画質を保ったまま圧縮率を大きくできるという意味だと思いますが、
現在のwikiwikiは、リミッターを超過した画像をWebPで再圧縮して表示していますので、
これに引っかかった場合、PNGだろうがWebPだろうがAVIFだろうが皆同じ画質になってしまうので、
AVIFが使えればより高画質になるという単純な話ではありません。
逆にAVIF→WebP変換で発生する負荷がマイナス要因となる可能性もあります。
（変換時の負荷の高さがAVIFのデメリットの一つとされています）
そう断言する根拠は何でしょう？
少なくとも自分はそう思っていません。
画像関連のフリーソフトで対応済みなのは一部だけですし、
Windows 11のペイントも未対応な現状で「既にメジャー」は言い過ぎでしょう。
AVIFはロスレス圧縮にも対応していますので、本当にメジャーになれば、
JPEG、PNG程には普及していないWebPは事実上駆逐されると思います。
「AVIFに対応しても（アニメーション）利用者は増えないと思う」というのがあなたの主張ならば、
「需要もまだ限定的」という運営の判断と矛盾しません。
（実際、GIFアニメを積極的に使用しているWikiは少ないです）
逆に「自分も含め多くのユーザーが待ち望んでいる」との主張ならば、
運営の懸念をあなた自身が証明していることになります。
AVIF対応に反対する訳ではありませんが、（現時点では）判断が難しいのは想像に難くありません。
対応するのは簡単でも、一度採用したものを中止するのは簡単なことではないからです。
（最近のpopular(total)の廃止もそうですが、
そんなことを当たり前のようにされたら、利用者全員が迷惑を被ります）
AVIFはこれから普及が見込まれる画像形式です。
運営も「ニーズが明確になれば再検討する」と言っているのですから、
ニーズが明確になるのを（気長に）待ちましょう。
これってそもそもですがまだ事象が起きているということでしょうか？
AVIF方式のメリットとしてですが、WebPよりもさらにファイルサイズを抑えられるため、wikiの軽量化に役立つと考えています。
また、AVIFが既にメジャーな形式であり、非対応環境もほぼ無くなっている関係上、対応が望ましくなってくるラインを超えていると考えられます。
既に一部のサイトでは既にAVIFが導入されていることも確認済みですので、自分としては割と導入が望ましいような気がします。(無くても困らないと言えば困らないですが・・・)
どなたからも根拠が示されないので、需要を理由としている以上近々では変わらないかと思います。
この件に関して賛成も反対もしません（あってもなくても困りませんので）が、需要がある！という件に関しては私も懐疑的です。
閲覧者は「ただ情報を表示できれば良い」ので、原則として編集者側の都合になるのですが、その編集者側から何も出ないとなると。
なお、AVIF方式のメリットが圧倒的になれば、ここで言われなくても予告なく勝手に実装するかと思います。
これ進展ないですよね。機能削除のページ更新は早いのに、こういう不具合出てるのは一向に調査されてない。
運営も今何を調査してるのか、何を対応してるのか、どこかのページに出したらいいのに。
こんなにも放置され続けてたらユーザーからは何も動いていないとしか見えないし、実質動いてないんだろうけど。
VPNや比較的特殊な広告ブロッカーを使用しているならば外してみてください。
詳細リンクに記載されている以上の意味はありません。
設定が調整された結果、あなたのPCが使用している回線はアクセス禁止となっているのでしょう。
月曜日からであれば今回のCloudflareの障害は無関係です。
VPN等を外しているもしくは使用していない状況で、かつ他のどなたも異常がないということは、WIKIWIKI運営と個別相談になるかと思います。
実際不具合（設定見直しの結果余計な範囲までBANしている）なのかもしれませんが。
ネットワークの中継的な動きをしてたクラウドフレアが一応復旧して、ツイッターや各種のネットサービスが復活したわけですが、依然としてwikiwiki.jpのエラー1005は解消されておりません…
ウェブサイトの所有者が、IPアドレスを含むASNからのアクセスを禁止した(拒否された)ってのが引っ掛かる…アクセスの制限にはクラウドフレアを使ってるらしいんだけど、そこの解法見るに送ったスクショを使ってサイトの所有者の方でID検索どうこうしろって書いてあるのよなぁ…
今日（11月18日）の午後9時前頃から、cloudflareで広範囲な障害が起きたことが原因のようです。
この障害が原因で、wikiwikiだけでなくさまざまなネットサービスで不具合が起きています。
お使いのパソコンの調子が悪いわけではありません。また、wikiwikiの運営さんサイドにも、非や責任は無いと思われます。
cloudflareが何なのかを知りたい場合は、「コンテンツデリバリネットワーク」で検索したりAIに聞いたりしてください。
Yahoo! JAPANアプリをご使用でしょうか？
投稿ログからご使用の端末情報を確認したところ、
Yahoo! JAPANアプリ（iOS版）からアクセスされていることが分かりました。
現在、Yahoo! JAPANアプリ内で表示される動画広告の一部で、
正しく再生されず「sync(file:///private/.../sync)」といった文字が表示される
事象が報告されています。
これは、アプリ内部の動画再生処理が一時ファイルの読み込みに失敗した際に、
一時的に内部パスが表示されてしまうもので、
Yahoo! JAPANアプリの不具合の可能性があります。
アプリ内で使用されている WebView（内蔵ブラウザ） は、
Safariなどの通常のブラウザと比べて更新が遅れることがあり、
不具合が修正されないまま残る場合があります。
公式の決定なんですね、、、よく見てませんでした。教えてくれてありがとうございます。
https://wikiwiki.jp/p/information/view?id=4
個人的には、このような仕様変更（改悪）はして欲しくなかったですが、
サーバーを提供する企業側が決めたことなので、
我々ユーザーは甘んじて受けざるを得ないでしょう。
（ホントに運営はどっち向いて仕事してるんですかねえ…）
現在は、&popular(表示件数,除外ページ,true/false)で、昨日・今日の人気が表示されます。
確認したところプライベートリレーはオフになってました。なので他の原因があるかもしれないです
参考になるかわかりませんが、apple製品を使っていて似たような事になっている人を原神wikiでも見かけました
https://z.wikiwiki.jp/genshinwiki/topic/42/5621
@wikiwiki
1月半ほど現状の仕様で編集を行っていますが、やはり不便＆想定どおりの仕様かわからない、ということで再度トピックを上げさせてください。
画像内のURLからもわかるように、部分編集を行っている場面のスクリーンショットです。
このとき、編集前の状態（右部分）のに他の見出しも取り込まれてしまっています。
差分機能として、純粋に視認性が悪くなっているうえ、まるで更新すると他の見出しの内容を削除してしまうようにも感じられるため、見出し編集時の「編集前の状態」には、該当する見出しの現時点のソースコードを表示するように仕様を復元していただきたいです。
有向グラフとも言われるものですね
フローチャートはもちろん、ゲームのエリア同士の繋がりや人物の関係を示す時にも便利そうです
いいですね。
自分は、チャート表をExcelで作成→PDF出力→スクリーンショットで切り出し→添付
という泥臭い方法でやりましたが、これならずっとスマートに作れるし、
表中に直接ページリンクも貼れそうです。
この機能は、ゲーム攻略でフローチャートを表示する場合など、
かなり需要がありそうな気がします。
こちら、twitter_timelineプラグインそのものが廃止されており機能しないので、事実上解消となっております。報告まで。
https://wikiwiki.jp/sample/TwitterTimeline
セキュリティ強化による確認画面についてに
と挙げられているので、検索という一見何気なく使う機能も
といった攻撃が想定されているか、実際に起きているのだと思われます
いちいち確認画面が出る煩雑さは分かりますが、確認画面の出ない利便性と引き換えにサーバーが不安定になってしまうのも利便性が良くないので、難しい所なのではないかな……と思います
win11 edgeにて、ケース2の不具合は発生しましたがケース1は発生しませんでした
やっぱりこの機能告知とかなかったんですね、見落としてるのかと思ってました…
この現象、Wikiwikiに限らず下位にCloudflareが絡んでいると起きるっぽい。
※Win11のEdge(142.0.3595.41)にてWikiwikiとTrueAchievementsで発生
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の移転提案ではなく、別の誰かに管理権限を譲渡することです。