リクエスト広場

リクエスト広場

1554 コメント
views
9 フォロー
1,478 件中 321 から 360 までを表示しています。
2
款冬華 2025/05/12 (月) 21:09:16

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

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

具体的な使用例を提示していただくことは可能でしょうか？
また、アンカー付きの短縮URLはどのように生成されたのでしょうか？
お手数ですが、ご確認のほどよろしくお願い申し上げます。
1
ｹﾂﾘﾆﾝ 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
1
名前なし 2025/04/22 (火) 20:53:16 9fc7e@85e50

ゲスト向け編集差分ログでID別で見れるのとはまた別のものでしょうか。IDは変化することがありますが、現状のトピック主の主張と大きく外れているとは思わないです。
もし全く別の主張をしているのであればもう少し具体的にどういった機能を求めているのか記載したほうが良いと思います。
12
WIKIWIKI運営 2025/04/22 (火) 19:08:16 修正

まずは、#code にコピーボタンを実装いたしました。
コピーボタンはデフォルトで表示されるため、#code に引数は不要です。
今後、インライン型の別プラグインとしての実装も視野に入れておりますので、デザイン等について引き続きご意見をいただけましたら幸いです。
32
WIKIWIKI運営 2025/04/22 (火) 18:53:49
  1. 削除済みページに添付されたファイルを削除できるようにしてほしい

こちらのご要望につきましては、対応が完了しております。
該当のファイルは、「添付」「全ページのファイル一覧」「詳細」より削除していただけます。
6
副管理人(WoTBWiki) 2025/04/21 (月) 11:03:20

皆様ご意見いただきありがとうございました。
賛同の多い要望かと思いますので、運営チーム(@wikiwiki)の見解をいただければ幸いです。

1
名前なし 2025/04/20 (日) 21:51:34 9fc7e@af59d

アカウント制度の導入とそれによる編集制限などの議論はこのトピックで行われております。話が複数箇所で行われると大変なため、似た話題の場合、こちらで対応していただきたいです
17
款冬華 2025/04/19 (土) 23:10:43

タグで切り替えできるプラグインの仕様について
PC版とスマホ版で画面領域が違うので、どちらかに合わせるほうが運営さん的には良いのかなと思います。

入れ子構造：どちらでも可

→PC編集ではあると便利ですが、スマホ編集では無い方が便利と思っています。

ラベル指定：必要

→文字列ありでスマホ表示では一定文字数を超えたら「…」が表示されたらいいと思います。(例:あいう…)

WIKI記法：不要

→理由あって運営さんが不要としたいのであれば、それを押し通すのが定石です。有料プランが存在していない以上はどうすることもできないので、他の要望を却下されて従うことと同じように異論ありません。

ラベルのデザイン：希望なし

→希望はありませんがプルダウンが利用しやすいです。画面外の数の表示になってもスクロールボタンが表示されてプルダウンできることが望ましいですね。いくつかサンプルを動画なり画像なりで運営さんが用意して、投票してもらうこともご検討ください。

タブ数の制限

→どれほど負荷が増えるか不明ですが、負荷が大きいページをタブで表示されるwikiもあると思いますので、それを見越した制限が科された方が運営的に対処しやすいかと存じます。

スマホ表示について

iOS独自の仕様で開発に苦慮していると伺っています。利便性を損なう場合、旧来の現行表示ができる形も選べると助かります。現行の編集モードである構文ハイライトON・OFFのように選べることが良いです。

最後に

過去に前例のないほどに数々の要望に対するご意見が、ここ数日だけで運営さんへ向かって投げかけられている状態です。それほど皆さんの編集意識の高まり・編集意欲の向上が感じます。どれほど受け止めて反映できるのか分かりませんが皆さんの思いはただ一つ、各々が行っている活動の発展です。早急でなくて構わないので一つひとつ、ご対応をお願いいたします。
11
款冬華 2025/04/19 (土) 22:19:57

>> 9さんが言っている

コピー対象の内容は画面上に表示されている必要があります。何がコピーされるか予想ができません。内容と量を把握したうえで実行されるべきです。

同意します。この機能が実装されたら編集しやすいなあと個人的に思います。
5
款冬華 2025/04/19 (土) 22:01:06 >> 4

管理をされている方の一番厄介で時間のかかる対応は荒らし・迷惑行為をする人物の特定及び、事後対応です。できるだけ工数を少なくして処理して対策したいと思っているはずです。まして迷惑行為の精査は慎重に行い、対処しなければならない大切な工程です。運営さんに最優先事項で対応して欲しいです。

この際、特にUAやIP、ホストなどで絞り込んで特定ユーザの編集履歴を検索する場合は、その日の編集履歴だけではなく上限いっぱい（＝90日分）の編集ログを取得したいと感じます。

これができるだけでも時間効率が短縮できます。