こちらのスレッドに参考になる意見が多数出てきたため、アカウントシステムをこれらの意見を参考に実装して下さると助かります。 一通り意見も出揃いましたので、運営からのコメントをお願いします。@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アプリが起動するようになりました。
改めてご確認いただき、ご対応をお願いいたします。
他のwikiwikiサイトのクッションページにて、エラーメッセージが表示されていませんでした。当Wikiでもクッションページを有効化したところ、上記エラーメッセージが表示されていないことを確認いたしました。ご対応ありがとうございます。
>> 1については05/10時点の投稿であるため、今回のメンテナンスとは直接、関係ないかもしれません。
WIKIWIKIゲーム！をクリックすると接続がプライベートではありませんと表示 こちらの現象は当方でも確認しています。
具体的な使用例を提示していただくことは可能でしょうか？ また、アンカー付きの短縮URLはどのように生成されたのでしょうか？ お手数ですが、ご確認のほどよろしくお願い申し上げます。
タグ管理機能について、より柔軟な仕組みの導入を検討しているとのことで感謝申し上げます。
>タグの記述はページとは別の管理画面で行う形を想定しており、タグ荒らし対策などの理由から、管理者限定となる可能性があります。 この点には強く否定的です。
文脈としては サーバーへの負荷やセキュリティの観点→誰もがタグを記述できることが望ましくない という流れであると認識しております。
しかし、運営さんが言及しているように「タグがページ分類だけでなく、情報整理や検索用途としても幅広く使われる」という現状において、タグの付与や修正が管理者（＋副管理者）以外で利用できなくなるとすれば、管理者の負担が著しく増加するほか管理者の多忙期にはタグが機能しないという状態を招きます。 （私が管理しているwikiでは、取り扱うソシャゲのアップデートに応じて、従来の記述ルールに沿う形で新しいタグが増えており、誤字衍字やタグ抜けを管理者以外が修正してくださることも多いです）
タグを編集できるのはSMS認証ユーザのみとするのが適当な落とし所ではないでしょうか。 タグ付与・修正を管理者のみが行えるという方向性で進めるとしても、通報機能に似た形式でユーザから管理者に対し、このページに〇〇というタグを付与してほしい(複数選択可・新規タグ可）という連絡機能が最低限あってほしいと考えます。
一方で、管理者に対しては、 ・タグの全件表示と付与ページ数表示（使用状況の確認） がマストとして、それを前提に ・特定のタグを一括でリネームする（表記揺れ等の対策） ・特定のタグを一括で除去する（タグ荒らしへの対応や、不要なタグの削除） などの機能があると便利だなと感じます。
タグリストの制限について
タグ機能は、20年前のWeb2.0的な利用スタイルを元に設計されたもので、誰でも気軽にタグを付けられる、簡素で自由度の高い運用を前提としており、ごく限られたタグ数での使用を想定していました。
しかし現在では、タグがページ分類だけでなく、情報整理や検索用途としても幅広く使われるようになり、登録数や使い方も大きく変化しています。その結果、非常に多くのタグが登録されるケースが増え、サーバーへの負荷やセキュリティの観点から、タグリストの出力に一部制限を設ける必要が生じました。
この制限について事前にお知らせできず、申し訳ありません。セキュリティ対策の一環として、仕様の詳細はあえて公表しておりません。
現行のタグプラグインにつきましては、設計上の制約もあり、今後の機能追加は予定しておりません。ただし、将来的には、より柔軟なタグ管理を可能にする新たな仕組みの導入を検討しています。
新しいタグ管理機能では、タグの記述はページとは別の管理画面で行う形を想定しており、タグ荒らし対策などの理由から、管理者限定となる可能性があります。このような新機能の具体化にあたっては、別のトピックでご要望をいただけますと、検討が進みやすくなります。
なお、どうしても現在のタグリストが必要な場合は、テキスト形式での個別対応も可能ですので、「お問い合わせ」よりご依頼ください。
今回の現象については、運営でも把握しております。
WIKIで使われる構文やプラグインは、プログラムのソースコードのように、書き方によって挙動が変わる仕組みになっています。そのため、見た目は単純でも、記述の構成や順序、組み合わせによって結果が変わることがあります。
特に古くから存在するプラグインは、開発当時に存在していなかった新しいプラグインとの連携を考慮していないため、組み合わせ方によって想定外の挙動となる場合があります。
ご指摘の動作については、期待される挙動との違いがあると受け止めており、改善の方向で検討しています。
回避方法のご教授ありがとうございます ひとまずこの方法で応急処置としたいと思います
リンクになる対象に適当なインライン要素を割り込ませれば、解釈されず回避できます。
&countdown(2023-5-12 09:00:00,full){ビッグ&null{};ランは終了しました。};
正しく表示されないのはcountdownの不具合ぽいですが。
ネクロポストとなってしまい恐縮ですが、こちらの問題について進展はございますでしょうか
文字コードを利用するのはどうでしょう。 [[記事名(文字コードで)>記事URL]]としたら、少し面倒ですがやりたいことはできると思います。 ですがリンク先がURLだと、右上に変なアイコンが出てしまうので見栄えは悪くなってしまいます
追記 他スレで既に解決済みなようでした
>ボタンを押してもコピーされたかどうか分からない 注釈のように、コピーボタンを押したら上部に「コピー完了」のようなふきだしが出るスタイルなら分かりやすいかもしれません
文字コードに変換する方法で解決しました。 本当にありがとうございますm(_ _)m
対応策として、以下のような方法があります。
インライン型の実装案ですが、以下イメージのような形式がシンプルで現実的かなと思います。
©{<テキスト>};
懸念点など：
この機能は、使い道が多そうです。👍 オンラインのゲームは期間限定のイベントやセールがよくありますが、そうした記述を期間が過ぎた後に自動で引っ込められるのは便利です。
@wikiwiki 仕様面になりこれ以上進展はないかと思いますので見解をお聞かせいただければ幸いです
用途変わってしまってますが4の使い方はできないということでしょうか？(単一ページ内でのsearch)
表示期間を指定できるマルチライン書式があれば良いでしょう。
#print(開始時, 終了時, 周期){{ 内容 }} オプション - 開始: 表示開始年月日時分(未指定ならはるか昔) - 終了: 表示終了(未指定ならはるか未来) - 周期: 時間帯、曜日、月ごとの特定日、特定の月日
動作としては開始-終了期間だけ内容を表示。 周期に指定があれば期間内で条件が当てはまる場合のみ表示。
利点
考えられる例としては以下のような案内の自動化
考慮すべき点として
カウントダウンであればあるもので対応できますし、&tomorrowを使うと、〇〇日後は〇〇です。という文章の自動更新化も可能です。リンク 既に言われているとおり複数人で動かすwikiという場で、編集の衝突の可能性がある予約システムは合わず、需要とその問題を回避する手間が見合っていないと思います。
クエリが厳格化されてます。 こちらが正しいクエリになります。 https://wikiwiki.jp/nijisanji/?cmd=search&word=不破湊
こちらのスレッドに参考になる意見が多数出てきたため、アカウントシステムをこれらの意見を参考に実装して下さると助かります。
一通り意見も出揃いましたので、運営からのコメントをお願いします。@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アプリが起動するようになりました。
改めてご確認いただき、ご対応をお願いいたします。
他のwikiwikiサイトのクッションページにて、エラーメッセージが表示されていませんでした。当Wikiでもクッションページを有効化したところ、上記エラーメッセージが表示されていないことを確認いたしました。ご対応ありがとうございます。
>> 1については05/10時点の投稿であるため、今回のメンテナンスとは直接、関係ないかもしれません。
WIKIWIKIゲーム！をクリックすると接続がプライベートではありませんと表示
こちらの現象は当方でも確認しています。
具体的な使用例を提示していただくことは可能でしょうか？
また、アンカー付きの短縮URLはどのように生成されたのでしょうか？
お手数ですが、ご確認のほどよろしくお願い申し上げます。
タグ管理機能について、より柔軟な仕組みの導入を検討しているとのことで感謝申し上げます。
>タグの記述はページとは別の管理画面で行う形を想定しており、タグ荒らし対策などの理由から、管理者限定となる可能性があります。
この点には強く否定的です。
文脈としては
サーバーへの負荷やセキュリティの観点→誰もがタグを記述できることが望ましくない
という流れであると認識しております。
しかし、運営さんが言及しているように「タグがページ分類だけでなく、情報整理や検索用途としても幅広く使われる」という現状において、タグの付与や修正が管理者（＋副管理者）以外で利用できなくなるとすれば、管理者の負担が著しく増加するほか管理者の多忙期にはタグが機能しないという状態を招きます。
（私が管理しているwikiでは、取り扱うソシャゲのアップデートに応じて、従来の記述ルールに沿う形で新しいタグが増えており、誤字衍字やタグ抜けを管理者以外が修正してくださることも多いです）
タグを編集できるのはSMS認証ユーザのみとするのが適当な落とし所ではないでしょうか。
タグ付与・修正を管理者のみが行えるという方向性で進めるとしても、通報機能に似た形式でユーザから管理者に対し、このページに〇〇というタグを付与してほしい(複数選択可・新規タグ可）という連絡機能が最低限あってほしいと考えます。
一方で、管理者に対しては、
・タグの全件表示と付与ページ数表示（使用状況の確認）
がマストとして、それを前提に
・特定のタグを一括でリネームする（表記揺れ等の対策）
・特定のタグを一括で除去する（タグ荒らしへの対応や、不要なタグの削除）
などの機能があると便利だなと感じます。
タグリストの制限について
タグ機能は、20年前のWeb2.0的な利用スタイルを元に設計されたもので、誰でも気軽にタグを付けられる、簡素で自由度の高い運用を前提としており、ごく限られたタグ数での使用を想定していました。
しかし現在では、タグがページ分類だけでなく、情報整理や検索用途としても幅広く使われるようになり、登録数や使い方も大きく変化しています。その結果、非常に多くのタグが登録されるケースが増え、サーバーへの負荷やセキュリティの観点から、タグリストの出力に一部制限を設ける必要が生じました。
この制限について事前にお知らせできず、申し訳ありません。セキュリティ対策の一環として、仕様の詳細はあえて公表しておりません。
現行のタグプラグインにつきましては、設計上の制約もあり、今後の機能追加は予定しておりません。ただし、将来的には、より柔軟なタグ管理を可能にする新たな仕組みの導入を検討しています。
新しいタグ管理機能では、タグの記述はページとは別の管理画面で行う形を想定しており、タグ荒らし対策などの理由から、管理者限定となる可能性があります。このような新機能の具体化にあたっては、別のトピックでご要望をいただけますと、検討が進みやすくなります。
なお、どうしても現在のタグリストが必要な場合は、テキスト形式での個別対応も可能ですので、「お問い合わせ」よりご依頼ください。
今回の現象については、運営でも把握しております。
WIKIで使われる構文やプラグインは、プログラムのソースコードのように、書き方によって挙動が変わる仕組みになっています。そのため、見た目は単純でも、記述の構成や順序、組み合わせによって結果が変わることがあります。
特に古くから存在するプラグインは、開発当時に存在していなかった新しいプラグインとの連携を考慮していないため、組み合わせ方によって想定外の挙動となる場合があります。
ご指摘の動作については、期待される挙動との違いがあると受け止めており、改善の方向で検討しています。
回避方法のご教授ありがとうございます
ひとまずこの方法で応急処置としたいと思います
リンクになる対象に適当なインライン要素を割り込ませれば、解釈されず回避できます。
正しく表示されないのはcountdownの不具合ぽいですが。
ネクロポストとなってしまい恐縮ですが、こちらの問題について進展はございますでしょうか
文字コードを利用するのはどうでしょう。
[[記事名(文字コードで)>記事URL]]としたら、少し面倒ですがやりたいことはできると思います。
ですがリンク先がURLだと、右上に変なアイコンが出てしまうので見栄えは悪くなってしまいます
追記
他スレで既に解決済みなようでした
>ボタンを押してもコピーされたかどうか分からない
注釈のように、コピーボタンを押したら上部に「コピー完了」のようなふきだしが出るスタイルなら分かりやすいかもしれません
文字コードに変換する方法で解決しました。
本当にありがとうございますm(_ _)m
対応策として、以下のような方法があります。
インライン型の実装案ですが、以下イメージのような形式がシンプルで現実的かなと思います。
懸念点など：
→主な用途としては、イメージのような表組みレイアウトとの組み合わせが想定されますので、コピー範囲の明示はしなくても問題はないと思います。
→ブロック型と違い、動的にコピー成否を表示するのは難しいと思われるので、許容してもらうしかない
この機能は、使い道が多そうです。👍
オンラインのゲームは期間限定のイベントやセールがよくありますが、そうした記述を期間が過ぎた後に自動で引っ込められるのは便利です。
@wikiwiki
仕様面になりこれ以上進展はないかと思いますので見解をお聞かせいただければ幸いです
用途変わってしまってますが4の使い方はできないということでしょうか？(単一ページ内でのsearch)
表示期間を指定できるマルチライン書式があれば良いでしょう。
動作としては開始-終了期間だけ内容を表示。
周期に指定があれば期間内で条件が当てはまる場合のみ表示。
利点
考えられる例としては以下のような案内の自動化
考慮すべき点として
月-金の9:00-17:00が営業時間中とか、あるいは17:00-24:00と0:00-9:00は時間外とか
カウントダウンであればあるもので対応できますし、&tomorrowを使うと、〇〇日後は〇〇です。という文章の自動更新化も可能です。リンク
既に言われているとおり複数人で動かすwikiという場で、編集の衝突の可能性がある予約システムは合わず、需要とその問題を回避する手間が見合っていないと思います。
クエリが厳格化されてます。
こちらが正しいクエリになります。
https://wikiwiki.jp/nijisanji/?cmd=search&word=不破湊