リクエスト広場

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

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の連携を良くするだけです。

ページ内検索の件だけでは限定的な要望ですが、この対応ができれば併せて以下の問題も解決できる見通しになります。

• 指定範囲内のfoldやaccordionを一括で開閉できるプラグインが欲しい
  少し前にあった要望。リンク
  どのように解決できるかは少し複雑なのでここでは説明しません。
• ソース文を読み取り専用で開く機能
  >> 2の話にもありましたが、従来ソース文は編集ボタンを押すか差分ボタンから差分込みで表示するのが常でした。
  しかし前者は操作を誤るリスクがあり、また不要な差分情報が表示され見にくいという問題があります。
  どのように解決できるかは以下のページ内検索の例で示します。

結局何がどうなればいいのかは、話が細かくなるので私が直接wikiwikiさんに話を持っていきます。
今回の検索の件がなくても以前不便に思ったところでもあるので。

■ページ内検索色々
以下特定のページを検索した結果の例を挙げます。実際にはこれをプラグインの検索ボックスの設置で実現させる必要があります。仮にそれができたときの結果のイメージです。これ以外の表示も色々できます。

• 検索対象の元のページ
  実験的に以下のページを検索します。
  元ページのリンク

• 上記ページの特定の文字だけ検索する
  さっきのページの全文章に対して"。"を検索させます。
  キーワードが"。"なのは他に適当にヒットするワードがなかったからです。
  accordionの中も含めて全部ハイライトされます。
  検索結果のリンク

• キーワードを含む行だけ検索する
  ページ内から"。"を含む行だけ抽出します。ハイライトも付けます。(付けないことも可能。)
  accordionの行には"。"が無いので機能が取り除かれます。
  検索結果のリンク

• 特定の区間だけ検索する
  検索区間を"使用例"の見出し内だけ絞り込みます。前述の検索よりさらに絞り込まれてます。
  検索結果のリンク
  区間の指定の仕方は色々できます。
  見出しは名称で指定したり、レベル別、先頭から何番目と何番目、どの見出しより後とか、色々できます。
  ただ閲覧者側に選択の自由はなく、設定者側が予め設定を決めておく必要があります。

• ソース文を表示して検索
  ソースコードを読み取り専用で開いて、キーワードをハイライトします。
  検索結果のリンク

• 特定の行だけ検索する
  例は書きませんがキーワードを含む表だけとか、リスト文だけとか、決まった表現を含む行だけに検索を絞り込めます。
  これは閲覧者が検索時に自由に設定できます。正規表現の理解が必要です。

• foldやaccordionを開いた状態で表示と検索
  foldやaccordionを開いた状態でハイライト検索ができます。ただページの方にあらかじめ仕込みが必要です。なので上記Sampleページ(編集不可)ではできません。

代替方法として次の2つを思いつきました。

• 検索するブロックごとにaccordionにし、検索する際は「検索したくないところを閉じ、検索したいところのみを開いて」検索する(表示されていない箇所は検索できないことを逆用する)
• 検索するブロックごとにpopout指定し、検索する際は検索したいブロックをポップアウトさせてそのページを検索する

やり方がスマートとは言えないので、指定した範囲のみの検索ができるに越したことはないと思います。

説明不足ですみませんでした。コントロールパネルは別々にしてほしいですが、いちいちログアウトして、ユーザー名入力して、パスワード入れて…という操作が煩わしいです。なので、同じアカウントで管理できるけども、サイトごとに設定を変えられるようにする、というようなものをイメージしています。

