リクエスト広場

リクエスト広場

1436 コメント
views
10 フォロー
1,366 件中 201 から 240 までを表示しています。
6
款冬華 2025/05/13 (火) 16:05:19 >> 5

問題②について他サイトにて、同事象の再現を確認いたしました。iOS・端末側の仕様変更によるものと確認いたしました。ご対応ありがとうございます。
3
WIKIWIKI運営 2025/05/13 (火) 15:41:56 >> 1

#includex のコンテンツ切り出しロジックを改修いたしました。
お手数をおかけしますが、想定どおりの動作になっているか、ご確認をお願いいたします。

なお、この改修に伴う副作用についても認識しており、現在対応を進めております。
内容によっては、仕様として取り扱わせていただく可能性もございます。
3
WIKIWIKI運営 2025/05/13 (火) 15:10:29

ご連絡ありがとうございます。

旧URLのリダイレクトに関する不具合につきましては、現在調査を進めております。
恐れ入りますが、今しばらくお待ちいただけますようお願いいたします。

ご迷惑をおかけして申し訳ありません。
5
WIKIWIKI運営 2025/05/13 (火) 15:07:56

ご確認ありがとうございます。

クッションページの不具合につきましては、すでに対応が完了しております。
ご迷惑をおかけして申し訳ありません。

問題②につきましては、端末の仕様による現象と思われます。
他のサイトやSNSでも同様の動作が見られるか、お試しいただけますでしょうか。

ご確認のほど、よろしくお願いいたします。
2
y_BNR32 2025/05/13 (火) 03:35:47 >> 1

https://zawazawa.jp/warthunder/topic/3162/20582
のユーザーです。リアルタイムで状況調査をしていたので、その変遷について補足させていただきます。

元々の挙動：/?（ページ名）であっても正常にそのページへリダイレクトされていた

メンテナンス直後：/?（ページ名）となっているページ全てにおいてリンクを踏むとトップページが表示されていた

5月12日16時20分ごろ以降～5月13日4時現在：/?（ページ名）のうち、ページ名にスペースを含まないページは正常に表示されるが、スペースを含む場合にアドレス上で本来は%20となるところが_になりリンク切れを起こす。

という感じで二段階に推移していました。
4
款冬華 2025/05/12 (月) 23:58:27 >> 3

問題①については解決したことを確認しました。問題②については未解決のままです。Googleアプリ自体は5年前にインストールしていたものです。今まではこのようなリンクの開き方ではありませんでしたが、iOSアップデートによって今までの不具合のようにiOS固有の問題である可能性も否めません。以前に使っていたiPhone6plusからでも外部リンクを押すと、Googleアプリが起動するようになってしまいました。
1
編集者Snow 2025/05/12 (月) 23:02:39

当Wikiユーザーが観測していた不具合の報告は下記の通りです。
https://zawazawa.jp/warthunder/topic/3162/20570

当Wiki編集者・管理者による報告は下記の通りです。
https://zawazawa.jp/warthunder/topic/100/4579
「?混入かつページ名に半角スペースが入っている場合半角スペースがアンダーバー判定に化けて正しくリダイレクトされない」と報告されています。
3
款冬華 2025/05/12 (月) 21:36:16 修正

当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アプリが起動するようになりました。

改めてご確認いただき、ご対応をお願いいたします。
2
款冬華 2025/05/12 (月) 21:09:16

他のwikiwikiサイトのクッションページにて、エラーメッセージが表示されていませんでした。当Wikiでもクッションページを有効化したところ、上記エラーメッセージが表示されていないことを確認いたしました。ご対応ありがとうございます。

>> 1については05/10時点の投稿であるため、今回のメンテナンスとは直接、関係ないかもしれません。
2
WIKIWIKI運営 2025/05/08 (木) 18:41:30 >> 1

具体的な使用例を提示していただくことは可能でしょうか？
また、アンカー付きの短縮URLはどのように生成されたのでしょうか？
お手数ですが、ご確認のほどよろしくお願い申し上げます。
1
cept 2025/05/06 (火) 12:13:50 修正

タグ管理機能について、より柔軟な仕組みの導入を検討しているとのことで感謝申し上げます。

