リクエスト広場

1,516 件中 441 から 480 までを表示しています。
6
副管理人(WoTBWiki) 2025/04/14 (月) 13:11:01

賛同します。編集ユーザーの特定(編集への貢献度などを負いやすくする)という点でも、現在の匿名仕様と並行して実装いただくと非常に有用かと思います。

また、アイデア程度のご提案とはなりますが、zawazawaアカウントと連動したアカウント機能があるとwikiwiki・zawazawa間がシームレスに連携するのでは、とも思います。

2
副管理人(WoTBWiki) 2025/04/14 (月) 13:07:09

賛同します。確かに凍結解除自体は大した手間ではない…と言われればその通りなのですが、凍結解除→返信→凍結→…と繰り返すのは面倒なところもありますし、凍結忘れのリスクもあります。>> 1さんの提案の通り、(サブ)パスワードを用いて更新できる機能の実装を望みます。

7
名前なし 2025/04/14 (月) 09:58:17 678d2@d2d6c >> 6

リアルタイムコメントは削除不可です。
各々ユーザーが自分のブラウザで特定投稿者のコメントを非表示にすることはできますが、
それでは根本的な解決になりません。

例えば、リアルタイムコメントの代わりに「助け合い掲示板」を埋め込んでしまう方法もあろうかと思いますが、
(運営が)どうするにせよ、荒らしを放置せずに対処されることを望みます。

6
名前なし 2025/04/14 (月) 01:48:19 93fcb@24fb0

権限を落とせたりしないのでしょうか?気づいた利用者が消せたりできればまだやりようがあるのかなと思いました。

5
款冬華 2025/04/14 (月) 00:35:35

https://wikiwiki.jp/sample/リアルタイムコメントフォーム
でも同様の文言でトピック主のURLにある荒らし行為が行われています。うさ晴らしに時間や書き込み先を変えた同一人物と推測します。

また、WIKIWIKI SandBoxにあるリアルコメントは現在もなお、数日前のログに個人情報が残されています。

サンプルwikiなど運営管理であれば荒らし行為をしても人様に迷惑かけているわけでもないので、問題ないと判断されているのでしたら考えを改めていただきたいです。

本サービスに関する利用のルール
1.公的秩序・法律に関する内容
第三者に対して危害や損害を与える内容
ネットワークやシステムに過度な負荷をかける行為
荒らし行為
5.管理権限の不適切な扱い
WIKIの管理を長期的に放置する

に該当しています。2つのサンプルページを適切に管理してほしいです。

5
款冬華 2025/04/13 (日) 23:45:08 >> 3

回答ありがとうございます。数年に渡って要望してきたことに終止符を打つことができました。丁寧に回答してくださり、改めて感謝申し上げます。

要望とは別に返信いただいた内容を拝見した上で、ここから先は提案です。いくら機能改善の要望があってもベースであるPukiWikiが更新が滞っており、不具合も所々あるという指摘を様々なサイトで拝見します。

wikiソフトウェア「PukiWiki plus!」を利用していて、現在はPukiWikiをベースに独自開発されていると聞いています。ベースのPukiWikiが時々、更新が途絶えてPHP8.2で2022年から止まっていたり、不具合箇所をwikiwiki側が解消(その1・その2)していて運営側の大変さを感じています。PukiWikiは主に日本人がメインで更新されているので、脆弱性を狙ったセキュリティの対応に遅れを取るのは致し方ないのかなと思います。

利用者の編集知識も長年のインターネットの普及で高まり、利用できる端末も豊富になりました。しかし、初心者が参入していくには確かにシンプルさも重要です。他にも優先度の高い要望やセキュリティ対策などもあるかと思います。

いっそのこと、同じデータベース不要で開発が活発であるDokuWikiに移行してしまうといった思い切った手法も一つかなと思います。そのためには記法の変換、利用者へ周知など大変なことは確かにいくつかあります。日々、増えていく利用者の要望受け入れ、セキュリティ対策、今後も継続して運営していくための戦略など総合的に判断が必要です。開発が停滞気味のPukiWikiに今後も依存していくのも見切りをつけるのも、最終手段として考えてほしいです。技術力があるならSeesaa Wikiのように独自にwikiソフトウェアを開発したり、データベースが必要なMediaWikiにするのもひとつです。

