@wikiwiki
ご回答ありがとうございます。 「いま起きている問題の把握」に重きを置いているとのことですが、そうだとしても一定期間ごとの絞り込みは必要に感じます。 仮にごく短い期間(1日)を対象にしても、日付を跨いで荒らし行為が発生することもあり、たかが2日分とはいえ1日ごとに検索するのは非常に手間になります。 このような点からも、日付を跨いだ検索機能は実装を強く希望します。
各WIKIの「規制ルール」に登録された情報は、多いところで700〜1000件近くにのぼっていますが、その大半が「ヒット数ゼロ」のまま何年も残っているといった例も少なくありません
こちらについてですが、個人的には荒らし行為が発生したとき、IP、ホスト、Cookie...といったようにひとまず各情報を登録することが多いのではないかと考えています。このような場合、当該ユーザーが再度編集を試みてもある1つのルール(登録順が早いルール？)にヒットし、それ以外はヒットしないというケースが発生するのではないかと思いますし、こうして数年以上ヒットしないルールが存在しているように思えます。
返信が遅くなり申し訳ございません。
編集差分ログの検索機能についてですが、以前の「DIFFANA」ではカレンダーで期間を指定して広く検索できましたが、現在の「コントロールパネル」では、「いま起きている問題の把握」を優先した設計にしています。
というのも、IPアドレスやCookieといった揮発性の情報は、時間が経つと変わってしまうため、古い過去ログの情報を現在の投稿規制対応に活かしにくいケースが多いからです。 そもそもこうした情報は、長期的な追跡にはあまり向いておらず、現在のように直近の動きを素早く確認できることを重視した形にしています。
また、実際の運用状況を見ると、各WIKIの「規制ルール」に登録された情報は、多いところで700〜1000件近くにのぼっていますが、その大半が「ヒット数ゼロ」のまま何年も残っているといった例も少なくありません。 こうした現状からも、揮発性の情報による長期的な規制には限界があると考えており、直近の状況把握を重視した設計としています。
さらに、広範囲の検索を可能にすると、サーバーへの負荷も大きくなるため、あえて「その日ごとの確認」に絞ったシンプルな仕様としています。
もちろん、日をまたいで確認したいケースがあることは承知していますので、今回いただいたご意見は、今後の改善検討の参考にさせていただきます。
@wikiwiki 他ユーザーからも賛同いただけていますので、ご検討のほどよろしくお願いいたします。
しばらく経っても不具合が解消されない場合は、恐れ入りますが「リクエスト広場」までご報告いただけますと、早期対応につながります。ご協力いただけますと幸いです。 https://t.co/ToeQrfIT6E— WIKIWIKI（ウキウキ）【公式】 (@WIKIWIKI_Japan) May 3, 2025
しばらく経っても不具合が解消されない場合は、恐れ入りますが「リクエスト広場」までご報告いただけますと、早期対応につながります。ご協力いただけますと幸いです。 https://t.co/ToeQrfIT6E
一つひとつの操作はそれほど大したことがなくて些細なことでも積み重ねれば都度、繰り返していくうちに億劫に感じがちです。
賛成です。他社WikiサービスでもTOPページからお知らせページにアクセスできるようにしていたりして、誰もが気づくことができます。wikiwikiの利用者が他社SNSサービスを使うことに無料だからといって全員、抵抗がないことはないので運営会社のお知らせ方針について、考え直してほしいです。
各wikiサービス事業者のお知らせ
確かに、wikiwikiのアップデートやメンテナンスなどのニッチ情報をSNSで不特定相手に発信しても余り意味ないし、 （ユーザーはアカウント取って積極的にフォローしてくれってこと？） 自社にwikiとの連携も可能な掲示板サービスがある訳だし、 Xになってから問題だらけの外部サービスに依存し続けるより、 zawazawa（wikiwiki official）に発信先を一本化してくれた方がありがたいです。
それと01vさんや>> 2さん同様、自分もXは利用していないので、 01vさんが仰るようにログインしていないと事実上使い物にならなくなった（時系列順に表示されない等）Xはもう…
なので、自分も賛成に1票です。
同意します。
つい先日実装された管理者ログイン機能もX上で告知されていましたが、 >> 1のコメントにあるようにXを利用しないユーザはアナウンスに気づくことが困難と言えます。 (私もXを利用していないため、コントロールパネルを開こうとした際に初めて気づきました）
従いまして、X以外の媒体でも公式アナウンスを行っていただく必要性があるように感じられます。
アップデートや機能仕様の変更についての案内をzawazawaで行うことは賛成です。 理由としては私はx.comをやっておらず、そちらに何か書かれてもわからないからです。 従来はhttps://zawazawa.jp/wikiwiki/ がお知らせページだったと思いますが、現在ここはあまり使われてないようです。 https://x.com/WIKIWIKI_Japan 、このページは一覧がみれますが私には内容が見えません。 また掲載が日付順になってないため、いつ何が変わったのわかりません。ソートや検索もできません。
メンテや変更点の案内は、wikiwikiの管理人や編集をする一部に向けられるものだと思います。 x.comで不特定多数にアピールしても連絡の確実性は低いのではないでしょうか。 逆に自身のサイトにそれらの情報を掲載しないというのは本末転倒な気もします。
@wikiwiki 本トピックに似た2022年の要望にコメントしています。本トピックにも議論は出尽くしたと思われますので運営さんから回答をもらえたらと思います。
別トピックにて、運営は新たなテーブル構想を打ち出しておりますが、本要望も検討されているのかをお伺いしたいです。
この新しい仕組みでは、将来的に、SQLによるデータ抽出やページ切り替え、並び替え、グラフ表示といった処理にも対応できるような拡張性を持たせることも視野に入れています。
トピック閲覧者へ 別トピックにて、運営は新たなテーブル構想を打ち出しており、次のように回答しております。
以下、トピックに対する回答 賛成です。 あらゆる情報をデータベース化しているテーブルが肥大化するにつれ、従来のままではWiki利用者にとって使いづらくなっていきます。
現状はネットワーク負荷の分散の意味合いも込めて、一つのテーブルに纏めずに分離するしか方法はありません。
編集者目線で行列を取捨選択したテーブルではなく、私が2023年に提案したトピックのように利用者目線で選択したテーブルに出来るようにして欲しいです。
@wikiwiki 本トピックに限らず、テーブルに対する機能の拡張強化の要望がこれまでにも出ています。ご対応をお願いします。
フィルタリング機能を調べていてこちらのリクエストを発見したので、同じように追加を希望します。 現在wikiwikiで使えるテーブルソートだけでは、大きなテーブルで検索をかけるのが非常に厳しい状況です。 https://arknights.wikiru.jp/?★6 こちらのページのような、ソートとフィルターを同時に行えることの出来るTable_editプラグインの実装を考慮して頂けると助かります。
wikiwiki.jpの内容 テキスト量が大きいため、パフォーマンス悪化を防ぐために構文ハイライトモードをOFFにしました。 これに該当するページで再適用させる場合、「確認のOKを押す → 構文ハイライトモードをONに再設定 → 確認のOKを押す」といった作業が毎回必要になるため、とても煩わしいです。
構文ハイライトモード実装によってメリットも感じていますが、トピック主のように煩わしさも同時に感じています。
テキスト量の多いページは有無を言わせずに強制的にダイアログ表示することなく、構文ハイライトモードOFFにしてしまうのも一手かもしれません。その後、編集者が必要に応じて構文ハイライトモードをONに再設定して、ダイアログ表示の確認のOKを押すという感じにすると確認の手間を省略できて時間効率も良い感じになるのではないでしょうか。
>> 2さんと同じく、あまり必要性を感じられません。 無条件にONになってしまうと(初回はOFFだとしても)その時のデバイスの状態によって閲覧が難しくなってしまうリスクもあり、現在の仕様で問題無いかと思っています。 編集に関わる身としてそこまで切り替えに手間を感じませんが、しいていうなら警告メッセージのダイアログ表示は無くてもよいのではと思います(チェックボックス部分に警告メッセージが表記されていれば十分かと)。
「確認の表示を常に非表示にする」という機能については>> 2の方の考えに同意するため、賛成しかねます。
ただ、「構文ハイライトモードを常にONにする」機能については実装をしてほしいと考えます。 テキスト量が多い、ページの描画速度を上げたいなどの理由で編集中一時的に構文ハイライトをoffにしたとき、 次回他のページを編集する際に構文ハイライトがoffの状態から始まるのが煩わしいためです。 また、テキスト量が多いページを含む複数ページを一括で別タブに開いた場合も、テキスト量が多いページ以降に読み込まれたタブが全てハイライトoffになってしまうというケースも度々あります。 かなり限定的な場面での用途になるため、優先度は低いかと思いますが、ご検討をいただきたいです。
現在、回答にお時間をいただいておりますが、 もう少々お待ちいただけますと幸いです。🙇♂️
かつてはページを凍結しても投稿出来ましたが、 2020.04.01から仕様が変わり、投稿不可になりました。 凍結されたまま管理放棄されたWikiの荒らしコメントが削除不可になるのを防ぐためだそうです。 （運営に直接伺いました） 理由があっての仕様変更なので、貴方の要望は叶わないでしょう。
理由については何を言っているのかよくわかりませんが、 コメント欄に画像を入れるのは普通にできますよ。 （入力アシストツールの右から4番目のボタン＝クリップマーク）
ただ、写真提供？を目的にコメントページに画像アップするのは迷惑行為になりかねないのでやめた方が良いと思いますが。 コメント欄に「車両一覧に写真を追加したいので、管理者の方は凍結解除してください」と投稿するのが筋かと。
理由は、例えばそのサイトがバスの車両の一覧wikiだとすると、車両の写真が必要となります。また、嵐防止のため、凍結しているとなると、写真提供ができないため、コメント欄に画像を入れられるようにしていただきたいです。
2025/05/26メンテナンスで修正が確認できたためクローズします
賛成ですね。 やはり、仮に、荒らしに遭った際などに復旧または、荒らしに防止のためにサイト全体の編集制限をすると、管理人の編集もできなくなってしまうので、この機能があった方が良いと思いますので、@wikiwikiの方はこの機能を追加していただきたいと思っております。 どうぞよろしくお願いします🙏
「他社のレンタルWikiとひたすら同じ方向性を打ち出しても仕方ない」という意味では、現状のシンプルで分かりやすい(誰でもすぐ編集できる)方向性は十分に実績を築いていると思います。
でも
荒らし対策の半凍結運用ページ編集時、凍結解除〜即再凍結の流れが面倒 →凍結フラグの扱いが「編集に管理パスワード必須」になれば便利で助かる……
という管理者都合はちょっとあるかも。
Apple Musicを埋め込み形式で表示しようと「Embedプラグイン」と「embedが含まれたURL」の両方で試してみたのですが上手くいきませんでした。
大量のテキストを1ページに詰め込むのは、ページ負荷やソース可読性の観点から好ましい状態とは言えません。
メッセージが表示されるのは、そのような状況に対して注意を促す意図も含まれていると解釈していますので、それを変えてしまうのは賛成しかねます。
また、対策としてページ分割や部分編集を利用するなど運用で十分カバー可能なため、個人的には実装の必要性は感じられません。
議論されてませんが、コメントしていただけると助かります。@wikiwiki
wikiの規模によってページ特定が困難になるケースがある旨理解しました。 そういった状況では荒らし対応として一定の有用性はありそうです。
この点が致命的でwiki運営に支障をきたす恐れがあるということであれば 改善される可能性は高くなると思われますので、利用者数や荒らしの頻度など 現状を詳しく説明していただくのも良いと思います。
RecentChangesだと200件までしか残らないこともありページ数が多いwikiだと一日も持たず、差分ログも追うのが難しい(すぐに埋もれて見つからない)ケースも存在するため表示されると嬉しいということです。
「新規作成されたページ」としての情報は確かに記録されなくなりますが、更新されたページそのものは全て最終更新(RecentChanges)に記録されます。 基本的に管理者以外が履歴を残さず更新することはできません。 また、対象のページが荒らしによって作成された「不要なページ」かどうかは差分などからも判別することが可能です。
従って、提示されている要望は現状の仕様や運用で十分カバーできる内容かと思います。
こちらのスレッドに参考になる意見が多数出てきたため、アカウントシステムをこれらの意見を参考に実装して下さると助かります。 一通り意見も出揃いましたので、運営からのコメントをお願いします。@wikiwiki
ご確認ありがとうございます。
こちらの環境では、想定どおりのincludexの取り込みになっていることを確認いたしました。 ご対応ありがとうございました。
特に要望することがないのですが、当Wikiでは扱う作品が非常に多いです。SNS上でよく言われるのが、作品数が多くてどの作品を遊ぶか迷うという意見です。管理者としてでなく、利用者が次のプレイしたい作品を求めて気になる/興味があるテーマを探しやすくするために、タグ一覧の表示が欲しいと願っています。そのため、分割して全件表示するなど何らかの手段で全件表示をお願いしたいです。
#tagcloud(cloud=off) のような、タグに対するページ一覧がその場で表示されない形が負担が少なくて望ましいです。
#tagcloud(cloud=off)
現在はページ一覧がその場で表示される #taglist(linkstr=title) で代用しています。
#taglist(linkstr=title)
さらに、添付ファイルのバックアップに「このバックアップを復元します。」という操作を追加しました。 これは、万が一画像削除などの荒らし行為があった場合でも、復旧を容易にするための措置です。 （既存のファイルは上書きします）
この機能は、上記の「添付ファイルの投稿者による完全削除」のご要望とはやや逆の方向性となりますが、誰でも編集できるWIKIという仕組みの中でのパワーバランスを考慮した対応となります。
なお、attach 操作まわりのUIについては、今後の改善に向けて検討を進めてまいります。
>> 4ご対応、誠にありがとうございました🙏🙏🙏 当Wikiはページ数とそれに対応したzawazawaトピックが非常に多いためhttp接続のリンクをhttps接続に修正するのは簡単ではありませんが、追々対応できるよう善処いたします。 毎度、Wiki運営様には大変お世話になっております。今後とも、何卒よろしくお願いいたします。
副作用として確認されていた点については修正済みです。 ご確認いただき、問題が解消されているかどうかコメントいただけますと助かります。
当該不具合につきましては、修正対応が完了いたしました。
今後もしばらく状況を注視してまいります。 このたびは大変ご迷惑をおかけいたしました。
確認用URL： http://wikiwiki.jp/warthunder/?Sea Hurricane Mk.IC#h2_content_1_18
なお、上記のURLは http 接続であり、ページ名が ? 以降に含まれる旧形式のものとなっております。 セキュリティの観点からも、https 接続かつ新しいURL形式への置き換えを推奨いたします。
http
?
できるだけ編集者に寄り添ってご配慮・ご対応いただき、ありがとうございます。
こちらでも記載どおり、エンコードされずに貼り付けることができたことを確認しました。また、iOS・端末の仕様変更によって不具合が再発する可能性についても了解いたしました。
不具合が再発した時は以前、伺ったようにメモ帳アプリなどを介してから貼り付けるようにいたします。
今回、iOSモバイル端末で発生していたコピーの不具合は、iOS側の仕様や挙動によるものと考えられますが、旧ブラウザ向けの特殊対応のように、例外的にレガシーコードを加えることで、ひとまず回避できるようにしています。 本来であればこうした対応は避けたいところですが、ご利用状況を踏まえ、現時点で可能な対応として実施しました。
現在はiOS端末でコピー・貼り付けが問題なく動作することを確認していますが、 この対応はiOSの仕様に依存しているため、今後のアップデート次第では、再び不具合が起こる可能性もあります。
投稿内容と履歴をもとに、短縮URLが使われているWIKI（MenuBar）を調査しました。
ご指摘の現象について
MenuBarで使用されている短縮URLは、現在、システム内部で自動的に正規URLへ変換される仕様となっています。 この変換は見た目にはわからず、URL表示自体は従来と変わりません。
この処理により、短縮URLの末尾に付いていたアンカー（例：#section1）が変換時に除かれ、指定した位置へ移動できなくなる現象が発生しています。
アンカーリンクについて
アンカーリンクは、ブラウザ側で処理されるものであり、サーバーには送信されません。 そのため、サーバー側でURLをリダイレクトする際にアンカーを保持・引き継ぐことはできません。
また、WIKIWIKIが提供している短縮URLは、ページ単位のURLを対象としており、アンカー（#〜）は含まれない仕様です。(アンカー付きの短縮URLは動作保証の対象外となります)
仕様変更の背景について
この仕様変更は、同一WIKI内で短縮URLが大量に使用されていたことで、アクセスのたびにリダイレクトが発生し、リクエスト数が増加していた状況を改善するために行ったものです。
現在は、同一サイト内の短縮URLはすべて内部的に正規URLへ変換されるようになっています。
アンカー付きの短縮URLについても、正規URLへの変換時に引き継ぐかどうかを検討しましたが、本来の用途を踏まえ、対応は行わない方針といたしました。
短縮URLの使用について
短縮URLは、もともと外部サイトでの一時的な共有などを想定した機能です。 そのため、WIKI内の記事やMenuBarなどでの使用はご遠慮いただきますようお願いいたします。
当該WIKIの短縮URLは、ページ容量の軽量化を意識して使用されていたものと見受けられますが、現在は正規URLに自動変換されるため、サイズ削減の効果はありません。
また、当該WIKIでは lazy_fold をご利用中のため、短縮URLを使わなくてもページ容量は十分に抑えられています。
lazy_fold
問題②について他サイトにて、同事象の再現を確認いたしました。iOS・端末側の仕様変更によるものと確認いたしました。ご対応ありがとうございます。
@wikiwiki
ご回答ありがとうございます。
「いま起きている問題の把握」に重きを置いているとのことですが、そうだとしても一定期間ごとの絞り込みは必要に感じます。
仮にごく短い期間(1日)を対象にしても、日付を跨いで荒らし行為が発生することもあり、たかが2日分とはいえ1日ごとに検索するのは非常に手間になります。
このような点からも、日付を跨いだ検索機能は実装を強く希望します。
こちらについてですが、個人的には荒らし行為が発生したとき、IP、ホスト、Cookie...といったようにひとまず各情報を登録することが多いのではないかと考えています。このような場合、当該ユーザーが再度編集を試みてもある1つのルール(登録順が早いルール？)にヒットし、それ以外はヒットしないというケースが発生するのではないかと思いますし、こうして数年以上ヒットしないルールが存在しているように思えます。
返信が遅くなり申し訳ございません。
編集差分ログの検索機能についてですが、以前の「DIFFANA」ではカレンダーで期間を指定して広く検索できましたが、現在の「コントロールパネル」では、「いま起きている問題の把握」を優先した設計にしています。
というのも、IPアドレスやCookieといった揮発性の情報は、時間が経つと変わってしまうため、古い過去ログの情報を現在の投稿規制対応に活かしにくいケースが多いからです。
そもそもこうした情報は、長期的な追跡にはあまり向いておらず、現在のように直近の動きを素早く確認できることを重視した形にしています。
また、実際の運用状況を見ると、各WIKIの「規制ルール」に登録された情報は、多いところで700〜1000件近くにのぼっていますが、その大半が「ヒット数ゼロ」のまま何年も残っているといった例も少なくありません。
こうした現状からも、揮発性の情報による長期的な規制には限界があると考えており、直近の状況把握を重視した設計としています。
さらに、広範囲の検索を可能にすると、サーバーへの負荷も大きくなるため、あえて「その日ごとの確認」に絞ったシンプルな仕様としています。
もちろん、日をまたいで確認したいケースがあることは承知していますので、今回いただいたご意見は、今後の改善検討の参考にさせていただきます。
@wikiwiki
他ユーザーからも賛同いただけていますので、ご検討のほどよろしくお願いいたします。
お知らせページが存在すれば、その場で利用者が気づいた点や不具合はフィードバックできます。zawazawaならメンション機能を使えます。現状だと利用者が利用サービスを変えてアクセスしないといけないので手間がかかります。PCならブラウザ内で完結しますがタブ移動は必要です。モバイル端末ではXアプリからブラウザに切替してタブ移動をする必要があります。モバイル端末を使ってブラウザ上でXを閲覧している人も限られているかと思います。また、Xにログインしないとユーザーが過去に発した投稿を検索することもできない不都合があります。
一つひとつの操作はそれほど大したことがなくて些細なことでも積み重ねれば都度、繰り返していくうちに億劫に感じがちです。
賛成です。他社WikiサービスでもTOPページからお知らせページにアクセスできるようにしていたりして、誰もが気づくことができます。wikiwikiの利用者が他社SNSサービスを使うことに無料だからといって全員、抵抗がないことはないので運営会社のお知らせ方針について、考え直してほしいです。
各wikiサービス事業者のお知らせ
確かに、wikiwikiのアップデートやメンテナンスなどのニッチ情報をSNSで不特定相手に発信しても余り意味ないし、
（ユーザーはアカウント取って積極的にフォローしてくれってこと？）
自社にwikiとの連携も可能な掲示板サービスがある訳だし、
Xになってから問題だらけの外部サービスに依存し続けるより、
zawazawa（wikiwiki official）に発信先を一本化してくれた方がありがたいです。
それと01vさんや>> 2さん同様、自分もXは利用していないので、
01vさんが仰るようにログインしていないと事実上使い物にならなくなった（時系列順に表示されない等）Xはもう…
なので、自分も賛成に1票です。
同意します。
つい先日実装された管理者ログイン機能もX上で告知されていましたが、
>> 1のコメントにあるようにXを利用しないユーザはアナウンスに気づくことが困難と言えます。
(私もXを利用していないため、コントロールパネルを開こうとした際に初めて気づきました）
従いまして、X以外の媒体でも公式アナウンスを行っていただく必要性があるように感じられます。
アップデートや機能仕様の変更についての案内をzawazawaで行うことは賛成です。
理由としては私はx.comをやっておらず、そちらに何か書かれてもわからないからです。
従来はhttps://zawazawa.jp/wikiwiki/ がお知らせページだったと思いますが、現在ここはあまり使われてないようです。
https://x.com/WIKIWIKI_Japan 、このページは一覧がみれますが私には内容が見えません。
また掲載が日付順になってないため、いつ何が変わったのわかりません。ソートや検索もできません。
メンテや変更点の案内は、wikiwikiの管理人や編集をする一部に向けられるものだと思います。
x.comで不特定多数にアピールしても連絡の確実性は低いのではないでしょうか。
逆に自身のサイトにそれらの情報を掲載しないというのは本末転倒な気もします。
@wikiwiki
本トピックに似た2022年の要望にコメントしています。本トピックにも議論は出尽くしたと思われますので運営さんから回答をもらえたらと思います。
別トピックにて、運営は新たなテーブル構想を打ち出しておりますが、本要望も検討されているのかをお伺いしたいです。
トピック閲覧者へ
別トピックにて、運営は新たなテーブル構想を打ち出しており、次のように回答しております。
以下、トピックに対する回答
賛成です。
あらゆる情報をデータベース化しているテーブルが肥大化するにつれ、従来のままではWiki利用者にとって使いづらくなっていきます。
現状はネットワーク負荷の分散の意味合いも込めて、一つのテーブルに纏めずに分離するしか方法はありません。
編集者目線で行列を取捨選択したテーブルではなく、私が2023年に提案したトピックのように利用者目線で選択したテーブルに出来るようにして欲しいです。
@wikiwiki
本トピックに限らず、テーブルに対する機能の拡張強化の要望がこれまでにも出ています。ご対応をお願いします。
フィルタリング機能を調べていてこちらのリクエストを発見したので、同じように追加を希望します。
現在wikiwikiで使えるテーブルソートだけでは、大きなテーブルで検索をかけるのが非常に厳しい状況です。
https://arknights.wikiru.jp/?★6
こちらのページのような、ソートとフィルターを同時に行えることの出来るTable_editプラグインの実装を考慮して頂けると助かります。
構文ハイライトモード実装によってメリットも感じていますが、トピック主のように煩わしさも同時に感じています。
テキスト量の多いページは有無を言わせずに強制的にダイアログ表示することなく、構文ハイライトモードOFFにしてしまうのも一手かもしれません。その後、編集者が必要に応じて構文ハイライトモードをONに再設定して、ダイアログ表示の確認のOKを押すという感じにすると確認の手間を省略できて時間効率も良い感じになるのではないでしょうか。
>> 2さんと同じく、あまり必要性を感じられません。
無条件にONになってしまうと(初回はOFFだとしても)その時のデバイスの状態によって閲覧が難しくなってしまうリスクもあり、現在の仕様で問題無いかと思っています。
編集に関わる身としてそこまで切り替えに手間を感じませんが、しいていうなら警告メッセージのダイアログ表示は無くてもよいのではと思います(チェックボックス部分に警告メッセージが表記されていれば十分かと)。
「確認の表示を常に非表示にする」という機能については>> 2の方の考えに同意するため、賛成しかねます。
ただ、「構文ハイライトモードを常にONにする」機能については実装をしてほしいと考えます。
テキスト量が多い、ページの描画速度を上げたいなどの理由で編集中一時的に構文ハイライトをoffにしたとき、
次回他のページを編集する際に構文ハイライトがoffの状態から始まるのが煩わしいためです。
また、テキスト量が多いページを含む複数ページを一括で別タブに開いた場合も、テキスト量が多いページ以降に読み込まれたタブが全てハイライトoffになってしまうというケースも度々あります。
かなり限定的な場面での用途になるため、優先度は低いかと思いますが、ご検討をいただきたいです。
現在、回答にお時間をいただいておりますが、
もう少々お待ちいただけますと幸いです。🙇♂️
かつてはページを凍結しても投稿出来ましたが、
2020.04.01から仕様が変わり、投稿不可になりました。
凍結されたまま管理放棄されたWikiの荒らしコメントが削除不可になるのを防ぐためだそうです。
（運営に直接伺いました）
理由があっての仕様変更なので、貴方の要望は叶わないでしょう。
理由については何を言っているのかよくわかりませんが、
コメント欄に画像を入れるのは普通にできますよ。
（入力アシストツールの右から4番目のボタン＝クリップマーク）
ただ、写真提供？を目的にコメントページに画像アップするのは迷惑行為になりかねないのでやめた方が良いと思いますが。
コメント欄に「車両一覧に写真を追加したいので、管理者の方は凍結解除してください」と投稿するのが筋かと。
理由は、例えばそのサイトがバスの車両の一覧wikiだとすると、車両の写真が必要となります。また、嵐防止のため、凍結しているとなると、写真提供ができないため、コメント欄に画像を入れられるようにしていただきたいです。
2025/05/26メンテナンスで修正が確認できたためクローズします
賛成ですね。
やはり、仮に、荒らしに遭った際などに復旧または、荒らしに防止のためにサイト全体の編集制限をすると、管理人の編集もできなくなってしまうので、この機能があった方が良いと思いますので、@wikiwikiの方はこの機能を追加していただきたいと思っております。
どうぞよろしくお願いします🙏
「他社のレンタルWikiとひたすら同じ方向性を打ち出しても仕方ない」という意味では、現状のシンプルで分かりやすい(誰でもすぐ編集できる)方向性は十分に実績を築いていると思います。
でも
荒らし対策の半凍結運用ページ編集時、凍結解除〜即再凍結の流れが面倒
→凍結フラグの扱いが「編集に管理パスワード必須」になれば便利で助かる……
という管理者都合はちょっとあるかも。
Apple Musicを埋め込み形式で表示しようと「Embedプラグイン」と「embedが含まれたURL」の両方で試してみたのですが上手くいきませんでした。
大量のテキストを1ページに詰め込むのは、ページ負荷やソース可読性の観点から好ましい状態とは言えません。
メッセージが表示されるのは、そのような状況に対して注意を促す意図も含まれていると解釈していますので、それを変えてしまうのは賛成しかねます。
また、対策としてページ分割や部分編集を利用するなど運用で十分カバー可能なため、個人的には実装の必要性は感じられません。
議論されてませんが、コメントしていただけると助かります。@wikiwiki
wikiの規模によってページ特定が困難になるケースがある旨理解しました。
そういった状況では荒らし対応として一定の有用性はありそうです。
この点が致命的でwiki運営に支障をきたす恐れがあるということであれば
改善される可能性は高くなると思われますので、利用者数や荒らしの頻度など
現状を詳しく説明していただくのも良いと思います。
RecentChangesだと200件までしか残らないこともありページ数が多いwikiだと一日も持たず、差分ログも追うのが難しい(すぐに埋もれて見つからない)ケースも存在するため表示されると嬉しいということです。
「新規作成されたページ」としての情報は確かに記録されなくなりますが、更新されたページそのものは全て最終更新(RecentChanges)に記録されます。
基本的に管理者以外が履歴を残さず更新することはできません。
また、対象のページが荒らしによって作成された「不要なページ」かどうかは差分などからも判別することが可能です。
従って、提示されている要望は現状の仕様や運用で十分カバーできる内容かと思います。
こちらのスレッドに参考になる意見が多数出てきたため、アカウントシステムをこれらの意見を参考に実装して下さると助かります。
一通り意見も出揃いましたので、運営からのコメントをお願いします。@wikiwiki
ご確認ありがとうございます。
こちらの環境では、想定どおりのincludexの取り込みになっていることを確認いたしました。
ご対応ありがとうございました。
特に要望することがないのですが、当Wikiでは扱う作品が非常に多いです。SNS上でよく言われるのが、作品数が多くてどの作品を遊ぶか迷うという意見です。管理者としてでなく、利用者が次のプレイしたい作品を求めて気になる/興味があるテーマを探しやすくするために、タグ一覧の表示が欲しいと願っています。そのため、分割して全件表示するなど何らかの手段で全件表示をお願いしたいです。
#tagcloud(cloud=off)のような、タグに対するページ一覧がその場で表示されない形が負担が少なくて望ましいです。
現在はページ一覧がその場で表示される
#taglist(linkstr=title)で代用しています。
さらに、添付ファイルのバックアップに「このバックアップを復元します。」という操作を追加しました。
これは、万が一画像削除などの荒らし行為があった場合でも、復旧を容易にするための措置です。
（既存のファイルは上書きします）
この機能は、上記の「添付ファイルの投稿者による完全削除」のご要望とはやや逆の方向性となりますが、誰でも編集できるWIKIという仕組みの中でのパワーバランスを考慮した対応となります。
なお、attach 操作まわりのUIについては、今後の改善に向けて検討を進めてまいります。
>> 4ご対応、誠にありがとうございました🙏🙏🙏
当Wikiはページ数とそれに対応したzawazawaトピックが非常に多いためhttp接続のリンクをhttps接続に修正するのは簡単ではありませんが、追々対応できるよう善処いたします。
毎度、Wiki運営様には大変お世話になっております。今後とも、何卒よろしくお願いいたします。
副作用として確認されていた点については修正済みです。
ご確認いただき、問題が解消されているかどうかコメントいただけますと助かります。
当該不具合につきましては、修正対応が完了いたしました。
今後もしばらく状況を注視してまいります。
このたびは大変ご迷惑をおかけいたしました。
確認用URL：
http://wikiwiki.jp/warthunder/?Sea Hurricane Mk.IC#h2_content_1_18
なお、上記のURLは
http接続であり、ページ名が?以降に含まれる旧形式のものとなっております。セキュリティの観点からも、https 接続かつ新しいURL形式への置き換えを推奨いたします。
できるだけ編集者に寄り添ってご配慮・ご対応いただき、ありがとうございます。
こちらでも記載どおり、エンコードされずに貼り付けることができたことを確認しました。また、iOS・端末の仕様変更によって不具合が再発する可能性についても了解いたしました。
不具合が再発した時は以前、伺ったようにメモ帳アプリなどを介してから貼り付けるようにいたします。
今回、iOSモバイル端末で発生していたコピーの不具合は、iOS側の仕様や挙動によるものと考えられますが、旧ブラウザ向けの特殊対応のように、例外的にレガシーコードを加えることで、ひとまず回避できるようにしています。
本来であればこうした対応は避けたいところですが、ご利用状況を踏まえ、現時点で可能な対応として実施しました。
現在はiOS端末でコピー・貼り付けが問題なく動作することを確認していますが、
この対応はiOSの仕様に依存しているため、今後のアップデート次第では、再び不具合が起こる可能性もあります。
ご確認ありがとうございます。
投稿内容と履歴をもとに、短縮URLが使われているWIKI（MenuBar）を調査しました。
ご指摘の現象について
MenuBarで使用されている短縮URLは、現在、システム内部で自動的に正規URLへ変換される仕様となっています。
この変換は見た目にはわからず、URL表示自体は従来と変わりません。
この処理により、短縮URLの末尾に付いていたアンカー（例：#section1）が変換時に除かれ、指定した位置へ移動できなくなる現象が発生しています。
アンカーリンクについて
アンカーリンクは、ブラウザ側で処理されるものであり、サーバーには送信されません。
そのため、サーバー側でURLをリダイレクトする際にアンカーを保持・引き継ぐことはできません。
また、WIKIWIKIが提供している短縮URLは、ページ単位のURLを対象としており、アンカー（#〜）は含まれない仕様です。(アンカー付きの短縮URLは動作保証の対象外となります)
仕様変更の背景について
この仕様変更は、同一WIKI内で短縮URLが大量に使用されていたことで、アクセスのたびにリダイレクトが発生し、リクエスト数が増加していた状況を改善するために行ったものです。
現在は、同一サイト内の短縮URLはすべて内部的に正規URLへ変換されるようになっています。
アンカー付きの短縮URLについても、正規URLへの変換時に引き継ぐかどうかを検討しましたが、本来の用途を踏まえ、対応は行わない方針といたしました。
短縮URLの使用について
短縮URLは、もともと外部サイトでの一時的な共有などを想定した機能です。
そのため、WIKI内の記事やMenuBarなどでの使用はご遠慮いただきますようお願いいたします。
当該WIKIの短縮URLは、ページ容量の軽量化を意識して使用されていたものと見受けられますが、現在は正規URLに自動変換されるため、サイズ削減の効果はありません。
また、当該WIKIでは
lazy_foldをご利用中のため、短縮URLを使わなくてもページ容量は十分に抑えられています。問題②について他サイトにて、同事象の再現を確認いたしました。iOS・端末側の仕様変更によるものと確認いたしました。ご対応ありがとうございます。