リクエスト広場

以下の手順はどうでしょう。

InterWikiNameに追加→-[./?plugin=template&refer=（エンコード済テンプレート名）&begin=0&end=999&page= フォーム左に表示したい文字]

フォームを置きたい場所に追加→#lookup(フォーム左に表示したい文字,編集)

バックアップ一覧の使いにくさは日付昇順でリストされるため、履歴が200件もあると最新行が画面外にあり、スクロール操作をしないと確認やクリックができてないことだと思います。以下に操作による改善策を挙げます。

• マウスジェスチャー機能
  私の場合は右クリックしながらマウスを下に動かすと画面下までスクロールする設定をつかってます。逆に右クリック+上の場合はTop。使用はPCとブラウザー環境によりますが。
• Footerへのリンクを仕込む
  メニューやヘッダーに[[↓>#footer]]とか記述しておけばリンクをクリックするとページ下部に飛べます。

サイト全体の編集履歴を追うために各ページのバックアップ一覧を呼び出して編集があったのかなかったのか、あったならばその内容が適切かを確認してるのでしょうか。

RecentChangesの右上にある"最近の投稿を詳しく見る"(diff_log)のほうが楽だと思います。日ごとの編集差分を90日分の履歴が追えます。
ネットワークID、ブラウザーID、どの機能で編集したかもわかるので対象も絞り込めます。ただしdiff_logは管理者が機能を有効にする必要があります。
またあなたが管理者あるいはサブ管理者であるならば、コントロールパネルの編集差分ログ機能からもっと詳細な情報を得たり検索機能が使えます。リンク
例えば不適切な編集のIPアドレスやブラウザーの編集履歴を検索できます。

ただ、検索結果は日付ページ単位でしか表示されないので編集があった日付を一つずつ選択と目視で探し出す必要はあります。この機能の今後の改善点として週単位、月単位、以前、以降、日付の期間指定に対応してもらいたいところです。負荷を下げるためにあえて絞られてるのかもしれませんが。

どっちでもいいけど、どちらかと言えば既存のプラグインを拡張する方がいいな。
それにプログラミングの原則として、機能は最小単位に抑制した方がいいハズ。

そうでなければ無駄な機能を実装せざるを得ない状況が発生してしまうハズ。
だから例えばウィジェットのバリエーションを増やすとか、追加したい機能を もっと極限化するためにニーズを整理した方が良いんじゃないのかな。

 #accordion(&color(Blue){たちつてと};,*,close){{
 なにぬねの
 はひふへほ
 }}

だと、うまくいかないぞぅ？

めっちゃ使いやすい

https://pukiwiki.osdn.jp/?自作プラグイン/aapro.inc.php
Pukiwikiのやつだけどこれじゃいかんのか？

Ctrlキーを押しながらソートボタンをクリックでリセット
Shiftキーを押しながらだと複数列ソート
上記の機能はPCのみですが、管理しているWIKI閲覧者の大半がモバイルなので、
何らかの手段で行えるように対応を希望します。

リセットする機能は特に汎用性が高いと思われます。

対応ありがとうございました。かなり使いやすそうです

いくつかのWikiを巡回してみたところ、サブディレクトリ毎にMenuBarページを作成して
通常のMenuBarページなどをincludeしていました。
当Wikiでも試したところ、特に不具合が発生しませんでした。

不具合は直っていませんがこの代替案を採用して管理していくので、
タグを解決済みに変更してスレッドを締めさせていただきます。

現在のrenameコマンドは複数ページを一括で置換する機能が含まれてるのが理由だと思います。個別ページ変更のみ開放して、正規表現置換は従来通り管理者権限で良いのですが。ただrenameは標準機能なのであまりそこに手を加えるたくないかもしれません。そうであるならば従来のは残して、一般向けのrename2とか新たに作る必要が出てきます。

>> 18
>> 15~17は問い合わせをした文面を分割して投稿しただけと思います。
またよく覚えていないので推測ですが、リクエスト広場の文章は2/26日に更新されており、恐らくこの問い合わせを受けてその注意書きを追加したものと思います。

