#を外して記述してプラグインとして殺せば期待通りの結果が得られるのですか。 inculdexのオプションがあると動作がちがうのですか。exceptのcounter抜いてみたらどうなりま すか。
#
おっしゃる通り、exceptのcounterを抜いてから、想定している挙動になりました。どうもありがとうございます。自身の検証では指摘内容に気づけませんでした。includexがexceptに合致した行は、無視してカウントする仕様だとは思わずに不具合を疑っていました。
不具合を疑うことになった記述内容 #includex(MenuBar,num=14:,except=_now|counter,titlestr=off) 今回の場合、exceptに合致する行が3行あるので実際に表示させたい参照先の指定行が17行目であっても、14行目にするのが正しい
#includex(MenuBar,num=14:,except=_now|counter,titlestr=off)
参照先にaccordionプラグインでincludexプラグインの行を括ると正しく参照しなくなります。
#を外して記述してプラグインとして殺せば期待通りの結果が得られるのですか。 inculdexのオプションがあると動作がちがうのですか。exceptのcounter抜いてみたらどうなりますか。 機能を疑うなら検討用のページを作って、シンプルな記述にして検証してみてください。
Steamはメジャーなサービスであるとは言え、基本的にはPCゲーム用の限定的なプラットフォームです。 専用プラグインがあるYoutubeやX(Twitter)はSNSサービスであり、どのWIKIでも汎用的に扱うことができますが、 Steamの場合は限定的な用途となってしまい汎用性に欠けると言わざるを得ません。
要望に関して反対はしませんが、個人的には導入された際のメリットがそれほどあるように思えず、 上記の点も考慮すると実装される見込みは薄いのではないかと思います。
編集差分ログを期間指定でcsvファイルとしてダウンロードできるようにすればいいのではないでしょうか。 ただし、ページ内容を除いた情報のみ。 個人的にはそこまで困ってないので、改善するならという意見です。
ローカル環境のエディターやスプレッドシートで解析する分にはサーバー側の負担はないでしょう。 サーバーで準備された限定的な検索サービスより、スプレッドシートのほうが自由度が高く、統計処理、加工、保存できるので利便性があります。 現状だとIPアドレスなど転記して整理してから処置を検討することになるわけで、そういった工程の削減にもなります。 規制ルール作るにしても荒らし以外の巻き込みも気になるので、全書き込み情報から事前のシミュレーションができます。 ローカル処理で必要なdiffを絞り込めるなら、サーバー側を無駄に叩かれる機会も減るかもしれません。 機能にアクセスできるのは管理者だけなので実行負荷は限定的でしょう。多くても月1回の定期ダウロードか、緊急対応で数日中のログが取れればいいでしょう。
吐き出す内容についてはページ本文を除いた情報でいいと思います。本文は情報量が予想できないので。 csvの各行に当該diffページURL(view?did=日時)を記述すれば、必要に応じてそのページに飛んで内容は確認できます。
@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・端末の仕様変更によって不具合が再発する可能性についても了解いたしました。
不具合が再発した時は以前、伺ったようにメモ帳アプリなどを介してから貼り付けるようにいたします。
おっしゃる通り、exceptのcounterを抜いてから、想定している挙動になりました。どうもありがとうございます。自身の検証では指摘内容に気づけませんでした。includexがexceptに合致した行は、無視してカウントする仕様だとは思わずに不具合を疑っていました。
不具合を疑うことになった記述内容
#includex(MenuBar,num=14:,except=_now|counter,titlestr=off)今回の場合、exceptに合致する行が3行あるので実際に表示させたい参照先の指定行が17行目であっても、14行目にするのが正しい
#を外して記述してプラグインとして殺せば期待通りの結果が得られるのですか。
inculdexのオプションがあると動作がちがうのですか。exceptのcounter抜いてみたらどうなりますか。
機能を疑うなら検討用のページを作って、シンプルな記述にして検証してみてください。
Steamはメジャーなサービスであるとは言え、基本的にはPCゲーム用の限定的なプラットフォームです。
専用プラグインがあるYoutubeやX(Twitter)はSNSサービスであり、どのWIKIでも汎用的に扱うことができますが、
Steamの場合は限定的な用途となってしまい汎用性に欠けると言わざるを得ません。
要望に関して反対はしませんが、個人的には導入された際のメリットがそれほどあるように思えず、
上記の点も考慮すると実装される見込みは薄いのではないかと思います。
編集差分ログを期間指定でcsvファイルとしてダウンロードできるようにすればいいのではないでしょうか。
ただし、ページ内容を除いた情報のみ。
個人的にはそこまで困ってないので、改善するならという意見です。
ローカル環境のエディターやスプレッドシートで解析する分にはサーバー側の負担はないでしょう。
サーバーで準備された限定的な検索サービスより、スプレッドシートのほうが自由度が高く、統計処理、加工、保存できるので利便性があります。
現状だとIPアドレスなど転記して整理してから処置を検討することになるわけで、そういった工程の削減にもなります。
規制ルール作るにしても荒らし以外の巻き込みも気になるので、全書き込み情報から事前のシミュレーションができます。
ローカル処理で必要なdiffを絞り込めるなら、サーバー側を無駄に叩かれる機会も減るかもしれません。
機能にアクセスできるのは管理者だけなので実行負荷は限定的でしょう。多くても月1回の定期ダウロードか、緊急対応で数日中のログが取れればいいでしょう。
吐き出す内容についてはページ本文を除いた情報でいいと思います。本文は情報量が予想できないので。
csvの各行に当該diffページURL(view?did=日時)を記述すれば、必要に応じてそのページに飛んで内容は確認できます。
@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・端末の仕様変更によって不具合が再発する可能性についても了解いたしました。
不具合が再発した時は以前、伺ったようにメモ帳アプリなどを介してから貼り付けるようにいたします。