対応ありがとうございました。かなり使いやすそうです
いくつかの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運営がまれに参加することがあります 基本的にはディスカッションに参加しません。 運営が回答すると、ディスカッションが終わってしまうことがあるからです。 自由な発想で参加いただけたらうれしいです。
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キー + マウスホイール操作でスマホのピンチイン/アウトと同じ事ができます。
それは>> 7で書いたのと同じです。 ですが結局現在のInterWikiNameはlookupからページ名を持ってこれないので実用的ではないのです。 なので>> 7で書いたようにInterWikiを改造する必要があるのです。
以前、lookupプラグインとlsxプラグインを組み合わせているのを見たことがあります。 あまり詳しくないので誤り等あればどなたか補足お願いします。
１．「InterWikiName」ページに下記を記入 -[./?cmd=lsx&prefix=ページ名,include=(filter=$1) interwikiname] utf8
※「ページ名」は検索したいページの名前、「interwikiname」は任意の文字列 ※「interwikiname」と「utf8」の手前にはスペースを入れる
２．検索フォームを置きたいページに下記を記入 #lookup(interwikiname,ボタン名,入力欄の初期値)
※「interwikiname」は1.で記入した任意の文字列 ※「ボタン名」と「入力欄の初期値」はそれぞれ任意の文字列（省略可）
現状でも後述のようなことができます。それぞれのリンク先に飛んで結果を確認してください。 ただし現在のwikiwikiでこれをプラグイン機能では実現できません。 つまり閲覧者が検索ボックスに任意の単語を入力して、かつ任意のページあるいは任意の区間を限定してという条件ではできません。 しかしwikiwikiのシステムに若干の手を加えてもらえればこれは可能になると思います。かつその改造がなされればこれ以外にもいつくかできることが増えると思われます。そんなに難しくないと思ってます。新しいプラグインは不要でInterWikiの連携を良くするだけです。
ページ内検索の件だけでは限定的な要望ですが、この対応ができれば併せて以下の問題も解決できる見通しになります。
結局何がどうなればいいのかは、話が細かくなるので私が直接wikiwikiさんに話を持っていきます。 今回の検索の件がなくても以前不便に思ったところでもあるので。
■ページ内検索色々 以下特定のページを検索した結果の例を挙げます。実際にはこれをプラグインの検索ボックスの設置で実現させる必要があります。仮にそれができたときの結果のイメージです。これ以外の表示も色々できます。
検索対象の元のページ 実験的に以下のページを検索します。 元ページのリンク
上記ページの特定の文字だけ検索する さっきのページの全文章に対して"。"を検索させます。 キーワードが"。"なのは他に適当にヒットするワードがなかったからです。 accordionの中も含めて全部ハイライトされます。 検索結果のリンク
キーワードを含む行だけ検索する ページ内から"。"を含む行だけ抽出します。ハイライトも付けます。(付けないことも可能。) accordionの行には"。"が無いので機能が取り除かれます。 検索結果のリンク
特定の区間だけ検索する 検索区間を"使用例"の見出し内だけ絞り込みます。前述の検索よりさらに絞り込まれてます。 検索結果のリンク 区間の指定の仕方は色々できます。 見出しは名称で指定したり、レベル別、先頭から何番目と何番目、どの見出しより後とか、色々できます。 ただ閲覧者側に選択の自由はなく、設定者側が予め設定を決めておく必要があります。
ソース文を表示して検索 ソースコードを読み取り専用で開いて、キーワードをハイライトします。 検索結果のリンク
特定の行だけ検索する 例は書きませんがキーワードを含む表だけとか、リスト文だけとか、決まった表現を含む行だけに検索を絞り込めます。 これは閲覧者が検索時に自由に設定できます。正規表現の理解が必要です。
foldやaccordionを開いた状態で表示と検索 foldやaccordionを開いた状態でハイライト検索ができます。ただページの方にあらかじめ仕込みが必要です。なので上記Sampleページ(編集不可)ではできません。
代替方法として次の2つを思いつきました。
やり方がスマートとは言えないので、指定した範囲のみの検索ができるに越したことはないと思います。
説明不足ですみませんでした。コントロールパネルは別々にしてほしいですが、いちいちログアウトして、ユーザー名入力して、パスワード入れて…という操作が煩わしいです。なので、同じアカウントで管理できるけども、サイトごとに設定を変えられるようにする、というようなものをイメージしています。
koishibaさんありがとうございます。 利用者というのは閲覧者のことを指します。 今回僕が利用する目的は、wikiwikiに載っている膨大な量の一覧リストから特定のものだけを閲覧者が検索できるようにするためです。 サイト内検索だと、他のページにも同じようなものがあるのでわかりづらく、ブラウザ側の検索機能だと、他のブロックにも同じようなものもあるので、これも然り。 ただ、2ブロック、というパターンもあるので、accordionのプラグインと同様に範囲を設定できるようにしてほしいです。 他のwikiでも、特にゲーム攻略では、特定のものを検索するのがめんどくさい（別のところに飛んで行ったりする）ので、このプラグインも用意したほうがいいと思っています。 （contentsのプラグインがありますが、それでも多いので、もっとコンパクトにしたほうがいい。）
こんなの実装されていたんですね。ありがとうございます。 公式さんぷるwikiのほうにも紹介を追加して欲しいところです。
以下でできます。
#contentsx(depth=1:2)
上記を含め関連プラグインの仕様 http://pukiwiki.sonots.com/?FrontPage
tag lsx contentsx includex ecache
対応ありがとうございました。かなり使いやすそうです
いくつかの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データ復元操作の簡略化を考慮した結果、機能を制限していると思われます。
どんなに議論が活性化してユーザーからの要望が多くても回答するか、あえて未回答のままとするか、
また導入するか保留のままとなるかは原則、運営の方針によります。
以下、トップページより引用
なるほど。ご回答ありがとうございます。
理由は以下の「サブ・パスワード」の説明ページにあるように、
WIKIの破壊を行えないようにするためではないでしょうか？
RenameLogに残るとはいえ、何回もリネームしシャッフルされてしまったら復旧は困難でしょう。
管理権限で一時的に許可する仕様にしても、管理者がすぐにリネーム不可に戻すことができるとは限りませんし、それならリネーム依頼を受けてから管理者が自分のペースでリネームした方が安全で楽だと思います。
コントロールパネル/サブ・パスワード
https://wikiwiki.jp/sample/-s/b1de97fc
以下引用
「サブ・パスワード」
サブ・パスワードでできること
過去に作成されたページは除外する仕様なのではないでしょうか？
削除したページを復旧して「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キー + マウスホイール操作でスマホのピンチイン/アウトと同じ事ができます。
それは>> 7で書いたのと同じです。
ですが結局現在のInterWikiNameはlookupからページ名を持ってこれないので実用的ではないのです。
なので>> 7で書いたようにInterWikiを改造する必要があるのです。
以前、lookupプラグインとlsxプラグインを組み合わせているのを見たことがあります。
あまり詳しくないので誤り等あればどなたか補足お願いします。
１．「InterWikiName」ページに下記を記入
-[./?cmd=lsx&prefix=ページ名,include=(filter=$1) interwikiname] utf8
※「ページ名」は検索したいページの名前、「interwikiname」は任意の文字列
※「interwikiname」と「utf8」の手前にはスペースを入れる
２．検索フォームを置きたいページに下記を記入
#lookup(interwikiname,ボタン名,入力欄の初期値)
※「interwikiname」は1.で記入した任意の文字列
※「ボタン名」と「入力欄の初期値」はそれぞれ任意の文字列（省略可）
現状でも後述のようなことができます。それぞれのリンク先に飛んで結果を確認してください。
ただし現在のwikiwikiでこれをプラグイン機能では実現できません。
つまり閲覧者が検索ボックスに任意の単語を入力して、かつ任意のページあるいは任意の区間を限定してという条件ではできません。
しかしwikiwikiのシステムに若干の手を加えてもらえればこれは可能になると思います。かつその改造がなされればこれ以外にもいつくかできることが増えると思われます。そんなに難しくないと思ってます。新しいプラグインは不要でInterWikiの連携を良くするだけです。
ページ内検索の件だけでは限定的な要望ですが、この対応ができれば併せて以下の問題も解決できる見通しになります。
少し前にあった要望。リンク
どのように解決できるかは少し複雑なのでここでは説明しません。
>> 2の話にもありましたが、従来ソース文は編集ボタンを押すか差分ボタンから差分込みで表示するのが常でした。
しかし前者は操作を誤るリスクがあり、また不要な差分情報が表示され見にくいという問題があります。
どのように解決できるかは以下のページ内検索の例で示します。
結局何がどうなればいいのかは、話が細かくなるので私が直接wikiwikiさんに話を持っていきます。
今回の検索の件がなくても以前不便に思ったところでもあるので。
■ページ内検索色々
以下特定のページを検索した結果の例を挙げます。実際にはこれをプラグインの検索ボックスの設置で実現させる必要があります。仮にそれができたときの結果のイメージです。これ以外の表示も色々できます。
検索対象の元のページ
実験的に以下のページを検索します。
元ページのリンク
上記ページの特定の文字だけ検索する
さっきのページの全文章に対して"。"を検索させます。
キーワードが"。"なのは他に適当にヒットするワードがなかったからです。
accordionの中も含めて全部ハイライトされます。
検索結果のリンク
キーワードを含む行だけ検索する
ページ内から"。"を含む行だけ抽出します。ハイライトも付けます。(付けないことも可能。)
accordionの行には"。"が無いので機能が取り除かれます。
検索結果のリンク
特定の区間だけ検索する
検索区間を"使用例"の見出し内だけ絞り込みます。前述の検索よりさらに絞り込まれてます。
検索結果のリンク
区間の指定の仕方は色々できます。
見出しは名称で指定したり、レベル別、先頭から何番目と何番目、どの見出しより後とか、色々できます。
ただ閲覧者側に選択の自由はなく、設定者側が予め設定を決めておく必要があります。
ソース文を表示して検索
ソースコードを読み取り専用で開いて、キーワードをハイライトします。
検索結果のリンク
特定の行だけ検索する
例は書きませんがキーワードを含む表だけとか、リスト文だけとか、決まった表現を含む行だけに検索を絞り込めます。
これは閲覧者が検索時に自由に設定できます。正規表現の理解が必要です。
foldやaccordionを開いた状態で表示と検索
foldやaccordionを開いた状態でハイライト検索ができます。ただページの方にあらかじめ仕込みが必要です。なので上記Sampleページ(編集不可)ではできません。
代替方法として次の2つを思いつきました。
やり方がスマートとは言えないので、指定した範囲のみの検索ができるに越したことはないと思います。
説明不足ですみませんでした。コントロールパネルは別々にしてほしいですが、いちいちログアウトして、ユーザー名入力して、パスワード入れて…という操作が煩わしいです。なので、同じアカウントで管理できるけども、サイトごとに設定を変えられるようにする、というようなものをイメージしています。
koishibaさんありがとうございます。
利用者というのは閲覧者のことを指します。
今回僕が利用する目的は、wikiwikiに載っている膨大な量の一覧リストから特定のものだけを閲覧者が検索できるようにするためです。
サイト内検索だと、他のページにも同じようなものがあるのでわかりづらく、ブラウザ側の検索機能だと、他のブロックにも同じようなものもあるので、これも然り。
ただ、2ブロック、というパターンもあるので、accordionのプラグインと同様に範囲を設定できるようにしてほしいです。
他のwikiでも、特にゲーム攻略では、特定のものを検索するのがめんどくさい（別のところに飛んで行ったりする）ので、このプラグインも用意したほうがいいと思っています。
（contentsのプラグインがありますが、それでも多いので、もっとコンパクトにしたほうがいい。）
こんなの実装されていたんですね。ありがとうございます。
公式さんぷるwikiのほうにも紹介を追加して欲しいところです。
以下でできます。
上記を含め関連プラグインの仕様
http://pukiwiki.sonots.com/?FrontPage
tag
lsx
contentsx
includex
ecache