3/3付でhack9 Wiki*にてSubMenuのあるページを全て確認したところ、
上記の誤った内容が下記のようにいずれも変わっていました。

• GHost94ではなく、hacker9/SubMenuの誤表示をしている
  1.GHost94/SubMenu

• GHost9ではなく、GHost92/SubMenuの誤表示をしている
  1.GHost9/小ネタ
  2.GHost9/3階層
  3.GHost9/4階層
  4.GHost9/非常階段

• hackerrankingではなく、hacker9/SubMenuの誤表示をしている
  1.hackerranking/アイテム効果
  2.hackerranking/小ネタ
  3.hackerranking

• GHost93/SubMenuが参照されていない
  1.GHost93/SubMenu
  2.GHost93/アイテムリスト
  3.GHost93/小ネタ
  4.GHost93/簡易チャート

• GHost9/SubMenuが参照されていない
  1.GHost9/アイテム効果
  2.GHost9/1階層
  3.GHost9/2階層
  4.GHost9/5階層

• どのSubMenuの参照も不要なのにhackerranking/SubMenuの誤表示をしている
  1.操作方法

賛成です。

↑のプラグインマニュアルはpukiwiki汎用のものなので、
wikiwiki専用のマニュアルページが欲しいです。

例えば、自分が便利に使用しているプラグインの1つにcountdownがありますが、
記載がない上に、wikiwikiに実装されているものは
上記pukiwikiオフィシャルの記載と微妙に仕様が違うんですよね。

実装されているものを全てまとめたページがあれば便利です。

前回、指摘させて頂いたhack9 Wiki*の箇所がGhost94/ミッション進行方法が直っておりました。
参考にしているWikiを再確認したところ、ほかにも複数のページで別ページのSubMenuを参照
または、対象となるSubMenuを参照していないページが確認できたのでお伝えします。

• GHost94/SubMenuの誤表示をしている
  GHost93/アイテムリスト
  GHost93/アイテム効果
  GHost93/小ネタ

• GHost93/SubMenuの誤表示をしている
  GHost9/小ネタ
  GHost9/1階層
  GHost9/2階層
  GHost9/3階層
  GHost9/4階層

• GHost92/SubMenuの誤表示をしている
  GHost9/アイテム効果
  hackerranking/アイテムリスト
  hackerranking/アイテム効果
  hackerranking/小ネタ
  hack9/hackerranking

• GHost9/SubMenuが参照されていない
  GHost9/SubMenu

• hacker9/SubMenuが参照されていない
  hacker9/京都御所

• hackerranking/SubMenuが参照されていない
  hackerranking/SubMenu

pukiwikiのrenameプラグイン（コマンド実行）に管理者権限が必要なのは以前から知っていましたが、
理由について考えたことはなく、あらためて考えて自分なりの推測を立てたのですが、
どうやら間違だったようです。（a3b27@c2ee0さんの検証・指摘）

規制理由も???ですが、運営の塩対応も???ですね（笑）
（個別に回答しておりません…って、どこぞの国会答弁みたいです😷）

自分はそれでもいいですが、トピ主のpaaa!さんは納得しますかね…
皆さんは理由、知りたくありませんか?

権限のないユーザーのWikiデータ復元操作の簡略化を考慮した結果、機能を制限していると思われます。
どんなに議論が活性化してユーザーからの要望が多くても回答するか、あえて未回答のままとするか、
また導入するか保留のままとなるかは原則、運営の方針によります。

以下、トップページより引用

WIKIWIKI運営がまれに参加することがあります

基本的にはディスカッションに参加しません。
運営が回答すると、ディスカッションが終わってしまうことがあるからです。
自由な発想で参加いただけたらうれしいです。

なるほど。ご回答ありがとうございます。

理由は以下の「サブ・パスワード」の説明ページにあるように、
WIKIの破壊を行えないようにするためではないでしょうか？

RenameLogに残るとはいえ、何回もリネームしシャッフルされてしまったら復旧は困難でしょう。
管理権限で一時的に許可する仕様にしても、管理者がすぐにリネーム不可に戻すことができるとは限りませんし、それならリネーム依頼を受けてから管理者が自分のペースでリネームした方が安全で楽だと思います。