>タグの記述はページとは別の管理画面で行う形を想定しており、タグ荒らし対策などの理由から、管理者限定となる可能性があります。
この点には強く否定的です。

文脈としては
サーバーへの負荷やセキュリティの観点→誰もがタグを記述できることが望ましくない
という流れであると認識しております。

しかし、運営さんが言及しているように「タグがページ分類だけでなく、情報整理や検索用途としても幅広く使われる」という現状において、タグの付与や修正が管理者（＋副管理者）以外で利用できなくなるとすれば、管理者の負担が著しく増加するほか管理者の多忙期にはタグが機能しないという状態を招きます。
（私が管理しているwikiでは、取り扱うソシャゲのアップデートに応じて、従来の記述ルールに沿う形で新しいタグが増えており、誤字衍字やタグ抜けを管理者以外が修正してくださることも多いです）

タグを編集できるのはSMS認証ユーザのみとするのが適当な落とし所ではないでしょうか。
タグ付与・修正を管理者のみが行えるという方向性で進めるとしても、通報機能に似た形式でユーザから管理者に対し、このページに〇〇というタグを付与してほしい(複数選択可・新規タグ可）という連絡機能が最低限あってほしいと考えます。

一方で、管理者に対しては、
・タグの全件表示と付与ページ数表示（使用状況の確認）
がマストとして、それを前提に
・特定のタグを一括でリネームする（表記揺れ等の対策）
・特定のタグを一括で除去する（タグ荒らしへの対応や、不要なタグの削除）
などの機能があると便利だなと感じます。
10
WIKIWIKI運営 2025/05/04 (日) 19:22:27 >> 8

タグリストの制限について

タグ機能は、20年前のWeb2.0的な利用スタイルを元に設計されたもので、誰でも気軽にタグを付けられる、簡素で自由度の高い運用を前提としており、ごく限られたタグ数での使用を想定していました。

しかし現在では、タグがページ分類だけでなく、情報整理や検索用途としても幅広く使われるようになり、登録数や使い方も大きく変化しています。その結果、非常に多くのタグが登録されるケースが増え、サーバーへの負荷やセキュリティの観点から、タグリストの出力に一部制限を設ける必要が生じました。

この制限について事前にお知らせできず、申し訳ありません。セキュリティ対策の一環として、仕様の詳細はあえて公表しておりません。

現行のタグプラグインにつきましては、設計上の制約もあり、今後の機能追加は予定しておりません。ただし、将来的には、より柔軟なタグ管理を可能にする新たな仕組みの導入を検討しています。

新しいタグ管理機能では、タグの記述はページとは別の管理画面で行う形を想定しており、タグ荒らし対策などの理由から、管理者限定となる可能性があります。このような新機能の具体化にあたっては、別のトピックでご要望をいただけますと、検討が進みやすくなります。

なお、どうしても現在のタグリストが必要な場合は、テキスト形式での個別対応も可能ですので、「お問い合わせ」よりご依頼ください。
2
WIKIWIKI運営 2025/05/04 (日) 18:02:45 >> 1

今回の現象については、運営でも把握しております。

WIKIで使われる構文やプラグインは、プログラムのソースコードのように、書き方によって挙動が変わる仕組みになっています。そのため、見た目は単純でも、記述の構成や順序、組み合わせによって結果が変わることがあります。

特に古くから存在するプラグインは、開発当時に存在していなかった新しいプラグインとの連携を考慮していないため、組み合わせ方によって想定外の挙動となる場合があります。

ご指摘の動作については、期待される挙動との違いがあると受け止めており、改善の方向で検討しています。
3
Spect 2025/05/03 (土) 19:54:14 >> 2

回避方法のご教授ありがとうございます
ひとまずこの方法で応急処置としたいと思います
2
01v 2025/04/30 (水) 19:45:41

リンクになる対象に適当なインライン要素を割り込ませれば、解釈されず回避できます。

&countdown(2023-5-12 09:00:00,full){ビッグ&null{};ランは終了しました。};

正しく表示されないのはcountdownの不具合ぽいですが。
1
Spect 2025/04/30 (水) 19:22:17

ネクロポストとなってしまい恐縮ですが、こちらの問題について進展はございますでしょうか

1
名前なし 2025/04/30 (水) 17:32:47 修正 d9d8f@6728c

文字コードを利用するのはどうでしょう。
[[記事名(文字コードで)>記事URL]]としたら、少し面倒ですがやりたいことはできると思います。
ですがリンク先がURLだと、右上に変なアイコンが出てしまうので見栄えは悪くなってしまいます

追記
他スレで既に解決済みなようでした

21
スレ主 2025/04/30 (水) 17:29:42 d9d8f@6728c >> 20

>ボタンを押してもコピーされたかどうか分からない
注釈のように、コピーボタンを押したら上部に「コピー完了」のようなふきだしが出るスタイルなら分かりやすいかもしれません
2
Lanotawiki管理人 2025/04/29 (火) 18:38:53 >> 1

文字コードに変換する方法で解決しました。
本当にありがとうございますm(_ _)m

1
名前なし 2025/04/29 (火) 18:27:05 1ac7b@626b9

対応策として、以下のような方法があります。

  • 全角で「｜」を記述する（2バイト文字はwiki構文として認識されません）
  • 文字コードに変換する(編集画面でテキストを選択し、下部の[＆＃]ボタンを押す)
  • 他の文字で代用する(/など)
20
Ze 2025/04/29 (火) 18:06:12 1ac7b@626b9 >> 19

インライン型の実装案ですが、以下イメージのような形式がシンプルで現実的かなと思います。

&copy{<テキスト>};

画像1

懸念点など：

  • コピーする範囲を分かりやすくするべきか
    →主な用途としては、イメージのような表組みレイアウトとの組み合わせが想定されますので、コピー範囲の明示はしなくても問題はないと思います。
  • ボタンを押してもコピーされたかどうか分からない
    →ブロック型と違い、動的にコピー成否を表示するのは難しいと思われるので、許容してもらうしかない
7
はやし 2025/04/28 (月) 20:11:21 6d43b@f53e0 >> 6

この機能は、使い道が多そうです。👍
オンラインのゲームは期間限定のイベントやセールがよくありますが、そうした記述を期間が過ぎた後に自動で引っ込められるのは便利です。

1
名前なし 2025/04/28 (月) 01:25:39 93fcb@24fb0

@wikiwiki
仕様面になりこれ以上進展はないかと思いますので見解をお聞かせいただければ幸いです

10
名前なし 2025/04/28 (月) 01:20:38 93fcb@24fb0 >> 9

用途変わってしまってますが4の使い方はできないということでしょうか？(単一ページ内でのsearch)
6
01v 2025/04/28 (月) 00:06:50

表示期間を指定できるマルチライン書式があれば良いでしょう。

#print(開始時, 終了時, 周期){{
内容
}}