どれも現実的ではない選択肢ですが設計が古いという指摘や、開発が滞り気味のPukiWikiに皆さんが数多の要望をしている機能改善・拡張をするにあたって、いくつもの障壁で限界が近いのではと感じており、今後の方向性を素人考えで恐縮ですが提案させていただきました。

DokuWikiの参考URL

10
名前なし 2025/04/13 (日) 22:48:22 修正 b4131@c46e3

@wikiwikiこちらの機能は賛同意見が多く集まっていますが、現時点で実装する可能性はあるのか伺いたいです。

1
名前なし 2025/04/13 (日) 22:10:36 93fcb@24fb0

@wikiwiki
こちらについて対応は可能でしょうか?

4
名前なし 2025/04/13 (日) 21:52:43 678d2@57ea0

木主の意見に賛同します。
自分も、ユーザーに対しては(故意の)荒らし放置は規約違反、
一方で運営自らが放置するのはOK、というダブルスタンダードは
いかがなものかと思います。

もう少しご意見が集まってから検討したい

では「荒らしは放置しておく方が良い」という意見があれば、
これからも放置し続けるのでしょうか?
自らが定めた規約は、率先して守るのが筋ではないかと思いますが、
違うのでしょうか。

助け合い掲示板もありますし、
1日で消されてしまう練習用WikiのFrontPageにコメントフォームは不要と考えます。
すぐにでも対処されることを希望します。

3
トピック主 2025/04/13 (日) 19:51:19 1ac7b@626b9

要望の背景等を補足します。

テストのためにSandBoxサイトへアクセスする度、嫌でも荒らしコメントが目に入ってしまうので不快な要素でしかなく、>> 2の方が仰るとおりコメント欄を設置しておくメリットは皆無です。
これに対し利用者が取れる対策は「サイトを利用しない」ことなのですが、根本的な問題解決にはなりません。

全体の利用者からするとSandBoxへのアクセスはごく少数ではありますが、たとえ少数でも不特定多数が閲覧可能な
サイトにおいて、サービス提供者自らが利用規約に抵触する行為を放置するのは些か問題があるのではと思い、
要望させていただいた次第です。

あくまで本件はSandBoxサイトに限った話であり、他の利用者がレンタルされているwikiに対して
影響がある訳ではありませんが、他の方々の見解もコメントいただければ幸いです。

19
名前なし 2025/04/13 (日) 19:05:48 修正 2eb07@7e536 >> 13

こんにちは

>> 18

「変化が生じた場合、慣れてない人が避けるようなUIや仕組みにはならないでほしい」

複雑な仕組みにならなければよいとの事ですが、現在、案として出ているのは

  1. 運営からの案で一定時間内での完全削除

  2. こちらが提案しているパスワード等を用いた期限なしの各自の削除

  3. >> 15アカウント制度を導入するなどして、期間を設けずに完全削除できる形

上記 3案です。

1の運営からの一定時間内での完全削除は、運営側で設定されることですので
従来通りでアップロード者が、一定時間内で完全削除できるようになるだけで

2のこちらが提案しているパスワードを用いた完全削除は
現在2段階になっていますが

1段階目で従来通り、誰でも削除でき(バックアップは残ります)
2段階目でバックアップの削除のみ管理者に加えてアップロード者も行えるようにする。

これも完全削除出来るのが、管理者に加えてアップロード者になるだけで

3のアカウント制度を導入するなどして、期間を設けずに完全削除できる形は
アップロード者を特定できる形にして、期間を設けずいつでも完全削除できる様に
と言う事です。

どれを取ってみても、慣れてない人が避けるようなUIや仕組みにはならないと思います。

結びに

あなたと対立して議論する気はありません。

こちらとしては、対立したいとかしないとかではなくて、リクエスト広場のトップページに
「他の提案(要望)について考え返信をする」と記載がありますので返信させて頂いただけです。
あまり深く考えない方が良いかと思います ご返信 有難うございました。

3
WIKIWIKI運営 2025/04/13 (日) 18:10:57 >> 2

