賛成です。マニュアルと言いつつあまりマニュアルの役目を果たしていないように思えます。>> 2さんの仰っている通りユーザー参加型の形式でもよさそうです。
賛成です。 利用しているwikiが使っているプラグインが、マニュアルを見ても載っていないことが多くてよく混乱しています。 切実にお願いします。プラグインのwikiがあったら自分も参加します。
公式Xの投稿日を見るに、こちらのトピックを受けて内容が追記されていたようですね。 https://x.com/wikiwiki_japan/status/1947539662194806924 ありがとうございました。
仕様上lazy系の中に入れた目次は表示されないようです。 https://wikiwiki.jp/pp/eco-plugins-guide (一番下のFAQに書いてあります)
賛成です。 公式Xの投稿を見て「ecache」の後継にあたる「fcache」の存在を知りました。 調べたら過去に投稿されてましたが、公式Xの投稿を逐一確認してないので気づきませんでした。 同投稿の「lazy_fold」と「lazy_accordion」に関しても追加していただきたいです。 プラグインの存在を簡単に知る方法がないと本末転倒なので、一ヶ所にまとめていただきたいです。 詳細な使い方や更新による挙動変化を含めると、切実に「wikiwikiプラグインのwiki」が欲しい。
@wikiwiki おそらく、popularが削除済みの記事も表示することは多数の利用者が煩わしく思っていたものであると考えます。 この要望については検討していただけないのでしょうか。
賛同します。 先日のアップデートによりWiki自体に管理者パスワードorサブパスワードでログイン出来る機能が追加されましたが、それでログインしている場合はページの凍結をバイパス出来ると便利かと思います。 既に指摘の通り、凍結解除・再凍結の分の操作が減る事、凍結忘れのリスクを回避出来る事の他、可能性は低いながら、凍結解除＆編集している間に荒らされてしまうリスクも回避する事が出来ます。
認証コードを送って認証完了のメッセージが出たのに、いざ書き込もうとすると「認証のない書き込みは制限されています」だとよ。何だよこれ
返信ありがとうございます。 こちらでも通常通り、表示されなくなったことを確認できました。
今はもう、表示されなくなったようです。プラグインが動作しているかどうかまでは、分かりませんが。 一時的な不具合ではないでしょうか。
wikiの管理者は、Googleアナリティクスを使って閲覧の統計を得たり、傾向を解析できるようになっています。 Googleアナリティクス: https://developers.google.com/analytics?hl=ja
得たい情報をもっと具体的に示してもらえれば、もう少し違った話ができるかもしれません。
この場合にも目次が生成されないようです。 lazy_foldの中に入れているincludeの内容に目次が含まれている場合: 引用元のページでは目次が生成されているにも関わらず、引用先に目次がされない
＃lazy_fold/lazy_accordion(option){{ ＃include(引用ページ) }}
引用ページの記述
＃contents/contentsx 内容 内容
既存のfoldをlazy_foldで置き換えた場合、折りたたみの内容が他の折りたたみの中に移動して表示されたり、内容を取得できないというエラーが表示される事があります。
お世話になっております。こちらの不具合についてですが、その後何か進展などありましたでしょうか？ googleカレンダーの埋め込みを一案として考えており、調査動向が気になった次第です。
同じ内容を選択できるプラグインみたいなものがあったらいいなと思いました。 現在の内容だと別のタグに同じ内容を選択したい場合は同じ内容を2回記載しないといけないので スペースを取ってしまいます。1か所記載したところから別のタグに同じ内容をコピー出来るみたいな感じでしょうか？ 使用した感想を率直に書きました違っていたらスミマセン。
メニュー時にできる左の無駄な空白を詰める
今確認したところ、これが改善されていました。 先頭タブ左の余白はほぼなくなり、メニュー幅に収められる量が少し増えました。ありがとございます。
wikiの編集中に自分も使いたい場面があったので実装を希望します。 また、対応してくださるなら、「fold」と「navfold」のどちらもインライン型で使えるようにしてほしいです。
自分もアカウント制は賛成です! 自分のWiki荒らしが多いので あとできればWikiごとにアカウントを 別々を希望しています
タブ機能についての追加要望となりますが、 「デフォルトで表示するタブを変更する機能」の実装を希望します。
現在の仕様は左端固定ですが、使い方として 新しいタブを後ろに追加し、それを最初に表示させたいケースがあります。
中間のタブをデフォルトにする運用はあまり思いつかないため、 個人的には先頭か末尾かを指定できれば十分です。
お手数ですが、ご検討いただければ幸いです。
タブの多段対応要望に関して、現在のデザインのまま実装されたとすると 選択中のタブが分かりづらくなる懸念があります。
最下段のタブは問題ありませんが、上段は太字表記のみになるため若干分かりにくくなります。 （小さい文字や1文字タブを設定するとこの問題はより顕著になります。）
もしタブ多段対応が実装されるならば、タブの選択・非選択状態をより明確に区別できるよう併せて検討いただきたいです。
選択・非選択状態の区別の例：
個人的には選択中タブの文字装飾を変更するのがシンプルでよいと思います。
アカウント制の実装は、大規模な荒らしが発生した際に、ごく一部の信頼できるユーザーのみが編集を継続できるようにすることを主な方向性として検討しているものと理解しています。 しかし、ホワイトリストを管理者が手動で認証する方式にすると、管理者は荒らし対策、Wikiの復旧作業に加えて、申請者の編集履歴を確認する作業を並行的に行うことになり、新たな作業が生じませんか？
現時点で議論されているホワイトリスト登録制度には、平常時に生じるメリットがほとんどないように見受けられ、多くの利用者は必要性を感じずアカウント申請を行わないと考えています。結果として（必要性が生じる）緊急時に申請が集中すると予想しています。
緊急時にアカウント申請への手動承認が必要だとすると、管理者としては「承認後からロックダウン解除の期間で本当に編集するか分からないユーザーに労力を割きたくない」「申請の照合作業よりも復旧作業を優先したい」と感じるのではないでしょうか。 ロックダウン中の承認作業が負担となれば、ロックダウン中のホワイトリスト制度は実際には機能しないことを意味します。
このため、管理者の負担減少を目的に、自動承認機能が必要だと考えています。 「SMS認証を必須とする」「該当ユーザが1ヶ月以上前から（editプラグインを用いた）編集実績がある」などの条件を設ければ、懸念されている安全性も一定程度担保しつつ、ロックダウン中でも意欲的な編集者の作業を許可し、管理側の負担も抑えられると考えますが、いかがでしょうか。 （仮に手動承認を要求するのであれば照合作業が負担とならないUIが必要で、別のスレッドの議論を引き合いに出してしまい恐縮ですが、現状の編集差分ログ機能ではその要求を満たしていないと考えます） 私自身、かなり想定が飛躍しているようには思われますので、皆さまの考えを伺いたいです。
>> 23 「タブAを読んでいる途中や読み終わった後に、今度はタブBを開きたい」というケースが起こるのであればタブという形はあまり向いていないのではないでしょうか。 終了部分にラベルを表示しても結局は文章を先頭から読み直すためにスクロールが必要になるので、そういったケースで便利に読むのであればタブよりも「スクロールに追従する目次」などの方が有用ではないかなと思いました。
tabプラグインの範囲内なのか分かりにくい点については同感です。 ただ、水平線などを末尾に配置する形やcssboxとの併用など、編集者がどのような形で範囲を明確にするか選べるという意味では現行の仕様も良いと思います、デザインの自由度が高いですから。
タブラベルの多段化はflexでいう所のflex-wrapのような「折り返しを許可するか否か」を指定できるシンプルなものがあると嬉しいですね。 多段化が目当てでなくとも、ラベル名を省略してほしくないケースでも使えそうに思います。
確かに多段設置可能になれば、カラム幅を気にせずにタブが置けるようになるので、 より便利になりますね。
flex_boxのようにタブ幅が数値で指定でき、 引数オプションで、カラム幅に合わせて自動で折り返し表示可能になれば、 サイズ超過分が自動で下段表示となり、キレイにレイアウトできると思います。
追記：
「タブ幅が数値で指定でき…」と書きましたが、 （タブの）サイズでなく個数指定の方が良いかもしれません。
例えば、列の最大数を「5」と指定した場合、 超過分は自動で下段にレイアウトされ、 タブ幅は、タイトル文字列 or カラム幅に合わせて自動調節されるみたいな。 （レイアウトオプションは、左寄せ or カラム幅合わせの2択か、 文字列合わせの場合のみ中央寄せを加えた3択）
※ご要望が多かった「プルダウン形式」は、今回は採用を見送っています。
プラグイン使用してみて複数の情報ブロックを、タブ化したい項目があるので、皆さんが代替案として要望している多段タブを希望します。
また、どこまでがtabプラグインの範囲内なのかが利用者に分かりづらいことも要改善点と感じました。 タブ領域の開始部分だけでなく終了部分にもラベルを表示するか選べるオプションや、 タブ領域を表示している間は、ラベルを（#tablescrollプラグインのように）ページ上部に固定するオプションが選べたりするとよいかなと感じます。
こちらの意見・要望に賛同します。
とサンプルサイトにも記述があり、すでにwikiwiki運営様の方でも認識はされていると存じますが 「タブAを読んでいる途中や読み終わった後に、今度はタブBを開きたい」というときにラベルのある上部まで遷移しなければならないというのが想定以上にストレスだなと感じます。とりわけページの中盤でタブを使用するページにおいて顕著です。
また、どこまでがtabプラグインの範囲内なのかが利用者に分かりづらいことも要改善点と感じました。
タブ領域の開始部分だけでなく終了部分にもラベルを表示するか選べるオプションや、 タブ領域を表示している間は、ラベルを（#tablescrollプラグインのように）ページ上部に固定するオプションが選べたりするとよいかなと感じます。
>> 21 私はメニューでの利用ついて述べています。通常ページについての意見ではありません。 デザインや調整値は共通や固定である必要はありません。
現状はメニュー・通常ページ内問わず共通デザインのため、全くの無関係であるとは言えません。 メニュー表示のためだけに、全体で使いづらくなるような変更をされては困るという意見を述べただけです。
「メニュー内表示時に限りデザインを変更したい」という意図で要望されているようですので、 通常ページでの利用に影響が出ない変更になるのであれば問題ありません。
私はメニューでの利用ついて述べています。通常ページについての意見ではありません。 デザインや調整値は共通や固定である必要はありません。 タブのためにメニューの幅を変更することは考えてません。今ところメニュー幅の方が優先度が高いです。
タブの多段対応に関しては私も要望していたところなので賛成します。 ただし、他の要望についてはあまり賛成できません。
余白を詰めたり区切りを変えたりすると、タブが選択しづらくなる・視認性が低下するなど 使い勝手が悪くなってしまう恐れがあります。 逆に言えば、利便性を損なうものにならなければ変更されることは構いませんが。
運営からタブの使用数を注意されているとおり、そもそも幅が狭い箇所でのタブの利用は向いていません。 ご存じかと思いますがメニューバーの幅は広げることが可能なので、そちらの対応も検討されてはいかがでしょうか。
メニューでの利用を考えてます。 ページ数が多いサイトはメニューがとても長くなる傾向があり、タブでこれを改善できると見込んでます。 現状だとこんな感じです。 ３つぐらいが限界です。文字も見切れます。使えて漢字一文字か半角2-3文字と思います。
要望として
タブプラグインです。 使い方はこちら https://wikiwiki.jp/sample/Tab
ご意見をもとに検討を重ね、以下の仕様で確定しました。 ご協力ありがとうございました！
追記
ご確認ありがとうございました。 ご迷惑をおかけしましたこと、お詫び申し上げます。 今後ともよろしくお願いいたします。
早期のご対応ありがとうございます。 問題の解決を確認しましたのでクローズとします。
ご確認ありがとうございます。 ご迷惑おかけしました。 今後ともどうぞよろしくお願いいたします。
動作を確認しました。 早急な対応ありがとうございます。
ご連絡ありがとうございます。
ご報告いただいた不具合を修正しました。 お手数ですが、ご確認いただけますと幸いです。
search プラグインのコマンドパラメータはこちらになります。
::cmd/search{[?word=検索文字列][&type=OR]}
このプラグインには、もともとページ名を指定するためのパラメータは存在しておりません。 仕様として、特定ページを対象に検索を行う機能も提供しておりません。
一部のケースで「特定ページ内の検索ができていたように見えた」と感じられたことがあるかもしれませんが、それは検索語やページ内容、表示順などが偶然一致した結果と考えられます。
また、2017年以前のソースまで遡って確認したところ、パラメータ仕様に変更はありませんでした。
なお、セキュリティ対策の一環として、サポートされていないパラメータや意図しない指定については、システム側で無効化される場合があります。
その点につきましては、ご理解のほどお願いいたします。
@wikiwiki コマンドが変わることで意図した動きにならなくなっており、見解をお聞かせください。(以前までは特定ページ内の検索結果が出ていましたが今はwiki内の検索にコマンド自体置換されてしまっています)
ホワイトリストの自動登録について反対です。 他の方も書かれている様に、捨て垢、特に複数回線を持つ人物による荒らしに対応出来ないと考えます。
賛成です。マニュアルと言いつつあまりマニュアルの役目を果たしていないように思えます。>> 2さんの仰っている通りユーザー参加型の形式でもよさそうです。
賛成です。
利用しているwikiが使っているプラグインが、マニュアルを見ても載っていないことが多くてよく混乱しています。
切実にお願いします。プラグインのwikiがあったら自分も参加します。
公式Xの投稿日を見るに、こちらのトピックを受けて内容が追記されていたようですね。
https://x.com/wikiwiki_japan/status/1947539662194806924
ありがとうございました。
仕様上lazy系の中に入れた目次は表示されないようです。
https://wikiwiki.jp/pp/eco-plugins-guide (一番下のFAQに書いてあります)
賛成です。
公式Xの投稿を見て「ecache」の後継にあたる「fcache」の存在を知りました。
調べたら過去に投稿されてましたが、公式Xの投稿を逐一確認してないので気づきませんでした。
同投稿の「lazy_fold」と「lazy_accordion」に関しても追加していただきたいです。
プラグインの存在を簡単に知る方法がないと本末転倒なので、一ヶ所にまとめていただきたいです。
詳細な使い方や更新による挙動変化を含めると、切実に「wikiwikiプラグインのwiki」が欲しい。
@wikiwiki
おそらく、popularが削除済みの記事も表示することは多数の利用者が煩わしく思っていたものであると考えます。
この要望については検討していただけないのでしょうか。
賛同します。
先日のアップデートによりWiki自体に管理者パスワードorサブパスワードでログイン出来る機能が追加されましたが、それでログインしている場合はページの凍結をバイパス出来ると便利かと思います。
既に指摘の通り、凍結解除・再凍結の分の操作が減る事、凍結忘れのリスクを回避出来る事の他、可能性は低いながら、凍結解除＆編集している間に荒らされてしまうリスクも回避する事が出来ます。
認証コードを送って認証完了のメッセージが出たのに、いざ書き込もうとすると「認証のない書き込みは制限されています」だとよ。何だよこれ
返信ありがとうございます。
こちらでも通常通り、表示されなくなったことを確認できました。
今はもう、表示されなくなったようです。プラグインが動作しているかどうかまでは、分かりませんが。
一時的な不具合ではないでしょうか。
wikiの管理者は、Googleアナリティクスを使って閲覧の統計を得たり、傾向を解析できるようになっています。
Googleアナリティクス:
https://developers.google.com/analytics?hl=ja
得たい情報をもっと具体的に示してもらえれば、もう少し違った話ができるかもしれません。
この場合にも目次が生成されないようです。
lazy_foldの中に入れているincludeの内容に目次が含まれている場合:
引用元のページでは目次が生成されているにも関わらず、引用先に目次がされない
引用ページの記述
既存のfoldをlazy_foldで置き換えた場合、折りたたみの内容が他の折りたたみの中に移動して表示されたり、内容を取得できないというエラーが表示される事があります。
お世話になっております。こちらの不具合についてですが、その後何か進展などありましたでしょうか？
googleカレンダーの埋め込みを一案として考えており、調査動向が気になった次第です。
同じ内容を選択できるプラグインみたいなものがあったらいいなと思いました。
現在の内容だと別のタグに同じ内容を選択したい場合は同じ内容を2回記載しないといけないので
スペースを取ってしまいます。1か所記載したところから別のタグに同じ内容をコピー出来るみたいな感じでしょうか？
使用した感想を率直に書きました違っていたらスミマセン。
今確認したところ、これが改善されていました。
先頭タブ左の余白はほぼなくなり、メニュー幅に収められる量が少し増えました。ありがとございます。
wikiの編集中に自分も使いたい場面があったので実装を希望します。
また、対応してくださるなら、「fold」と「navfold」のどちらもインライン型で使えるようにしてほしいです。
自分もアカウント制は賛成です!
自分のWiki荒らしが多いので
あとできればWikiごとにアカウントを
別々を希望しています
タブ機能についての追加要望となりますが、
「デフォルトで表示するタブを変更する機能」の実装を希望します。
現在の仕様は左端固定ですが、使い方として
新しいタブを後ろに追加し、それを最初に表示させたいケースがあります。
中間のタブをデフォルトにする運用はあまり思いつかないため、
個人的には先頭か末尾かを指定できれば十分です。
お手数ですが、ご検討いただければ幸いです。
タブの多段対応要望に関して、現在のデザインのまま実装されたとすると
選択中のタブが分かりづらくなる懸念があります。
最下段のタブは問題ありませんが、上段は太字表記のみになるため若干分かりにくくなります。
（小さい文字や1文字タブを設定するとこの問題はより顕著になります。）
もしタブ多段対応が実装されるならば、タブの選択・非選択状態をより明確に区別できるよう併せて検討いただきたいです。
選択・非選択状態の区別の例：
個人的には選択中タブの文字装飾を変更するのがシンプルでよいと思います。
アカウント制の実装は、大規模な荒らしが発生した際に、ごく一部の信頼できるユーザーのみが編集を継続できるようにすることを主な方向性として検討しているものと理解しています。
しかし、ホワイトリストを管理者が手動で認証する方式にすると、管理者は荒らし対策、Wikiの復旧作業に加えて、申請者の編集履歴を確認する作業を並行的に行うことになり、新たな作業が生じませんか？
現時点で議論されているホワイトリスト登録制度には、平常時に生じるメリットがほとんどないように見受けられ、多くの利用者は必要性を感じずアカウント申請を行わないと考えています。結果として（必要性が生じる）緊急時に申請が集中すると予想しています。
緊急時にアカウント申請への手動承認が必要だとすると、管理者としては「承認後からロックダウン解除の期間で本当に編集するか分からないユーザーに労力を割きたくない」「申請の照合作業よりも復旧作業を優先したい」と感じるのではないでしょうか。
ロックダウン中の承認作業が負担となれば、ロックダウン中のホワイトリスト制度は実際には機能しないことを意味します。
このため、管理者の負担減少を目的に、自動承認機能が必要だと考えています。
「SMS認証を必須とする」「該当ユーザが1ヶ月以上前から（editプラグインを用いた）編集実績がある」などの条件を設ければ、懸念されている安全性も一定程度担保しつつ、ロックダウン中でも意欲的な編集者の作業を許可し、管理側の負担も抑えられると考えますが、いかがでしょうか。
（仮に手動承認を要求するのであれば照合作業が負担とならないUIが必要で、別のスレッドの議論を引き合いに出してしまい恐縮ですが、現状の編集差分ログ機能ではその要求を満たしていないと考えます）
私自身、かなり想定が飛躍しているようには思われますので、皆さまの考えを伺いたいです。
>> 23
「タブAを読んでいる途中や読み終わった後に、今度はタブBを開きたい」というケースが起こるのであればタブという形はあまり向いていないのではないでしょうか。
終了部分にラベルを表示しても結局は文章を先頭から読み直すためにスクロールが必要になるので、そういったケースで便利に読むのであればタブよりも「スクロールに追従する目次」などの方が有用ではないかなと思いました。
tabプラグインの範囲内なのか分かりにくい点については同感です。
ただ、水平線などを末尾に配置する形やcssboxとの併用など、編集者がどのような形で範囲を明確にするか選べるという意味では現行の仕様も良いと思います、デザインの自由度が高いですから。
タブラベルの多段化はflexでいう所のflex-wrapのような「折り返しを許可するか否か」を指定できるシンプルなものがあると嬉しいですね。
多段化が目当てでなくとも、ラベル名を省略してほしくないケースでも使えそうに思います。
確かに多段設置可能になれば、カラム幅を気にせずにタブが置けるようになるので、
より便利になりますね。
flex_boxのようにタブ幅が数値で指定でき、
引数オプションで、カラム幅に合わせて自動で折り返し表示可能になれば、
サイズ超過分が自動で下段表示となり、キレイにレイアウトできると思います。
追記：
「タブ幅が数値で指定でき…」と書きましたが、
（タブの）サイズでなく個数指定の方が良いかもしれません。
例えば、列の最大数を「5」と指定した場合、
超過分は自動で下段にレイアウトされ、
タブ幅は、タイトル文字列 or カラム幅に合わせて自動調節されるみたいな。
（レイアウトオプションは、左寄せ or カラム幅合わせの2択か、
文字列合わせの場合のみ中央寄せを加えた3択）
プラグイン使用してみて複数の情報ブロックを、タブ化したい項目があるので、皆さんが代替案として要望している多段タブを希望します。
こちらの意見・要望に賛同します。
とサンプルサイトにも記述があり、すでにwikiwiki運営様の方でも認識はされていると存じますが
「タブAを読んでいる途中や読み終わった後に、今度はタブBを開きたい」というときにラベルのある上部まで遷移しなければならないというのが想定以上にストレスだなと感じます。とりわけページの中盤でタブを使用するページにおいて顕著です。
また、どこまでがtabプラグインの範囲内なのかが利用者に分かりづらいことも要改善点と感じました。
タブ領域の開始部分だけでなく終了部分にもラベルを表示するか選べるオプションや、
タブ領域を表示している間は、ラベルを（#tablescrollプラグインのように）ページ上部に固定するオプションが選べたりするとよいかなと感じます。
現状はメニュー・通常ページ内問わず共通デザインのため、全くの無関係であるとは言えません。
メニュー表示のためだけに、全体で使いづらくなるような変更をされては困るという意見を述べただけです。
「メニュー内表示時に限りデザインを変更したい」という意図で要望されているようですので、
通常ページでの利用に影響が出ない変更になるのであれば問題ありません。
私はメニューでの利用ついて述べています。通常ページについての意見ではありません。
デザインや調整値は共通や固定である必要はありません。
タブのためにメニューの幅を変更することは考えてません。今ところメニュー幅の方が優先度が高いです。
タブの多段対応に関しては私も要望していたところなので賛成します。
ただし、他の要望についてはあまり賛成できません。
余白を詰めたり区切りを変えたりすると、タブが選択しづらくなる・視認性が低下するなど
使い勝手が悪くなってしまう恐れがあります。
逆に言えば、利便性を損なうものにならなければ変更されることは構いませんが。
運営からタブの使用数を注意されているとおり、そもそも幅が狭い箇所でのタブの利用は向いていません。
ご存じかと思いますがメニューバーの幅は広げることが可能なので、そちらの対応も検討されてはいかがでしょうか。
メニューでの利用を考えてます。
ページ数が多いサイトはメニューがとても長くなる傾向があり、タブでこれを改善できると見込んでます。
現状だとこんな感じです。
３つぐらいが限界です。文字も見切れます。使えて漢字一文字か半角2-3文字と思います。
要望として
タブプラグインです。
使い方はこちら
https://wikiwiki.jp/sample/Tab
ご意見をもとに検討を重ね、以下の仕様で確定しました。
ご協力ありがとうございました！
→ 対応済み
→ 任意に指定可能
→ 使用可能ですが、表示崩れの可能性があるため自己責任で
→ 白背景と黒背景のシンプルなスタイルのみ対応
→ 無制限。ただし多数のタブは非推奨
→ PCと同じくレスポンシブ対応。幅が狭くなるため、使用時はラベル長・数に配慮してください
→ 今回は非対応。別プラグインでの提供を予定しています。
※ご要望が多かった「プルダウン形式」は、今回は採用を見送っています。
追記
→ 対応済み
→ 対応済み
ご確認ありがとうございました。
ご迷惑をおかけしましたこと、お詫び申し上げます。
今後ともよろしくお願いいたします。
早期のご対応ありがとうございます。
問題の解決を確認しましたのでクローズとします。
ご確認ありがとうございます。
ご迷惑おかけしました。
今後ともどうぞよろしくお願いいたします。
動作を確認しました。
早急な対応ありがとうございます。
ご連絡ありがとうございます。
ご報告いただいた不具合を修正しました。
お手数ですが、ご確認いただけますと幸いです。
ご連絡ありがとうございます。
ご報告いただいた不具合を修正しました。
お手数ですが、ご確認いただけますと幸いです。
ご連絡ありがとうございます。
ご報告いただいた不具合を修正しました。
お手数ですが、ご確認いただけますと幸いです。
search プラグインのコマンドパラメータはこちらになります。
::cmd/search{[?word=検索文字列][&type=OR]}このプラグインには、もともとページ名を指定するためのパラメータは存在しておりません。
仕様として、特定ページを対象に検索を行う機能も提供しておりません。
一部のケースで「特定ページ内の検索ができていたように見えた」と感じられたことがあるかもしれませんが、それは検索語やページ内容、表示順などが偶然一致した結果と考えられます。
また、2017年以前のソースまで遡って確認したところ、パラメータ仕様に変更はありませんでした。
なお、セキュリティ対策の一環として、サポートされていないパラメータや意図しない指定については、システム側で無効化される場合があります。
その点につきましては、ご理解のほどお願いいたします。
@wikiwiki
コマンドが変わることで意図した動きにならなくなっており、見解をお聞かせください。(以前までは特定ページ内の検索結果が出ていましたが今はwiki内の検索にコマンド自体置換されてしまっています)
ホワイトリストの自動登録について反対です。
他の方も書かれている様に、捨て垢、特に複数回線を持つ人物による荒らしに対応出来ないと考えます。