オプション
- 開始: 表示開始年月日時分(未指定ならはるか昔)
- 終了: 表示終了(未指定ならはるか未来)
- 周期: 時間帯、曜日、月ごとの特定日、特定の月日

動作としては開始-終了期間だけ内容を表示。
周期に指定があれば期間内で条件が当てはまる場合のみ表示。

利点

  • 手動で困難なタイミングでの実行
  • 拘束時間の開放
  • ミス、忘れ防止
  • 繰り返しの煩雑さの軽減
  • マルチライン

考えられる例としては以下のような案内の自動化

  • イベント、記念日、あけおめ
  • 特売日(曜日)
  • 活動時間(外)、番組の放映時間の案内

考慮すべき点として

  • 内容は予めhtml変換済みでブラウザー側の時計で表示タイミングを制御
  • 見出しを含む場合、非表示期間にcontentsで表示されないこと
  • 内容をincludeで呼び出せること
  • 見た目非表示でもソースは記述済みなのでネタバレはしかたない
  • 周期内容を複数指定できるか
    月-金の9:00-17:00が営業時間中とか、あるいは17:00-24:00と0:00-9:00は時間外とか
  • 周期指定を入れると作りが複雑になりそうだから、これは省くか後回しにするか
5
名前なし 2025/04/27 (日) 20:47:26 9fc7e@db5fb

