リクエスト広場

1,418 件中 281 から 320 までを表示しています。
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日分)の編集ログを取得したいと感じます。

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

9
款冬華 2025/04/19 (土) 21:47:27 >> 8

以前に言及して運営さんから返答いただいていないので、サイレント修正されたものと認識しています。テスト導入ではない正式導入しているプラグインの変更に関しては、案内して欲しいです。

100件表示されている現在において>> 1>> 8なりの何らかの手法で全タグを見れるようにしていただきたいと願っています。

16
名前なし 2025/04/19 (土) 18:55:03 b4131@c46e3 >> 11

コメントありがとうございます。
タブの仕様に関する個人的意見を以下に示します。

入れ子構造
不要。構造が複雑になる事で処理が重くなってしまう懸念があるからです。

ラベルの任意指定
必須。

ラベル内のWIKI記法
あれば良いですが、どちらでもかまいません。

ラベルのデザイン
使いやすいデザインであれば、どのようなものでもかまいません。

タブの上限
設けるとしたら、10程度が良いと思います。

スマートフォン表示でのラベルの切り替え
個人的にはプルダウン形式が使いやすいです。

8

@wikiwiki
本来のメンション機能の意図するところではないと思うのですが、メンションを送らせていただきます。

本変更について、2024/07以前の仕様であるとtaglistのページがサーバに負荷をかける等望ましくなく、一定件数を越えた際に、Too many tags to display.のエラーメッセージを表示する仕様に変更したのだと認識しております。

ただこの約9ヶ月間、wiki内で利用しているtag自体を一覧したい場面が複数あり、なんらかの形でwikiwiki内の全タグを取得する方法の実装を希望します。
以前のtaglistのように甲に対してtag甲を付与したページを下層に全表示する仕様は必要ありません。
使用しているtagの一覧のみが取得できれば十分です。
・#tagcloud(,cloud=off)を2024/07以前同様に100件でなく全件表示する
・#tagcloudの表示数上限を100としたまま、前/次の100件のページ送りで分割表示する
などの現状の機能の延長線で構いませんので、ご検討をいただきたいです。

1

@wikiwiki
お世話になっております。この件について、以下の点についてお教えいただる部分があれば、ご返答を頂きたいです。
・この不具合を認識しているか。
・この不具合は修正可能なものか。
・本プラグインの仕様や、wikiwiki運営のリソース面から、不具合が解決するのにどの程度時間を要しそうか。

正直なところ、wikiwiki全体のaaプラグインの利用数や発生する状況の特殊性から、対応の緊急性が高い案件とは言えないと感じております。
とはいえ不具合が発生しているのも事実なので、修正にかかる日数を踏まえ、aaプラグインを利用しない形でページの内容を修正するか、現状どおりページを保持しておくかを考えたいです。

4

既存の議論に同意します。編集差分ログはこれまで荒らしへの対応を行う用途で活用することが多いです。
この際、特にUAやIP、ホストなどで絞り込んで特定ユーザの編集履歴を検索する場合は、その日の編集履歴だけではなく上限いっぱい(=90日分)の編集ログを取得したいと感じます。

現状の仕様は検索にマッチする内容は日付ごとで区切って表示され、例えば4/16に検索にマッチする編集差分ログがあるかは4/16のタブを開いてみないかぎりわからない仕様で、運用するのには負担感があります。

日を跨いで一定件数表示をしてくれるのが理想です。
次善として、日付タブに4/16 (20件)のように件数を表示してくれたり、その日付に検索結果がないときはリンクが機能しなくなったりと、現状のUIのままでも確認すべき日付タブが減る方向性のアップデートが考えられます。
いずれにしても、今の編集差分ログを利用して十分な管理を実施するのは、管理人が慈善事業な以上勘弁してほしいというのが正直な気持ちです。

15

レイアウト構成の幅が広がるため、是非とも導入していただきたい機能です。
タブ仕様に関する意見は以下のとおりです。

  • 入れ子構造:どちらでも可
    →要望が多ければ設定可能で良いと思いますが、ソースが複雑になり可読性が下がるので個人的には利用予定はありません。
  • ラベル指定:必要
    →スマホ表示を考慮すると短い文字列などの指定は必須かと思います。
  • WIKI記法:不要
    →改行やリンクなどを記述するとタブ本来の機能を損なう可能性があるため、制限した方が良いと考えます。
  • ラベルのデザイン:希望なし
    →後述のスマホ表示と関連しますが、選択中のタブが分かりやすいものであれば特に希望はありません。
  • タブ数の制限
    →タブ内の表示はinclude想定とのことなので、includeの仕様に合わせる形で良いと思います。
  • スマホ表示について
    →flex_containerプラグインのように、画面幅に応じて動的にタブの行数が切り替わる形式が良いと思います。