コントロールパネル/サブ・パスワード
https://wikiwiki.jp/sample/-s/b1de97fc

以下引用

「サブ・パスワード」

管理機能の一部が利用できるお手伝い用のパスワードです。

• 使える管理機能は安全です。WIKIを乗っ取ったり破壊することはできません。
• コントロールパネルの操作は操作ログに記録されお互い確認ができます。
• いくつでも作成することができ、いつでも削除ができます。

サブ・パスワードでできること

WIKIの凍結と解除と一部のコントロールパネルの操作を「サブ・パスワード」を利用して行うことができます。
文字列の一括置換やバックアップの削除などWIKIに致命的なダメージを与える操作はできません。
コントロールパネルで操作ができる機能は下の比較表をご確認ください。

過去に作成されたページは除外する仕様なのではないでしょうか？
削除したページを復旧して「RecentCreated」に反映されたら見にくいですもんね。

ほとんどのWikiで影響ないとは思いますが「TEST」というページを作成したところ、
RecentCreatedのリストに反映されていませんでした。

「てすと」は反映されました。

解決されたようでしたので、検証したところ全角と半角ともに反映されていました。
ご対応いただきまして、どうもありがとうございます。

追加されたみたいですね

トップに「🙇‍♂️お問い合わせはお控えいただきますようお願いいたします」とありますししつこくするのは…

ZAWAZAWAで議論したところ、結論の見通しがたたず、問い合わせをさせていただきました。大変申し訳ございませんが、やはり回答していただきたいと存じ上げます。

いつも安定したサービスをご提供していただきありがとうございます。
質問ですが、
・なぜページリネームは規制の対象になっているのか
・今後、規制の対象外になる可能性は無いのか
答えていただければ幸いです。
 https://zawazawa.jp/wikiwiki-request/topic/59

WIKIWIKI.jp*運営チームです。

申し訳ございません。

「助け合い掲示板」や「リクエスト広場」の投稿内容につきまして、
運営から個別に回答しておりません。

ご理解いただけたら幸いです。

できれば結果（規制理由と解除の可能性）について報告していただけるとありがたいです。

（運営とのやり取りに使用されたURLを示されてもパスワードロックが掛かっていて見れませんし、
運営の許諾を得ずにパスワードを公開するのはお薦めしません）

問い合わせてみました。
リンク

これは本当に解決されていますか？
実際に試しましたがcontentsxを利用時、preで囲んだ範囲に*を記述した部分は
見出しとして認識されアンカーが付与されました。

別に読まない人は読まなくても良くて、書いてありましたよね？というポジションの証拠に使うのに1番目立つfrontページに書かないといけないコンテンツと関係の無い注意書きが増え続けることを避けたいというだけで、私はそこまでのものは求めてないです。

編集上の注意ページを用意していても、気づかない方や面倒で読まない方は一定数います。
スマホや保険のWEBサイト契約のように、「WIKI独自の注意ページを読みました」という一文の前にあるチェックボックスへ、レ点チェックを入れないと編集フィールドが非アクティブのままという機能があってもいいと思っています。

賛成です。
そのWiki独自のルールや記述方法もあるでしょうし、1番手っ取り早く見てもらえるのはやはりスレ主さんの言う「注意書き」なのだと私も思います。

ブラウザで文字を大きくしたら拡大しなくなりました。ありがとうございます。

iPhoneの仕様で、文字の大きさが16pxより小さいと入力フォームに入力を開始する時(フォームをタッチしてキーボードを出した時)に勝手に拡大されます。

この仕様とwikiwikiの文字サイズによって編集時に毎回拡大され、行の端の方を編集するために拡大を戻さないといけなくなっています。

そこで、拡大されないように編集画面(?cmd=edit)の入力フォーム(wikiの本文のテキストが書いてあるところ)の文字サイズが16px以上にしてほしい、という要望でした。

文字サイズが16px以上なら勝手に拡大されないです。

表示画面の文字サイズはsizeプラグインを使えば16px以上にもできますが、編集画面の文字サイズはできないので、要望としてここに書きました。