カウントダウンであればあるもので対応できますし、&tomorrowを使うと、〇〇日後は〇〇です。という文章の自動更新化も可能です。リンク
既に言われているとおり複数人で動かすwikiという場で、編集の衝突の可能性がある予約システムは合わず、需要とその問題を回避する手間が見合っていないと思います。
8
WIKIWIKI運営 2025/04/27 (日) 16:48:12 >> 5

ご不便をおかけして申し訳ございません。

当該ページの MenuBar 最下部に直接リンクされている旧形式のURLについて動作確認を行い、正常に新しいURL形式へリダイレクトされていることを確認しました。

?cmd や ?plugin などのURLコマンド仕様は、セキュリティ強化のため先日変更しています。

従来のURLコマンドは恒久的にリダイレクトされますが、セキュリティ上の理由から、状況によりブロックされる場合があります。

そのため、新しいURL形式への置き換えを推奨します。
新仕様では、クエリパラメータではなくパス形式でコマンドを指定します。

例: ?cmd=list → ::cmd/list ?cmd=edit&page=FrontPage → ::cmd/edit?page=FrontPage

また、?plugin は廃止され、今後は ::cmd/ を通じて同様の機能をご利用いただきます。
ご不便をおかけしますが、順次、新しい仕様への移行にご協力をお願いいたします。

19
スレ主 2025/04/27 (日) 12:42:31 d9d8f@6728c

使ってみた所感ですが、やはりcodeということで何行もある文のコピーには適していました。少しcopyの文字が見づらいとは感じましたが、下手に大きくしたり濃くしたりしても原文が見づらくなるので仕方ないかとは思っています。
しかし、結果と原文の両方を載せようとすると、codeの性質上とるスペースがどうしても大きくなってしまいます。一応foldで片方隠すことはできますが、行数が多くなる、展開する度に視認性が悪くなるといった問題があるように感じました。

1行で終わる程度の構文やプラグインのコピーには、インライン型のものが欲しいです。1行のものずつに原文とcodeを載せていると、先述の視認性の悪さが顕著に出ます。どちらかを排してどちらかを受け入れるというよりは、両方に得手不得手があると思うので、codeは引き続き実装し、インライン型のものも実装してほしいです。

あと少し逸れますが、codeのcopyボタンの表示の有無については引数がほしいです。コピーさせることを前提に置いてない使い方(使用例とそのコード文)をしている箇所があるので、その引数があった方がと思いました。

4
名前なし 2025/04/27 (日) 12:33:56 24a97@4fd43

ネットワークプログラミングの知識が多少あること、wiki管理者にAPIトークンを発行してもらうことが前提とはなりますが、
REST APIを用いて自作のスクリプトを組めば予約投稿のようなことは実現可能です。

REST API - WIKIWIKI.jp Sample Wiki*
https://wikiwiki.jp/sample/REST API

掲示板 WIKIWIKI REST API コミュニティ - zawazawa
https://zawazawa.jp/wikiwiki-rest-api/topic/6

3
名前なし 2025/04/27 (日) 12:19:31 d9d8f@6728c

カウントダウンだけなら>> 1さんのものでいいと思います。
予約投稿の機能については、需要がほとんどないと思うので要らないかと思います。おそらく想定される使い方は「特定時間に合わせて投稿」「編集者のアクティブ時間帯を他者に悟られないように」などがあると考えますが、わざわざこのための機能を追加し、更新の衝突の問題を解決する方法を探すのは割に合わない気がします。
「特定時間に合わせて投稿」ならば、詳しくはないですが外部から編集できるような仕組みがあったようななかったような。もしかしたらそれからできるのかもしれません。

2
名前なし 2025/04/27 (日) 07:05:19 ef179@24fb0

予約投稿した場合に衝突や更新の考え方が難しいのかなと思います。

1
はやし 2025/04/25 (金) 11:39:42 6d43b@f53e0

wikiは複数の人が編集をするシステムなので、投稿を予約する機能を持たせることは非常に難しいのではないでしょうか。

「発売や公開までのカウントダウンを毎日投稿したい」とのことですが、
countdownのプラグインを使えば、近いことが自動でできるかもしれません。

例

子供の日まで残り: &countdown(2025-05-05,day);

出力