3
はやし 2025/04/19 (土) 11:57:56 6d43b@f53e0 >> 2

特定ユーザーの編集を日を跨いで一覧化できないのは非常に不便だし、日付の選択も不便です。

こんな話をしたら怒られるかもしれませんが、ログ画面のURLを手で書き換える(day=の部分に見たい日付を入れる)ことで、特定の日付に直接移動できます。

ttps://c.wikiwiki.jp/wiki/diff-log?day=2025-04-19
                 ↑ここ

2
名前なし 2025/04/19 (土) 08:38:48 a05f6@510a5

同意します。1日ずつ見ないといけないので不便だと思います。
日付の選択も1週間ずつしか移動できず、昔のログを見たいときカレンダー画面で選択するようなものがあったら良いなと思っています。
そこまで使用頻度は高くないのですが、もっと便利になったらいいなとは思います。

1
副管理人(WoTBWiki) 2025/04/19 (土) 02:30:24

こちら、他の管理者ユーザーの方が居ればご意見を伺いたいです。

10
副管理人(WoTBWiki) 2025/04/19 (土) 02:03:37

>> 9さんと概ね同様の意見です。
コード型はページ(の一部)テンプレートで、インライン型は何らかのID(wiki外で使用)などで利用しやすいかと思います。
もともとページテンプレートなどの拡張として希望したこともあり、どちらか一方を優先して実装するのであれば#codeから拡張したコード型を希望します。
イメージとしてはテック系サイトで用いられるコードブロックのようなものです(quitaなどが参考になるかと思います)。

14
副管理人(WoTBWiki) 2025/04/19 (土) 01:57:02 >> 10

タブ機能は私も所望します。
その上で運営チームからのコメントを踏まえて個人的な意見を羅列します。

・タブの中にさらに別のタブを配置するような構成は必要か?(いわゆる「入れ子構造」)
→不要です。タブ形式の場合、includeよりも入れ子化すると見づらくなるのでは?と思っています。
・タブのラベルは任意に指定できるべきか?
→必要です。そもそもラベルが変更できないとタブ機能の意味が無いかと思います。文字・背景色などは無くて構いません。
・ラベル内でWIKI記法を使えるようにするか?(※あまり許容したくないと考えています)
→中立です。基本的には欲しいですが、無くても許容できます。
・ラベルの見た目やデザインはどのような形式が望ましいか?
>> 12さんと同じく見やすければ特に希望ありません。
・タブの数に制限は必要か?
→特に希望はありません。極端に多くても読み込み速度を損なうだけかと思いますし。
・スマートフォン表示ではラベルをどのように扱うのが適切か?
→プルダウン形式だと一番見やすいかと思います。

16
副管理人(WoTBWiki) 2025/04/19 (土) 01:47:30

>> 15さんの意見に賛同します。
私が管理しているwikiにおいてもサブパスワードの発行には一定回数以上の編集参加を条件としているものの、現状の完全匿名仕様ですと確認に労力を割くことになります。
一方でアカウント間の連絡については中立的な立場です。wikiは個人間のコミュニケーションを取る場ではなく、他のSNS等で十分代用可能と考えているためです(あれば便利かとは思いますが)。
この仕様はzawazawaと同じかと思いますので、近い機能、ひいてはzawazawaアカウントと連動するようなシステムがあれば個人的には重宝します。

15
clusial 2025/04/17 (木) 02:25:33

>> 13の「匿名が基本、ただし管理メンバーはアカウント必須」という形態には賛成ですが、今多く言われている「管理人・副管理人のみがアカウントを持てる」ではなく「一般の利用者も希望すればアカウントを持てる」の方が良いのかなと個人的には思っています。

私が参加しているwikiの中に副管理人を決める条件としてwiki内以外の連絡先を持っていることやwikiに参加してから○日以上などの条件があるので、そういった統計情報などをアカウントページに表示させることで管理メンバーが副管理人などを選ぶ際の参考にできると思います。

また、アカウントページにコメント欄があるとwiki内で匿名での質問や連絡ができ便利だと思います。


アカウント機能が実装された場合の話ですが、アカウント保有者の場合は編集差分ログのネットワークID・ブラウザIDの部分がアカウント名に変わるようにしてほしいです。

14