koishibaさんありがとうございます。
利用者というのは閲覧者のことを指します。
今回僕が利用する目的は、wikiwikiに載っている膨大な量の一覧リストから特定のものだけを閲覧者が検索できるようにするためです。
サイト内検索だと、他のページにも同じようなものがあるのでわかりづらく、ブラウザ側の検索機能だと、他のブロックにも同じようなものもあるので、これも然り。
ただ、2ブロック、というパターンもあるので、accordionのプラグインと同様に範囲を設定できるようにしてほしいです。
他のwikiでも、特にゲーム攻略では、特定のものを検索するのがめんどくさい（別のところに飛んで行ったりする）ので、このプラグインも用意したほうがいいと思っています。
（contentsのプラグインがありますが、それでも多いので、もっとコンパクトにしたほうがいい。）

こんなの実装されていたんですね。ありがとうございます。
公式さんぷるwikiのほうにも紹介を追加して欲しいところです。

以下でできます。

#contentsx(depth=1:2)

上記を含め関連プラグインの仕様
http://pukiwiki.sonots.com/?FrontPage

tag
lsx
contentsx
includex
ecache

普通にページの改ざん・削除なら、
wikiのバックアップから「誰でも」元に戻せます。

しかし、ページの改ざん後に（例えば「あ」という1文字にしてから）ページ名の変更が行われると、
これが不可能になるのではないでしょうか。
（ページがリネームされた瞬間に、旧ページ名時のバックアップが消滅）

ページ名の変更は、確か副管理者（サブパスワード所持者）でもできなかった筈です。
上記は自分の推測で、実際に試したことはないので間違っているかもしれませんが、
理由もなしに規制されているとは考え難いので、
運営に正確な理由を問い合わせてみると良いと思います。

（ページ名を変更するために）ページを作り直すと言っても、
それ自体はコピペ&Deleteなので1分と掛かりませんし、
ページ名を変更してもリンクなどを修正する手間が残るのは、
ページを作り直す場合と何も変わりません。
つまり、「面倒」であることに関して差はないのですよ。

ページ名の変更(renameコマンド)は管理者権限ではなく、一般開放して良いと思います。
例えば新規作成、削除、編集は誰でもできます。ページ名の編集権限がこれらと区別される理由が見当たりません。
システム的にはバックアップや添付ファイルなどページ名に紐づいたものが内部に存在しますが、renameコマンドで変更すればこれらの整合性は取れます。
逆に名前を変えたいページを削除してから、別名で新ページを作成してソース文だけ移しても上記のものは引き継げません。ユーザが自分のできる範囲でなんとか解決しようとするとバックアップを失ったり、添付ファイルが迷子になったり、システム側にゴミが残ったりと良いことがありません。
ページ名の変更履歴(RenameLog)はだれでも見れるので仮に荒らされても戻せます。ページ編集の対応と同じことです。

問題が出るとすれば既存ページ名で作られてるリンクやページ参照式のプラグインの整合性です。ページ名をちょっと修正したつもりが気が付かないところに影響が出たみたいなケースでしょうか。しかしそれはシステム側で気にすることではなく運用で解決する問題だと思います。
最終的には管理者の負担に影響がでそうなので、管理者側でOff/Onできるようにしてもいいかもしれません。しかし私の意見としては最初に述べたように誰でもページが作れたり消せたりできる前提のシステムなら名前の変更操作もその中に含まれると思います。なので、設定としてはデフォルトが開放で、管理者の判断で禁止も選択できるのがよいと思います。

ページ名の変更場面はいくつかあります。
誤記などはわかりやすいですがそれ以外で。階層構造をやめたり、逆にページを分類して階層構造に変更したり。
参加者が勝手気ままに付けたページ名を整えたり。カタカナ、全角半角、英語表記を統一したり、スペース替わりに使ってるアンダースコアを直したりなど。
気付いたときにすぐ直したいケースや、計画的にまとめて直すケースなど考えられますが、いずれにしろ全部管理者にお願いする(される)のも大変です。
個人ページや任せてるページなら勝手にやればいいし、自分で話をまとめられるなら自分でやればいいと思います。

利用者というのは閲覧者のことですか? それとも編集者のことでしょうか。
1ブロック単位での検索ツールにどのような意味・利便性があるのか、
ちょっと自分には想像できません。（特に閲覧者にとって）