ご要望ありがとうございます。

テーブルのヘッダと左端のセルを同時に固定する機能についてですが、現時点では実装の予定はありません。

WIKIWIKIで使われているテーブル(表組み)書式は、もともとシンプルな表を手軽に作るためのもので、複雑なレイアウトや高機能な表示には向いていません。

実際、多くのテーブルはレイアウト目的で使われていて、装飾や構造もさまざまです。
その結果、列や行を正確に固定するような制御が難しくなってしまっています。

こうした状況は、Excelでも見られる問題に少し似ています。
表計算ソフトなのに見た目を整えるために使われすぎて、本来のデータ処理がやりにくくなってしまっている、というようなことです。

さらに現在は、PCやスマホ、タブレットなど端末の種類が多く、特にiOSは独自の仕様も多いため、全ての環境で安定した動作を確保するには調整が必要で、運用やメンテナンスの負担も小さくありません。

仮にこういった機能を追加する場合は、今の書式とは別に、もっと構造がシンプルで、データ中心の用途に特化した新しいテーブル機能として設計する必要があると思っています。

任意の行や列をユーザー側で固定できるようにするには、テーブルの構造が明確であることが前提となるため、現行の仕様では対応が難しく、これも新しい仕組みの中で検討すべき内容と考えています。

この新しい仕組みでは、将来的に、SQLによるデータ抽出やページ切り替え、並び替え、グラフ表示といった処理にも対応できるような拡張性を持たせることも視野に入れています。

現在検討中ではありますが、実装するかどうかはまだ未定です。

18
16 2025/04/13 (日) 16:45:21 修正 9fc7e@cefc0 >> 13

今まで自分はそのようなことを思ったことがないので、バックアップに残ると躊躇うという意見は理解できませんし正直変化してもしなくてもいいと思っているのが事実です。
16でコメントしたのも「変化が生じた場合、慣れてない人が避けるようなUIや仕組みにはならないでほしい」という運営宛ての意見を送りたかっただけで、あなたと対立して議論する気はありません。初心者でも使いやすいものが良いという意見に反していないのであれば、私との議論は不要ですので、17さんから私への返信は必要ありません。

2
名前なし 2025/04/13 (日) 16:08:08 9fc7e@cefc0

その状況を初めて知りましたがこのような状態のまま置いておくメリットはなく、もし何か聞きたい場合いつ荒らしに流されるかわからないそのコメント欄で聞かずとも、活発なwikiであれば編集者同士で意見交換したり助け合い掲示板を使えば良い話だと思います。
もし残すのであれば荒らしの排除を求めます。

1
WIKIWIKI運営 2025/04/13 (日) 15:17:38

ご要望ありがとうございます。
もう少しご意見が集まってから検討したいため、
議論が進みましたら再度メンションでお知らせください。

5
あもお 2025/04/13 (日) 14:37:12 df39e@e1ab0

アカウントベースの管理機能の実装、大いに賛成です。

もちろん、従来通りアカウントがなくとも不便なく編集可能(IPの強制公開などはナシ)とすることは必須ですが、少なくとも管理人・サブパスワード保持者(副管理人)についてはアカウント制を採用するに越したことはありません。

荒らし対策だけでなく、複数Wikiの管理一括化、管理メンバー同士のやりとりの円滑化など、多数のメリットが感じられます。また、万が一管理人が業務怠慢や職権乱用を起こした際の処置もより手早く可能になることと思います。

一方、素人の勝手な想像にはなってしまうのですが、各Wiki管理人のアカウント整備・運用が定着するにはやや長い期間を要するかもしれません。また、定着までには不具合や各種トラブルの発生も想定されます。今までのWIKIWIKIになかった全く新しいシステムですから、運営の方々と利用者との間で意見交換を重ね、丁寧に整備していく必要があるかと思います。

そこで、こちらのトピックと一部被りますが、問題が顕在化し早急な対処が求められる「荒らし対策」についてのみ、暫定的に

・パスワード(サブパスワード含む)による凍結ページの編集(≠凍結解除)
・コントロールパネル「編集制限」における「編集にはパスワードが必要」機能の新設