現在zawazawaで実装されているグループ管理画面をベースに、>> 12で提案されているような
wiki独自の要素を組み込んだシステムにするというのは技術的に可能なものでしょうか。

wikiとzawazawaを併用して管理するケースは多いかと思いますので、
ある程度UIに共通性を持たせることができれば管理の利便性向上は図れるのではないかと考えます。

なお、編集者の公開・非公開という点に関しては、編集差分ログ機能によって同様の内容が既に実装されているため、
改めて機能を設計する意義は薄いのではないかと感じますが、いかがでしょうか。

13
あもお 2025/04/16 (水) 23:17:19 df39e@e1ab0 >> 12

念のためですが、私は「アカウント作成が基本、ただし匿名でも編集可」というより「匿名が基本、ただし管理メンバーはアカウント必須」という形態にして欲しいと思っております。理由は③に記したとおりです。
つまり、私の思う「アカウント」は「管理者」や「サブパスワード」の発展版に近いです。

ただ、もし前者(アカウント作成が基本)とする方向で議論が進んだ場合でも、主張内容はおおむね同じになります。

12
あもお 2025/04/16 (水) 22:38:28 df39e@e1ab0

運営の方からの返信や皆さんの意見を拝読し、私なりに考えてみました。
具体的には以下のようなシステムを提案します。



アカウントは名前のみ。プロフィールや編集ランキングなどSNS的機能は不要。ただし、管理の円滑化のために最低限のアカウントページは作り、「管理しているWiki一覧」「連絡先」(セキュリティ上問題なければ)は表示できるようにすべき。
また、Wiki内に一般利用者が閲覧可能な「管理メンバー一覧」ページを作り、そこから管理メンバーへの荒らし通報や問い合わせなどができると望ましい。
編集の公開については、>> 10より

誰が編集したかを明確にしつつも、誰が編集したかの情報は権限を持つメンバーだけ閲覧可能にするという設定が欲しいです。また、設定の変更で全ての利用者に誰の編集かを公開出来るようにする(誰の編集かを公開するか非公開にして一部メンバーだけ閲覧可能にするか選べるようにする)と、柔軟性があってベストな気がします。

こちらの意見に全面的に賛成。
公開する設定になっていてもアカウント名を隠した編集も選べると嬉しい。


権限は、ZAWAZAWAと同様に「オーナー」「アドミニストレーター」(いずれも従来の管理人権限相当)、「モデレーター」(従来のサブパスワード権限相当)の3段階とする。
また、正直カタカナの名称はわかりづらく感じるので、できればそれぞれ「管理人」「共同管理人」「副管理人」としてほしい。(以後、便宜的にこちらの名称を使用させていただきます。また、"管理メンバー"はこれら3つの総称です)
副管理人の権限は管理人および共同管理人がある程度選べるようにすると柔軟性があって良さそう。


ZAWAZAWAで言うところの「一般メンバー」は不要。
運営の方がおっしゃるように、「誰でもすぐに編集できる」というオープン性と匿名性はWIKIWIKIの大きなメリットである。私の管理するWikiでも、「匿名でアカウントなしでも気軽に参加できるのが良い」という声が、低年齢層に限らず見受けられる。
一時期な荒らし対策としては「メンバーのみ編集可」というモードは確かに有効なのかもしれないが、それが常態化すると閉鎖的で新規参入のハードルが高いWikiになってしまいかねず、本末転倒である。
アカウント制度はあくまでも管理メンバー向けのシステムとし、一般利用者は従来と何ら変わりなく利用できるようにしたい。
もちろん、副管理人などに昇格する際はアカウント作成が必須になるが、それはむしろ信頼のない人物が権限を持ってしまうリスクを減らせるので良い。


前項で一般メンバー制度を否定した代わりというわけではないが、荒らし対策は大幅に強化し、気軽さと安全性を両立したシステムにしてほしい。
例えば、次のような機能が挙げられる。

・管理メンバーは凍結ページを編集可(≠凍結解除)
・「管理メンバーのみ編集可」機能 (どちらも>> 5から)
・大規模な荒らし時のロールバック機能 (>> 11から)
・ページ名NGワード設定機能
・荒らし通報があると管理メンバーのアカウントに通知が行く機能


その他、追加でこのような機能もあるとありがたい。

・アカウントとWikiの紐付けによるシームレスな移動(>> 7から)
・管理メンバー同士で話し合える機能(外部SNSのグループチャットなどを使わずに済む)
・管理人だけができる機能の副管理人への拡大(②の項で書いたように選択制だと良い)
・問題のあるアカウントを運営に通報する機能


