アップデートや機能仕様の変更についての案内を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・端末側の仕様変更によるものと確認いたしました。ご対応ありがとうございます。
#includex のコンテンツ切り出しロジックを改修いたしました。 お手数をおかけしますが、想定どおりの動作になっているか、ご確認をお願いいたします。
#includex
なお、この改修に伴う副作用についても認識しており、現在対応を進めております。 内容によっては、仕様として取り扱わせていただく可能性もございます。
ご連絡ありがとうございます。
旧URLのリダイレクトに関する不具合につきましては、現在調査を進めております。 恐れ入りますが、今しばらくお待ちいただけますようお願いいたします。
ご迷惑をおかけして申し訳ありません。
クッションページの不具合につきましては、すでに対応が完了しております。 ご迷惑をおかけして申し訳ありません。
問題②につきましては、端末の仕様による現象と思われます。 他のサイトやSNSでも同様の動作が見られるか、お試しいただけますでしょうか。
ご確認のほど、よろしくお願いいたします。
https://zawazawa.jp/warthunder/topic/3162/20582 のユーザーです。リアルタイムで状況調査をしていたので、その変遷について補足させていただきます。
元々の挙動：/?（ページ名）であっても正常にそのページへリダイレクトされていた
メンテナンス直後：/?（ページ名）となっているページ全てにおいてリンクを踏むとトップページが表示されていた
5月12日16時20分ごろ以降～5月13日4時現在：/?（ページ名）のうち、ページ名にスペースを含まないページは正常に表示されるが、スペースを含む場合にアドレス上で本来は%20となるところが_になりリンク切れを起こす。
という感じで二段階に推移していました。
問題①については解決したことを確認しました。問題②については未解決のままです。Googleアプリ自体は5年前にインストールしていたものです。今まではこのようなリンクの開き方ではありませんでしたが、iOSアップデートによって今までの不具合のようにiOS固有の問題である可能性も否めません。以前に使っていたiPhone6plusからでも外部リンクを押すと、Googleアプリが起動するようになってしまいました。
当Wikiユーザーが観測していた不具合の報告は下記の通りです。 https://zawazawa.jp/warthunder/topic/3162/20570
当Wiki編集者・管理者による報告は下記の通りです。 https://zawazawa.jp/warthunder/topic/100/4579 「?混入かつページ名に半角スペースが入っている場合半角スペースがアンダーバー判定に化けて正しくリダイレクトされない」と報告されています。
当Wikiのセール情報ページにて、以前から機能していた外部リンクで以下の問題が起きています。
問題① https://play.google.com/store/apps/collection/cluster?clp=igM4ChkKEzc3MTA2Mzc3Nzc5MDQ4MjUyODAQCBgDEhkKEzc3MTA2Mzc3Nzc5MDQ4MjUyODAQCBgDGAA=:S:ANO1ljIY_k8&gsr=CjuKAzgKGQoTNzcxMDYzNzc3NzkwNDgyNTI4MBAIGAMSGQoTNzcxMDYzNzc3NzkwNDgyNTI4MBAIGAMYAA==:S:ANO1ljIFxlk の外部リンクで、 &gsr=CjuKAzgKGQoTNzcxMDYzNzc3NzkwNDgyNTI4MBAIGAMSGQoTNzcxMDYzNzc3NzkwNDgyNTI4MBAIGAMYAA%3D%3D:S:ANO1ljIFxlk の部分が省略されてしまう。そのため、アクセス不能に見える。実際には正しくURLを貼り付けるとアクセスできる。
https://store.steampowered.com/search/?sort_by=Price_ASC&developer=Kairosoft Co.,Ltd の&developer=Kairosoft+Co.%2CLtd の部分が省略されてしまう。そのため、意図しないページにアクセスすることになる。実際には正しくURLを貼り付けるとアクセスできる。
外部リンクの後ろにあるアイコンから開く場合は、別窓で問題なくアクセスできています。
問題② https://www.google.com/search?q=PC+%E7%84%A1%E6%96%99%E9%85%8D%E5%B8%83 今までは、アクセスすると使っていたchromeやSafariのブラウザが継続して外部リンクにアクセスしていたが都度、Googleアプリが起動するようになってしまった。Googleアプリをインストールしている利用者のみに影響しているものと思われます。
https://www.google.com/search?q=PC+%E7%84%A1%E6%96%99%E9%85%8D%E5%B8%83
外部リンクの後ろにあるアイコンから開く場合でも、別窓でアクセスしてもGoogleアプリが起動するようになりました。
改めてご確認いただき、ご対応をお願いいたします。
アップデートや機能仕様の変更についての案内を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・端末側の仕様変更によるものと確認いたしました。ご対応ありがとうございます。
#includexのコンテンツ切り出しロジックを改修いたしました。お手数をおかけしますが、想定どおりの動作になっているか、ご確認をお願いいたします。
なお、この改修に伴う副作用についても認識しており、現在対応を進めております。
内容によっては、仕様として取り扱わせていただく可能性もございます。
ご連絡ありがとうございます。
旧URLのリダイレクトに関する不具合につきましては、現在調査を進めております。
恐れ入りますが、今しばらくお待ちいただけますようお願いいたします。
ご迷惑をおかけして申し訳ありません。
ご確認ありがとうございます。
クッションページの不具合につきましては、すでに対応が完了しております。
ご迷惑をおかけして申し訳ありません。
問題②につきましては、端末の仕様による現象と思われます。
他のサイトやSNSでも同様の動作が見られるか、お試しいただけますでしょうか。
ご確認のほど、よろしくお願いいたします。
https://zawazawa.jp/warthunder/topic/3162/20582
のユーザーです。リアルタイムで状況調査をしていたので、その変遷について補足させていただきます。
元々の挙動：/?（ページ名）であっても正常にそのページへリダイレクトされていた
メンテナンス直後：/?（ページ名）となっているページ全てにおいてリンクを踏むとトップページが表示されていた
5月12日16時20分ごろ以降～5月13日4時現在：/?（ページ名）のうち、ページ名にスペースを含まないページは正常に表示されるが、スペースを含む場合にアドレス上で本来は%20となるところが_になりリンク切れを起こす。
という感じで二段階に推移していました。
問題①については解決したことを確認しました。問題②については未解決のままです。Googleアプリ自体は5年前にインストールしていたものです。今まではこのようなリンクの開き方ではありませんでしたが、iOSアップデートによって今までの不具合のようにiOS固有の問題である可能性も否めません。以前に使っていたiPhone6plusからでも外部リンクを押すと、Googleアプリが起動するようになってしまいました。
当Wikiユーザーが観測していた不具合の報告は下記の通りです。
https://zawazawa.jp/warthunder/topic/3162/20570
当Wiki編集者・管理者による報告は下記の通りです。
https://zawazawa.jp/warthunder/topic/100/4579
「?混入かつページ名に半角スペースが入っている場合半角スペースがアンダーバー判定に化けて正しくリダイレクトされない」と報告されています。
当Wikiのセール情報ページにて、以前から機能していた外部リンクで以下の問題が起きています。
問題①
https://play.google.com/store/apps/collection/cluster?clp=igM4ChkKEzc3MTA2Mzc3Nzc5MDQ4MjUyODAQCBgDEhkKEzc3MTA2Mzc3Nzc5MDQ4MjUyODAQCBgDGAA=:S:ANO1ljIY_k8&gsr=CjuKAzgKGQoTNzcxMDYzNzc3NzkwNDgyNTI4MBAIGAMSGQoTNzcxMDYzNzc3NzkwNDgyNTI4MBAIGAMYAA==:S:ANO1ljIFxlk
の外部リンクで、
&gsr=CjuKAzgKGQoTNzcxMDYzNzc3NzkwNDgyNTI4MBAIGAMSGQoTNzcxMDYzNzc3NzkwNDgyNTI4MBAIGAMYAA%3D%3D:S:ANO1ljIFxlk
の部分が省略されてしまう。そのため、アクセス不能に見える。実際には正しくURLを貼り付けるとアクセスできる。
https://store.steampowered.com/search/?sort_by=Price_ASC&developer=Kairosoft Co.,Ltd
の&developer=Kairosoft+Co.%2CLtd
の部分が省略されてしまう。そのため、意図しないページにアクセスすることになる。実際には正しくURLを貼り付けるとアクセスできる。
外部リンクの後ろにあるアイコンから開く場合は、別窓で問題なくアクセスできています。
問題②
https://www.google.com/search?q=PC+%E7%84%A1%E6%96%99%E9%85%8D%E5%B8%83今までは、アクセスすると使っていたchromeやSafariのブラウザが継続して外部リンクにアクセスしていたが都度、Googleアプリが起動するようになってしまった。Googleアプリをインストールしている利用者のみに影響しているものと思われます。
外部リンクの後ろにあるアイコンから開く場合でも、別窓でアクセスしてもGoogleアプリが起動するようになりました。
改めてご確認いただき、ご対応をお願いいたします。