以上2機能の追加をお願いし、その後にアカウント制度について考えてゆくのはいかがでしょうか。

拙い文章で申し訳ありませんが、皆様の意見をお聞かせください。

17
名前なし 2025/04/13 (日) 14:19:17 09690@7e536 >> 13

皆様 こんにちは
返信が遅くなりましたが色々とご意見いただき有難うございます。


>> 15

実際問題として、アップロードミスに気づくのはその場限りではありません。

確かに後々気付くこともありますよね、それだけではなくこちらの考えとしては
例えば、やり取りの場面で、文面だけでは説明が付かない時には
「こちらをご覧下さい」とか言って、画像で説明したりする場面も想定できますし
その際は、一時的に説明する為に使用するだけなので、あとは必要なくなりますよね?
そういった時でも、いつでも気軽に添付できて、いつでも削除できる方が
便利が良いかとも思います。

他社サービスも併用することを考慮してはいかがですか。

こちらの方はあまり考えていませんでした、前スレにありましたが
「別のwikiで呼び出すための倉庫としての利用は、wikiwikiでは利用規約で禁止事項になっています」
このようなこともあり、他社サービスにおいても、同じような規約があるのでは
ないかと思っていました。

それに、他社サービスにおいては直接リンクを引いても、きちんと画像が表示されるかが
分からなかったのも理由にあります。

更に、上記の利用想定もしていましたので、その程度であれば他社サービスなどを
使用する必要もないかとも思っていました。

しかしながら、こちらの提案を支持して頂けることは、うれしく思います
ご意見有難うございます。


>> 16

編集は難しくても画像だけなら提供できると添付してくださる方もいる

確かにwiki編集は慣れないと難しいかも知れませんが
そう言った時でも、画像でなら簡単で説明も付きやすいかも知れませんね。
その様な方でも、失敗した画像などが、バックアップに残ってしまうと
添付を戸惑うのではないでしょうか?

運営の方針としては「一定時間での完全削除」が望ましいとの考えだそうですが
こちらとしては、上記の利用方法も想定しており
出来れば、いつでも添付して、いつでも削除の方が、気軽なのではないかと思います。


結びになりますが、お二方、ご意見有難うございました。

9
01v 2025/04/13 (日) 11:48:57

コピー対象の内容を画面上に表示したいか、それともボタンだけで十分か

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

テンプレート活用や初心者支援など、主な利用目的

  • wikiページの定型書式
  • 複雑なプラグインの入力支援(includexとかflexboxとかオプション指定が多いもの)
  • スマホの操作支援(範囲選択、アルファベット/記号入力の煩わし)

ブロック型なら#codeのオプションとしてCopyを追加できれば十分と思います。
ページのテンプレートやwiki書式の説明なら、flexboxで通常表示とソース表示で並べて使われると想定します。

別途インライン型は望まれると思います。

  • 表やリストにまとめたデータ
  • wikiのプラグインの記述例

インライン型の場合は、コピー範囲がわかるのが望ましいです。
コピーボタンを押したときに対象がマウスで範囲選択したように反転されるなど。
予め枠か下線で明示してもいいかもしれませんが、あまり高さを取って欲しくない気もします。

16
名前なし 2025/04/13 (日) 09:47:33 9fc7e@635f0 >> 13

②の一定時間で完全削除で自分は十分かなと思います。画像添付してから編集してプレビューで気づくこともあるのでさすがに1分は短いと思いますので、その期間の話し合いは必要だと思います。
私のところは編集は難しくても画像だけなら提供できると添付してくださる方もいるので、色々追加して複雑化するのは避けてほしいです。

4
款冬華 2025/04/12 (土) 23:58:15

編集機能を管理拡張をするアカウント制度について賛成です。こちらのトピックのように管理者・編集者は、個々に行った行動に対して責任を持って行動したいと願っています。

匿名であるが故に自由を履き違えて誤った行動する者も後を断ちません。過去に大規模なページ削除にあったことがあります。運営に問い合わせしてロールバックなどを頼めば良かったのですが、当時の利用者達は管理人が不在かつ、その考えに及ばずにトピック主と同じで有志者達が時間を掛けてバックアップから復旧させていました。当然、手動でページの復旧を行ったために抜けもあったことでしょう。