以上、長文で申し訳ありませんが、私からの提案です。

11
款冬華 2025/04/16 (水) 20:36:23
  • それとも、機能だけを制御する「匿名の権限アカウント」で十分とする

こちらに一票です。私がアカウント制度の導入を求めている理由として、現行のサブパスワードはあくまで管理人の補助のため、管理パスワードも含めて編集権限の強化を求めています。凍結中でもパスワード保持者は編集できたり、大規模なページ削除があっても運営に頼らずに荒らし行為が起きる前までにロールバックできたりなどです。現状はどの作業もひとページづつ手作業で行う必要があります。

>> 3の方が言うようにFrontPageやお知らせページの凍結しているページは匿名利用者に編集させず、管理側の利用者だけ編集できるといった編集機能の強化・拡張をお願いしたいです。

また、当Wikiではないのですが幾つもの荒らし対策を回避して執拗に執着して荒らす利用者がいます。日本の電話番号取得もフリーSNSサービスは除いて昔と違い、低価格で複数回線の取得が容易になっています。このことから、執拗な荒らし行為を完全排除のために特定のページあるいは特定のディレクトリ、特定のWikiごと、アカウントなしでは編集できないような仕組みを望みます。

さらに以下の管理パスワードを所持する管理人だけができる以下の編集に関わる機能もサブパスワードなり、アカウント所持者に権限を付与してメンテナンス管理しやすくなるようにチームを形成したいです。ご検討いただければ幸いです。

7
名前なし 2025/04/16 (水) 20:11:12 1ac7b@626b9 >> 5

参考までに、ユーザ側での対処法を記します。

>> 2のコメントに記載されているInterWikiNameの記述を以下のように修正することで
リンクが機能するようになります。
(下記の内容をそのままコピーして差し替えると楽です。)

* 拡張InterWikiName
-[./::cmd/add?page= 新規]
-[./::cmd/add?page= New]
-[./::cmd/read?page= 参照]
-[./::cmd/read?page= View]
-[./::cmd/edit?page= 編集]
-[./::cmd/edit?page= Edit]
-[./::cmd/backup?page= バックアップ]
-[./::cmd/backup?page= Backup]
-[./::cmd/unfreeze?page= 凍結解除]
-[./::cmd/search?word=$1&type=OR 検索]
-[./::cmd/search?word=$1&type=OR Search]

なお、本トピックは既に[解決済み]扱いになっていますので、
ホームの案内に書かれているとおり、新規にトピックを作成すると運営の目に留まりやすいかと思います。

10
Lanotawiki管理人 2025/04/16 (水) 19:28:05

複数人での管理を容易にしつつプライバシーのことも考慮したいので、誰が編集したかを明確にしつつも、誰が編集したかの情報は権限を持つメンバーだけ閲覧可能にするという設定が欲しいです。また、設定の変更で全ての利用者に誰の編集かを公開出来るようにする(誰の編集かを公開するか非公開にして一部メンバーだけ閲覧可能にするか選べるようにする)と、柔軟性があってベストな気がします。

またアカウント制については、既存のサブ・パスワード機能をベースにして、個別にサブ・パスワードが持つ権限を変更出来るようにすることで十分実現可能だと思います。

他社サービスの用にユーザー毎に権限を変更して、編集権限だけ持つ一般ユーザーとwikiの管理の権限を持つ人ををユーザー毎に分けたり、管理権限を持つ人でも、バックアップの削除や規制の実施等の権限の付与を細かく操作して、副管理人にはほぼ全ての権限を与えて、そこまではいかないけど管理メンバーではある人には一部の権限だけ与えるなど、柔軟性のある管理を行えるようにする機能があると理想的です。

31
名前なし 2025/04/16 (水) 19:09:15 修正 72531@7e536 >> 30

お忙しいところ、ご対応有難うございます。

こちらとしては、かなり需要があると思っていましたが
仰るように、全体としては否定的な意見が多かったみたいで
皆さん、荒らし・暴走などを恐れらているようです。
非常に残念に思います。

結びになりますが、長々とお付き合い頂き、ご返信有難うございました。
今後、何らかの形で、対応出来ることがありましたら、よろしくお願いいたします。


お付き合い頂いた皆様へ

長らくお付き合い頂き有難うございました。
また、ご縁がありましたらよろしくお願いいたします。

なお、スレ主様におかれましては
本題をすり替えたような事になってしまい大変失礼しました。
改めてお詫び申し上げます。