子供の日まで残り: 9日
18
款冬華 2025/04/24 (木) 19:55:14 >> 13 
BGCOLOR(whitesmoke):
BGCOLOR(lavender):
BGCOLOR(#ddd):
BGCOLOR(#F0F0F0):
BGCOLOR(silver):
BGCOLOR(white):

こちらの内容だと問題なく見た目どおりに貼り付けることができたので、参考記事にある原因として挙げられている:が問題ではなく、別のところにあるかもしれません。記事内ではiOS17の問題でiOS18では解消されていると言われていますが、当方はiPhoneSE3(iOS18.3.2(22D82))です。バージョンアップ(iOS18.4.1)がありましたので念のため行ったところ、やはり不具合は改善されませんでした。

ちなみに普段は利用していない2台目のiPhone8plus(iOS16.7.10)で当事象を確認しましたが、この問題は発生せずに見た目どおりに貼り付けることができます。
17
款冬華 2025/04/24 (木) 18:38:10 >> 13

ご指摘のとおりでした。コロンを抜いてコピー&貼り付けてみたところ、記述したとおりに改行されたままで貼り付けできました。

この不具合はiOS側のものなので、どうにかできるものなのか不明ですが引き続き、よろしくお願いします。

また、同様の仕組みがあるプラグインを公開されている方がいましたので参考にしてみてください。

自作プラグイン/clipboard
https://jpngamerswiki.com/?39d867ef25

自作のPukiWiki用プラグイン置き場
https://github.com/kanateko/pukiwiki-plugin
16
WIKIWIKI運営 2025/04/24 (木) 18:12:42 >> 13

現時点では、iOS側の不具合であると考えられます。
テキスト内に : が含まれていると、URLとして認識され、
自動的にURLエンコードされた状態で貼り付けられてしまうようです。

引き続き、調査を進めております。

参考記事

How do you avoid copy/paste content with a ':' coming out url encoded on an iPhone browser?
I have a web app that puts content on the browser clipboard: navigator.clipboard.writeText("Name: Joe Schmo\nAddress:\t550 W. Someplace Ave\n\t\t\tAnytown\t\t\t55555\nPhone: 555-555-5555&quot...
Stack Overflow
15
款冬華 2025/04/24 (木) 13:49:36 >> 13

ご確認ありがとうございます。一旦、教えていただいた対処法で今後は編集いたします。幾度となくiOS独自のブラウザ仕様にお手を煩わせてしまい、申し訳ありませんがよろしくお願いします。
14
WIKIWIKI運営 2025/04/24 (木) 13:17:18 >> 13

ご連絡ありがとうございます。
iPhoneでコピーした後、フォームに貼り付けた際にご指摘の現象をこちらでも再現できました。
なお、iPhoneのメモ帳アプリには正常に貼り付けできることも確認しており、iOSのブラウザ側の仕様による可能性がありそうです。
現在、原因の特定を進めております。
13
款冬華 2025/04/24 (木) 12:31:30 >> 12

不具合報告です。

#code{{
CENTER:&fa_stack(fa-2x,#ffd700){&fa(fa-solid fa-diamond fa-stack-2x); &fa(fa-solid fa-person-digging fa-stack-1x,#000000);};
LEFT:このページは編集中です。ページ名を変更する可能性があります。
}}

コピーボタンを押して貼り付けるとデコードされずに反映されます。改行もされません。記述した通りにコピーするよう、お願いいたします。

貼り付けた時の内容

center:&fa_stack(fa-2x,%23ffd700)%7B&fa(fa-solid%20fa-diamond%20fa-stack-2x);%20&fa(fa-solid%20fa-person-digging%20fa-stack-1x,%23000000);%7D;%0ALEFT:%E3%81%93%E3%81%AE%E3%83%9A%E3%83%BC%E3%82%B8%E3%81%AF%E7%B7%A8%E9%9B%86%E4%B8%AD%E3%81%A7%E3%81%99%E3%80%82%E3%83%9A%E3%83%BC%E3%82%B8%E5%90%8D%E3%82%92%E5%A4%89%E6%9B%B4%E3%81%99%E3%82%8B%E5%8F%AF%E8%83%BD%E6%80%A7%E3%81%8C%E3%81%82%E3%82%8A%E3%81%BE%E3%81%99%E3%80%82