日本の電話番号で遮断するにしても、いくらでも作れてしまう現状があるので、執拗にあるwikiへ執着して嫌がらせを繰り返す人に有効な手段とは言えません。

アカウント機能にある編集権限を強化して、管理者一人だけに権限を一極集中するのではなく、チームでwikiを形作っていけるよう拡張するなり再編してほしいと思っています。

8
スレ主 2025/04/12 (土) 22:53:04 修正 d9d8f@6728c

codeの拡張版なら数行〜十数行のコピペに対してとても有用だと思います。ですが、他の方が書いている通り閲覧者向けのゲーム内ギフトコードやパスワードは表に組み込めるよう、インライン型のものを新しく作っていただけるととても使いやすく、見やすいものになると思います。

私は編集者向けに#codeの拡張版プラグイン、
そして閲覧者向けにインライン型の新規プラグインの実装を提案します。中身を表示するかどうかについては、どちらにもメリットがあると感じるので、引数で選択できるようにしてほしいです。

15
款冬華 2025/04/12 (土) 22:30:52 >> 13

WIKIWIKIでは、どなたでも自由にファイルをアップロード・削除できる設計としていますが、削除されたファイルは復旧用にバックアップされ、完全削除は管理者のみが行える仕様となっています。

運営方針として投稿者がアップロードしたファイルをいかなる時も、復元や完全削除できるのは管理者だけとしたいように思えます。そのため、1のみの対応に賛成です。

誤ってアップロードしたファイルを投稿者自身が完全に削除できない問題については、
たとえば「アップロードから一定時間(例:1分以内)であれば、誰でも完全に削除できる」仕組みが、現実的な改善案のひとつと考えています。

例として挙げていただいた第三者のアップロードを誰でも削除できる一定時間を設けることは反対です。投稿者のみ、一定時間を設けてその間だけ削除できるとしても、運営さんが想定しているような短時間・短期間だけという制約をつけるのであれば、反対です。

実際問題として、アップロードミスに気づくのはその場限りではありません。私自身の経験として、数日〜数ヶ月経過してから気づくことも往々にしてあります。短時間だけ投稿者自身の完全削除できる案は一定の効果はありますが、トピック主さんの問題提起する内容が根本的に解決するわけではありません。アップロード者を特定できるアカウント制度を導入するなどして、期間を設けずに完全削除できる形なら賛成します。

運営さんが提示した、ご自身の管理する公開サーバーやzawazawa掲示板、他社アップローダーを併用して、refプラグインで配信元のメディアファイルをwikiwikiへ表示させる方がいつでも完全削除することも容易く、使い勝手が良いです。現状は将来的にメディアファイルを完全削除する可能性もありうる投稿者はwikiwikiにサービスだけで完結させようとするのではなく、他社サービスも併用することを考慮してはいかがですか。

過去のトピックと本トピックを全て閲覧した上で要望者の問題提起を解決するには、投稿者がいつでも期限設けずに完全削除できる機能が必要だと思います。2のシステム改修は安易に着手して欲しくありません。今後、さらに運営が負担を強いる可能性を秘めています。

このトピックおよび、前トピックは議論が白熱し過ぎて丁寧な物言いでも、いくつかのコメントに棘があります。あるwikiwikiとzawazawaをそれぞれ管理する者として言えることは、掲示板の管理者(この掲示板では運営会社)はハンドルネームではない匿名でも、一つひとつのコメントが同一人物であるかどうか把握していることにご留意ください。

議論が白熱しても冷静により引用
なにか意見の食い違いが起こったなら、結論を急がず、じっくりノートで話し合い、結論付けましょう。そうすれば相手はあなたの意図を汲んでくれるでしょうし、あなたも相手の意見を理解して、最後にはよりよい結果になるでしょう。

少し時間をとって冷静になり、言いたいことをよく考えて、それがまとまってから書き込むようにしましょう。一旦書き込んでしまえば、あなたの署名入りのその発言履歴は削除できないまま、ずっと記録に残るのですから。

14
名前なし 2025/04/12 (土) 21:28:54 修正 374b3@7e536 >> 13