「ヒント」「以下の留意点～」に書かれているように、
（他のwikiでも需要がありそうか、なぜそれが必要か理由を書く）
どのような場合に、どんなふうに便利なのか、
簡単でいいので具体的な説明をお願いします。

あ、僕が欲しいのはページ内じゃなくて、特定の部分でした。（1ブロックとか）
既存のwikiwikiのサイト内検索だと、他のページでヒットしたものまで出てきてしまうので困ります。できれば、特定の部分だけ検索してほしいのですが、ブラウザ側の検索機能だと、関係ないところまで対象になったり、あるいは非表示になっているところを検索できなかったりと不便なところがあります。
それに、検索をかけるのは、僕ではなく、利用者なので、難しい操作はなしにしてほしいです。

管理人が機能の制限/開放を設定できるようにすればよいのではないでしょうか。
荒らしが発生したら機能を制限し、管理権限を持たない一般編集者では編集できなくする。
また一般編集者による名前変更には1時間とか1日とか1週間とか、クールタイムを設けるなども有効な荒らし対策になるかと思います。

逆に考えてみて下さい。
もしも簡単な操作でページ名を変更できたら荒らし放題ですよ。

それに加えてページ名自体、つまりURLを変えるとなれば恐らく内部の書き換えで相当な手間が掛かるはずです。

素人の例えですけども、サイトのサーバー移転をする際に何時間もかかるような感じですね。

ここで見ず知らずの貴方に説教をするつもりはさらさら有りませんが、面倒だからこそいいこともあるのではないのでしょうか？

それがめんどくさいし、それが出来るなら解放してほしい。

別に反対はしませんが、
黒バックの場合、普通の青では余計に視認性が悪化するので、
それだけはやめてください。

追記：

文字色はデザイン テンプレートにより様々です。
（リンクが青文字になるテンプレートもあります）
黒文字とか、特定の環境だけでなく、全体のことも考えてください。

とりあえず↑の方法で折り畳みボタンを好みの色に変更できますが、
それではダメなのでしょうか。
（個人的には、多用しない限り面倒という程ではないように思えます）

【例】
 #color(DodgerBlue){{{{
 #fold(&color(Black){開く};){{{
 #color(Black){{
 折り畳み記事の色は黒、
 折り畳みボタンの色を&color(DodgerBlue){明るめの青};にしたい場合です。
 一寸面倒かもですが、好きな色を指定できますよ。
 }}
 }}}
 }}}}

 #color(Blue){{
 #fold(あいうえお){{
 かきくけこ
 さしすせそ
 }}
　
　
 #accordion(&color(Blue){たちつてと};,*,close){{
 なにぬねの
 はひふへほ
 }}
　
　
これでできたと思います

運営の方は見てらっしゃいますか？
どうでしょうか。

ページの内容を切り取って、消して、新しいページ名でページ作って、貼り付けて更新する。

設定をWikiごとに変えたい場合困りませんか？

横からですが、ブラウザの検索機能だと折畳みされている内容が検索から漏れるため、その点は不便ですね。
そういう時、自分は差分表示にしてソース文を検索していますが、見づらいですし一般の利用者に勧められるやり方とは言い難いかと思います。
まぁトピ主さんの目的からするとおそらく不足はないと思います。

ブラウザ側の機能の検索では不足でしょうか。PCだとCtrl+Fとかで検索できると思います。
また例えばwiki側にページ内検索機能があったとして、どのような検索結果をイメージしてるのでしょうか。サイト全体検索だとヒットするページが列記されるわけですが、ページ内だと該当行に飛んだり色が付いたり程度で、ブラウザの検索機能とたいして変わり映えがしないように思います。

私も同じような現象がおきています。
編集ミスしたとき、この機能を使っても、元通りにはならず、結局やり直しです。