そうなると、やはり運営に理由を問い合わせてみるほかなさそうですね。
ディスカッションが目的の掲示板とはいえ、推測でやっていても不毛ですから…

• なぜページリネームは規制の対象になっているのか
• 今後、規制の対象外になる可能性は無いのか

木主に問い合わせてもらうのが一番ですけど、
（やりたくないなら）代わりに自分が問い合わせて、ここで結果報告でもいいです。
paaa!さん、どうしますか?

当方が利用しているWikiではいくつかリネームされたページがありますが、RenameLogでリネームされた日時と該当ページのバックアップファイルの日時を見比べた所、リネーム前のファイルは維持されており表示もされることを報告しておきます。

また削除されたページの編集差分ログ(diff_log)、添付ファイル、バックアップが存在し続けることを確認しております。
ただしアクセスは面倒くさい手順となります。(添付ファイル(画像)のrefによる表示は通常通り出来ます。)
編集差分ログは日数経過で自動消滅しますが能動的に削除することは出来ませんし、添付ファイルやバックアップファイルについては管理者権限でしか削除できません。
WIKIWIKIはデータの喪失に対してかなり配慮されているように見受けられます。

「ページリネームと同時に旧ページ名時のバックアップが消滅」というのはあくまで自分の推測ですが、
仮に事実だとして、消滅しないようにできるなら、既に対処済みだろうと思います。
そういった理由なしに、ページのリネーム如きを規制する必要性がありませんし、
内部処理上、どうにもできないので規制してますゴメンナサイと考えるのが自然です。

上記の手法で荒らしにwikiを破壊されても、
管理ユーザーがdumpプラグインを用いて自身のPCにこまめにバックアップしていれば元に戻せるかもですが、
そんなことをしている人はあまりいないでしょうし、
そもそもそれが可能なのは管理ユーザーだけなので、それを前提にするのもナシでしょう。
事実上管理者不在状態のwikiなど珍しくありませんし、
自動でバックアップされ「ユーザー誰でも」簡単な作業で修復できることがwikiにとっては重要なのです。
（と、自分は思います）

それと訂正を一つ。
「面倒に関して差はない」と書きましたが、
旧ページ自体にたくさんの画像ファイルを添付している場合などは、
それを新ページもしくは別の場所に移す必要があるので差は出るでしょうね…

繰り返しますが、上記はあくまで自分の推測で、全く別の理由だったりする可能性もあるので、
正確な理由が知りたいなら、運営への問い合わせをお薦めします。
（できれば結果を報告してもらえると有り難いです）

バックアップが消えない仕様にするのはどうでしょうか。

文字を今よりも大きく（16px以上に）して欲しいという要望なのか、
編集画面で勝手に拡大しないで欲しいという要望なのか、よく解りませんが、
（文面では前者、タイトルでは後者）
両者は本来別のものです。

文字の大きさに関しては、過去に別の方のリクエストがあったかと思います。
基本文字サイズが12～14pxでは小さいので、設定可能範囲を拡大して欲しいというもので、
コントロールパネル上のオプションであれば何も問題はないかと思います。

しかしデフォルトで16px以上にして欲しいというのは乱暴な話だと思います。
（そういう事ですよね?）
全てのwikiが影響を受けますし、多くのwikiがカラム幅を固定しているため、
1行に表示可能な文字数が減って表などのレイアウトが崩れるなど混乱必至で、
個人的にも大変迷惑です。

勝手に拡大云々に関しては、wikiwikiの機能ではなく、ご使用のiPhone側の挙動ですが、
（自分のAndroid & Firefoxではそのような事は起こりません）
wikiwikiさん側で編集画面をいじることで解決できる可能性もあるかもなので、
運営に直接問い合わせてみたらいかがでしょうか。
（あるいは、ご使用ブラウザのフォントサイズ変更などで挙動が変わるかもしれません）

話はズレますが、wikiの文字が小さくて見づらい場合は、
PCでもCtrlキー + マウスホイール操作でスマホのピンチイン/アウトと同じ事ができます。