運営の方、お忙しいところご対応いただきありがとうございます。


  1. 削除済みページに添付されたファイルについて

こちらの方は、スレ主が要望されたことですので、こちらの方では分かりませんが
ご対応頂ける事と、言う事ですので、よろしくお願いいたします。


  1. 添付ファイルの投稿者による完全削除について

こちらが代替案として、要望させて頂いた事で

「アップロードから一定時間(例:1分以内)であれば、誰でも完全に削除できる」仕組みが、現実的な改善案のひとつと考えています。

アップロードから1分はさすがに短すぎると思いますが如何でしょうか?
確認して考える時間(アップするか?しないか?)と少し時間にゆとりを持たせても
せいぜい半日~1日ぐらいは猶予が欲しいかと思いますが如何でしょうか?

こちらの提案したパスワード設定の件は技術的に難しいのでしょうか?
出来れば、いつでもアップして、いつでも削除できる方が、自由度が増すかと思いますし
必要なくなった添付ファイルも、差し替えではなく各自で責任をもって削除して
新しい物に取り換えることにより、添付ファイルの管理も簡単になります。

結びになりますが、自動バックアップを、否定している訳ではありませんが
そもそも、画像のサイズ間違え画質の不具合等のバックアップ自体必要ない訳です。
管理者は情報を提供して頂いている訳で、その判断を管理者がするのは違う訳です。
その判断は添付ファイルを添付した各自(各々)かと思います。
その為、今回要望させて頂きました。

長々と失礼いたしました、スレ違いの内容にもかかわらず、ご対応頂き有難うございました。
では返信お待ちしています。

7
はやし 2025/04/12 (土) 20:35:49 1eed6@f53e0 >> 5

#codeはブロック型のプラグインなので、表のなかでは使えないか、使えても非推奨になるはずです。
オンラインゲームのサーバ招待やフレンド登録などで使うIDを表で一覧化するような用途も考えられるので、インライン型プラグインとして実装できないでしょうか?

13
WIKIWIKI運営 2025/04/12 (土) 19:47:59 >> 12

ご要望ありがとうございます。

本トピックでは、添付ファイルに関して以下の2つのご要望をいただいております。

  1. 削除済みページに添付されたファイルを削除できるようにしてほしい
  2. 添付ファイルをアップロードした本人が、バックアップも含めて削除できるようにしてほしい

WIKIWIKIでは、どなたでも自由にファイルをアップロード・削除できる設計としていますが、削除されたファイルは復旧用にバックアップされ、完全削除は管理者のみが行える仕様となっています。


1. 削除済みページに添付されたファイルについて

ページ削除後にファイルの確認・削除ができなくなる問題については、状況を把握しており、対応を予定しております。


2. 添付ファイルの投稿者による完全削除について

誤ってアップロードしたファイルを投稿者自身が完全に削除できない問題については、
たとえば「アップロードから一定時間(例:1分以内)であれば、誰でも完全に削除できる」仕組みが、現実的な改善案のひとつと考えています。

こうした変更は運用やセキュリティにも関わるため、引き続き慎重に検討します。
皆さまのご意見もぜひお聞かせください。

アップロードに不安がある場合は、ご自身の管理する公開サーバー等にファイルを置き、そのURLを参照していただく方法もご活用ください。

1
名前なし 2025/04/12 (土) 19:40:17 9fc7e@e3644

不特定多数に編集されたくないけど定期更新があり、凍結で手間が発生するのは避けたいページがあるので賛成します。
現在のタイムスタンプを更新しない機能みたいに、サブパスワードを入力して編集ができるような機能があれば便利だと思います。
親しい意見として378のようにアカウントベースで編集者制限できる機能でも、荒らされるリスクを抑えつつ、編集時の利便性も保てるのかなと思います。

6

私が使用する場合、主にテンプレート、ハッシュタグ、特典コードの共有に使用すると思います。そのためボタンだけでなく対象の表示を希望します。
テンプレートの場合、改行を多く含んだ大きな塊なのでイメージとしては現在文章前に半角スペースを入れることで表示できるpreの状態にコピーボタンがあればいいなと想像していました。
ハッシュタグ、特典コードに関しては、テンプレートと違い、短い文章が複数配置する形式になるので、一つ一つバラバラに配置すると視認性が悪く表で使用できると嬉しいです。
codeプラグインを全く使用していないので、どういったものなのかあまり理解しきれていませんが、大きな文の塊と短い文章両方に使用したいと思っているのでできれば表に使用できるようなものがあれば助かります。

6
名前なし 2025/04/12 (土) 19:00:51 a05f6@6d016 >> 3

返信ありがとうございます。
無料で場を提供していただくのにその運営に広告が必要なことは理解していますし、エロ系広告が出ないだけでも女性ユーザーがほとんどなwikiの管理者としてありがたく思っております。

状況が不明な状態で一月経ち、どういった対応なのかわからず不安を感じていたため、返信いただき嬉しいです。
実現できるかどうかはともかく、今後もこのように言葉をかわし意見を伝えられたらと思います。ありがとうございます。

5
WIKIWIKI運営 2025/04/12 (土) 17:06:33 >> 3

ご要望ありがとうございます。

ご提案いただいた「テンプレートなどをコピーしやすくする機能」について、実装そのものは技術的に可能です。

運営としては現時点で、既存の #code プラグインにコピーボタンを右上に常時表示する形での対応を想定しています。
この方法であれば、すでに多く使われている書式を拡張しながら対応でき、操作性もシンプルに保つことができます。

ただしこの場合、ソース(マークアップ)は画面上に表示された状態での提供となり、表の中などインライン要素として埋め込む形式には対応できません。

このような前提を踏まえつつ、以下の点についてご意見をいただけますと幸いです。

  • コピー対象の内容を画面上に表示したいか、それともボタンだけで十分か
  • テンプレート活用や初心者支援など、主な利用目的

想定されている使い方や、特に不便を感じている点なども共有いただければ、今後の改善検討の参考にさせていただきます。

引き続き、ご意見をお待ちしております。

5
WIKIWIKI運営 2025/04/12 (土) 13:43:54 >> 3

失礼しました。

運営側で、広告のカテゴリや個別の広告を制御・ブロックすることは可能です。

広告の露出については、できるだけ少なくなるよう日々調整しておりますが、広告単価の変動や世界情勢の影響などにより、運営コストとのバランスをとる必要がある状況です。
該当の広告も、運営側で調整を行ったうえで配信しているものです。

サービスを長く安定して継続していくため、最低限の広告表示についてご理解いただけますと幸いです。

また、ユーザー側の設定でも該当広告を非表示にできる仕組み(いわゆるオプトアウト)があります。
オプトアウトにつきましては、上記の「広告について」をご確認ください。

特に、露出の高い広告(動画広告、全画面広告、追尾バナーなど)には適用できるようになっています。
広告が気になる方は、このオプトアウト機能をご活用いただけますと幸いです。

なお、オプトアウトの詳細につきましては、機能の性質上、広く明示的にご案内することが難しいため、ご了承いただけますと幸いです。

2
款冬華 2025/04/09 (水) 20:22:54

@wikiwiki
これまで同様のトピックで賛同コメントをいただいています。行・列の片側一方だけ固定ではなく、両立できることで画面外にはみ出すテーブル(表データ)が格段に使い勝手が良くなると思います。近々ではなくても将来的に実現する可能性があるのか、回答をお願いいたします。

参考トピック・賛同コメント
https://zawazawa.jp/wikiwiki-request/topic/220

https://zawazawa.jp/wikiwiki-request/topic/206/2
screen-sticky動作で横スクロール可能にならないと、
正式実装はかなり厳しいように思います。

https://zawazawa.jp/wikiwiki-request/topic/206/18
問題点
screen-sticky + fix-colの組み合わせはできない

18
名前なし 2025/04/09 (水) 19:33:23 9fc7e@a8e20 >> 16

同意します。今までのものを変更するのであれば反論も出るかと思いますが、完全新規の案件であれば欲しい人が賛成と投げるくらいで、そこから議論を進めるには技術的に可能なのかどうかの返答だと思います。

3
名前なし 2025/04/09 (水) 19:29:02 9fc7e@a8e20

賛成です。多くの人が閲覧するため装飾多めでプラグインも多くなるFrontPageやinclude元になるページなどは不特定多数の人が触れるような状態じゃないほうが良いと思う場面もあり、ページ単位で編集者制限をかけられると良いなと思います。
編集凍結という手段もありますが、毎回凍結解除の手間が管理者であっても必要で、不便だと感じています。
誰でも編集できるというのはwikiの良いところではありますが、下手にいじると多くのページで混乱が生じるページが存在するのも確かですので、検討していただきたいです。

12
名前なし 2025/04/09 (水) 18:45:20 62820@7e536

おおよその内容はスレを読んで頂ければお分かりいただけるかと思います。
議論が出尽くしましたので、前スレ(リンク先)も含めて
運営からの可否のコメントをお願いします。@wikiwiki

なお、当スレの内容とは異なる事の様ですが、こちらとしては内容をすり替えたつもりはなく
そうすることにより、管理者も管理しやすくなり、編集する人もさらに利便性を向上できるかと思い
以前にこちらの方で提案させていただいた、スレを代替案として提案させていただきました。
スレ違いの事ではありますがよろしくお願いいたします。

4
名前なし 2025/04/09 (水) 18:05:52 a05f6@ef25c

指定した範囲内の文章をワンボタンでコピーする機能ということでしょうか。
うちのwikiではカード毎の詳細のテンプレが10行以上ある上、プラグインも複数あり}のコピーミスが発生しやすい環境なため、ワンボタンでできるようになるならありがたいです。

3
副管理人(WoTBWiki) 2025/04/09 (水) 14:12:08

@wikiwikiこちらの実装可否についてお伺いできれば幸いです。

17
副管理人(WoTBWiki) 2025/04/09 (水) 14:10:41 >> 15

まずは本トピックにご回答頂けたことに感謝いたします。
また、メンション機能を追加頂いたことで議論に幅が出るようになるかと思いますので、早速利用させていただきます。
一方、>> 16さんのコメントの通り、ただの追加要望ですとそもそも「議論」になりにくいことも想像に容易いかと思います。そういった観点では、メンション機能は補助として運営チームの定期的な介入があると嬉しく思います。

16
名前なし 2025/04/09 (水) 12:08:18 678d2@bf966 >> 15

内容にもよりますが、議論を深めて欲しいなら、
まず運営が、投げられたボールを返さないことには始まらないでしょう。

実際、木主が「長期間経過した例」に挙げているトピックを見ても、
「私も欲しい」という要望がいくつか挙がっているだけで、
議論になっていません。

仕様変更に関するトピックであれば、
賛成・反対意見が出やすいので議論になりますが、
機能追加に関するトピックの場合、
運営が沈黙したままだと、上記の例のようにしかならないと思います。

4
名前なし 2025/04/08 (火) 20:28:35 a05f6@8df25 >> 3

迅速な返信ありがとうございます。私が求めている回答は「ユーザーが広告をコントロールできるか」ではなく、「特定の広告をwikiwiki運営が表示しないように設定することができるのか」についてです。
ご提示いただいた広告についてのページもトピック作成前に読ませていただきました。管理人として積極的に編集し、利用規約に同意した状態の端末だと見る専用のスマホより明らか広告が少なくなっており、運営方の配慮を感じております。

ただ一部の広告で音楽が流れ、元々流しているBGMやゲーム音声より優先されていることにストレスを感じているため、その広告のみ運営サイドでブロックできないかと思い、このトピックを作成させていただきました。
広告についているバツ印からフィードバックを送る機能もありますが、該当の広告にその機能はついておりません。
可能でしたら音楽が流れる広告の停止を運営サイドで行っていただきたいです。

3
WIKIWIKI運営 2025/04/08 (火) 19:40:04 修正 >> 2

ユーザーが広告の露出をコントロールすることは可能です。
まずは、利用規約の下部の「利用規約に同意します」にチェックをお試しください。
広告につきましては「広告について」をご確認いただけたら幸いです。

利用規約
https://wikiwiki.jp/pp/policies

広告について
https://wikiwiki.jp/pp/aboutad