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内の検索にコマンド自体置換されてしまっています)
ホワイトリストの自動登録について反対です。 他の方も書かれている様に、捨て垢、特に複数回線を持つ人物による荒らしに対応出来ないと考えます。
そもそも論、ホワイトリスト登録を自動承認制にするとブラックリストと呼ばれるべき機能になる気がします。
ロックダウン機能において編集とコメント投稿の制限を個別にできた方が良いという理由に関して書きます。
経験上、wiki利用者は閲覧のみのユーザーが一番多く、ついでコメントを投稿するユーザー、そして一番少ないのが編集に参加するユーザーのように思われます。提案されているロックダウンの仕様は閲覧のみのユーザーには影響がありせんし、編集に参加する熱心なユーザーにも抵抗感は少ないと思います。 しかし、中間層であるコメントを投稿するユーザーは匿名の場でやり取りを好んでいる傾向があり、アカウントを作成してまで利用し続けようとするユーザーは少数派です。
編集・解説がwikiの大きな役割であることは間違いありませんが、コメントによるユーザー間の交流も人気のコンテンツである事もまた事実です。コメントページのビューの多さからコメントのやり取りを見るために定期的に訪れている閲覧のみのユーザーもかなりの割合存在します。そのためロックダウンで一括して制限をかけた場合、wiki利用者の大部分にとってサービスとしての価値が失われた状態になります。 編集やコメント書き込みなど個別に制限を設定できるというのは選択肢の多さであり、個別設定できないよりも柔軟性があり利便性が高いのは明らかな事実です。
そもそもロックダウン機能は果たして荒らし行為に対して有効な対策なのか？という疑問も主張の根底に存在します。仮に荒らし行為が原因で一括のロックダウンを実施したとして、先述の通り多くのユーザーにとっては利用価値が大きく損なわれた状態にるわけであり、それこそが荒らしの思う壺ではないでしょうか？
仮に編集のみのロックダウンならば大半のユーザーに取って影響はありません。しかし、コメントのようなコミュニケーション部分はロックダウン機能との相性が極端に悪く、どちらかといえばミュート機能やシャドウバン、ユーザーが個別に設定できるNGワードなどより適した手段が存在するように思います。
ホワイトリストの自動登録について反対です。他Wikiでは、編集・利用ルールをちゃんと読んでいるかを確認するためのWiki管理者が用意した質問で、アカウント申請時にWiki管理者へのメッセージ欄を設けて回答を求めるようなところもあります。アカウント申請だけで質問に未回答だったりルール未読と判断出来れば、その時点で却下できます。
この仕組みがあれば、ロックダウンのようにすべての投稿を一律にブロックしなくても、 特定のホスト制限やSMS認証が必要な状況でも、 許可されたアカウントだけはそれらの制限を受けずに投稿できるという柔軟な対応が可能になります。
アカウント申請を全て自動承認にすると、BANされても困らないように大量の捨てメアドを用意して、複数アカウント登録されることが想定されます。上記のようなSMS認証の規制をしても回避できてしまうようになるので反対です。
もう少し柔らかく制限したい場合について
ホワイトリストに入っているアカウントに対して、 「コントロールパネル」の「規制ルール」を回避できるオプションを設けることも検討できます。
また、SMS認証が困難な海外在住ユーザーでも、アカウントを通じて投稿できるようになります。
この仕様についても、引き続きご意見をお待ちしています。
申請者のホワイトリスト自動登録について
実質的には「申請ボタン付きのゲスト投稿」となってしまいます。
本来の目的は、大規模な荒らしが発生した際に、投稿者を一時的に絞り込むための緊急対策です。 そのため、自動でホワイトリストに登録してしまう運用は、本来の意図を損なうことになるのではないかと思います。
安全性を確保するため、申請内容を確認してから許可する手動方式を想定しています。 この仕様についても、引き続き皆さまのご意見をお待ちしています。
また、このホワイトリストは今後、「信頼されたアカウント」としての扱いになる可能性があるため、 慎重に進めていく必要があると考えています。
ご不便をおかけして申し訳ありません。
ご利用のネットワークは、Googleが提供するクラウドサーバー（bc.googleusercontent.com）経由となっております。 この経路からは現在も多数の不正アクセスが確認されているため、特定の操作に一部制限をかけさせていただいております。
お手数ですが、別のネットワーク（ご自宅のWi-Fiやスマートフォンの通信など）からのご利用をお願いいたします。
ご確認ありがとうございます。 今後ともよろしくお願いします。
上記2点の変更をこちらでも確認できました。対応ありがとうございます。
不具合のご報告ありがとうございます。 次のように改善しました。
お手数ですが、ご確認のほどよろしくお願い申し上げます。
ご提案頂いた内容に概ね賛成します。アカウント機能については、現状のzawazawaアカウントと統合・再利用されるような形だと非常に分かりやすく、管理もしやすいのではないかと思います。
>> 23さんの仰っているコメントと編集のロックダウン分離については私も反対します。実際、荒らし行為が発生した際、どちらかのみを規制してももう一方で荒らし行為が継続するケースもあり、わざわざ分離するメリットはないかと思います。
当サービスは、誰でも自由に投稿できることを基本としています。 そのため、アカウントを持つ人だけが投稿できるような恒久的な仕組みは設けない方針です。
賛成します。（Wikiとは本来そういうものです）
>> 23 wiki編集とコメント投稿の制限を個別に設定できたほうが…
反対します。「利便性が高く」とありますが、何の利便性が向上するのでしょうか。
これをやると、編集は身内のみ可、ゲストユーザーはコメント投稿のみ可という閉鎖的なWikiが実現できてしまいます。 この機能（ロックダウン）は、閉鎖的なWikiの実現を目的とするものではなく、 あくまで大規模荒らしに対応するための（一時的な）機能であるべきです。
投稿できるアカウントは申請制とし、 管理者やサブ・パスワード保持者が申請内容を確認し、許可した場合のみ使用可能とします。
ホワイトリスト方式自体に反対はしませんが、 アカウントを申請すると自動でホワイトリストに登録されるようにした方が、 ユーザーの編集参加に対する敷居が低くなり、 閉鎖的なWikiを作ろうとする管理者の恣意的な運用も避けられるのではと思います。
運営が仰るように、 万が一、許可されたアカウントが不正な投稿を行った場合は、 そのアカウントをホワイトリストから削除することで対処すればよいので。 （リスト削除後に、同じID者の再登録をブロックできる機能がないとダメかな？）
追追記：
ホワイトリストの自動登録については反対意見が多いようですね。 運営自体が否定的な見解をお持ちなので、実現性は低いように思いますし、 別にそれでも構わないのですが、 一つ気になるのが「複数のメルアドで複数のアカウントが持てる」と考えている方が多いということです。
そんなザルのようなシステムなら、自動だろうと手動だろうとホワイトリスト方式自体に賛成できかねます。
申請時には、IPアドレス・Cookie・ブラウザ情報（User-Agentなど）もあわせて送信され、 過去の投稿と照らし合わせて、荒らし等の問題がないかを確認するために使用されます。
「同じID者の再登録をブロックできる機能がないとダメかな？」と書きましたが、 ホワイトリストの（自動）登録には、 同一人物が別のアカウントを持とうとする行為を（自動で）BANできる機能が欠かせないように思います。
素人考えでは可能だと思うのですが、 仮に難しいということであれば、ホワイトリストの自動登録は難しいということになるでしょうし、 容易に複数アカウントが持てるシステムということなら、自動・手動以前の問題でしょう。
手動登録の場合は、上に書いたように、身内以外の申請を全て不許可にすることで、 閉鎖的なWikiを作ろうとする管理者に恣意的に運用される可能性があるため、 諸手を挙げての賛成はできないというのが正直な感想です。
ロックダウン機能に関して投稿・編集を制限できるとのことですが、これにはコメントの書き込みも含まれるのでしょうか？
一括で制限するのではなく、zawazawaのようにwiki編集とコメント投稿の制限を個別に設定できたほうが利便性が高く需要に合うと思います。
ご意見ありがとうございます。 これまでに寄せられたユーザーの皆さまのご要望・議論をふまえ、 総合的に検討した結果、以下のような仕様が適切ではないかと考えております。
ロックダウン機能とアカウント制の導入について、 現時点での案を以下にまとめました。
なお、本仕様はあくまで検討中の内容であり、確定ではありません。 今後、皆さまのご意見をいただきながら、柔軟に見直しを行っていく予定です。
仕様の背景と基本的な考え方
ただし、大規模な荒らし行為が発生した場合に備え、 投稿を一時的に制限できる「ロックダウン」機能の導入により、緊急時の対応を可能にしたいと考えています。
仕様内容（ロックダウンとアカウント制）
ロックダウンは、管理者用のコントロールパネルからON/OFFを切り替えることができます。
ロックダウンがONになると、投稿・編集できるのは 「管理者」「サブ・パスワード保持者」「あらかじめ許可されたアカウント」に限定されます。
閲覧はロックダウン中も制限されず、これまで通り誰でも可能です。
投稿できるアカウントは申請制とし、 管理者やサブ・パスワード保持者が申請内容を確認し、許可した場合のみ使用可能とします（ホワイトリスト方式）。
申請時には、IPアドレス・Cookie・ブラウザ情報（User-Agentなど）もあわせて送信され、 過去の投稿と照らし合わせて、荒らし等の問題がないかを確認するために使用されます。 ※ロックダウン後にアカウントを作成した場合でも、過去の投稿と紐づけて判断できるようにするための仕組みです。
アカウント名は投稿ログ（diff_log）には表示されず、匿名性はこれまで通り維持されます。 ※ただし、管理者用のコントロールパネルではアカウント名を確認できます。
万が一、許可されたアカウントが不正な投稿を行った場合は、 そのアカウントをホワイトリストから削除することで対応します。
アカウント機能の設計について
現在、WIKIWIKIには一般ユーザー向けのアカウント機能は存在していません。 そのため、アカウント制を導入する場合は、新たな設計が必要となります。
一方、多くのユーザーがすでにzawazawaアカウントを利用しており、 別々のアカウントを併用する形にすると、ユーザー・運営の双方に管理負担が生じる可能性があります。
今後、WIKIWIKIとzawazawaは運用基盤の統合を予定しているため、 zawazawaアカウントをWIKIWIKI共通アカウントとして再利用する方向も検討中です。
仕様案についてのご確認
この仕様は、ユーザーの皆さまのご意見やこれまでの議論をもとに、運営として整理・検討中の内容です。 あくまで確定したものではなく、今後の調整にあたってもユーザーの皆さまのご意見を参考にしていきます。
この仕様については、引き続きユーザー同士で自由に議論・意見交換を行っていただければと思います。
#を外して記述してプラグインとして殺せば期待通りの結果が得られるのですか。 inculdexのオプションがあると動作がちがうのですか。exceptのcounter抜いてみたらどうなりま すか。
#
おっしゃる通り、exceptのcounterを抜いてから、想定している挙動になりました。どうもありがとうございます。自身の検証では指摘内容に気づけませんでした。includexがexceptに合致した行は、無視してカウントする仕様だとは思わずに不具合を疑っていました。
不具合を疑うことになった記述内容 #includex(MenuBar,num=14:,except=_now|counter,titlestr=off) 今回の場合、exceptに合致する行が3行あるので実際に表示させたい参照先の指定行が17行目であっても、14行目にするのが正しい
#includex(MenuBar,num=14:,except=_now|counter,titlestr=off)
参照先にaccordionプラグインでincludexプラグインの行を括ると正しく参照しなくなります。
#を外して記述してプラグインとして殺せば期待通りの結果が得られるのですか。 inculdexのオプションがあると動作がちがうのですか。exceptのcounter抜いてみたらどうなりますか。 機能を疑うなら検討用のページを作って、シンプルな記述にして検証してみてください。
Steamはメジャーなサービスであるとは言え、基本的にはPCゲーム用の限定的なプラットフォームです。 専用プラグインがあるYoutubeやX(Twitter)はSNSサービスであり、どのWIKIでも汎用的に扱うことができますが、 Steamの場合は限定的な用途となってしまい汎用性に欠けると言わざるを得ません。
要望に関して反対はしませんが、個人的には導入された際のメリットがそれほどあるように思えず、 上記の点も考慮すると実装される見込みは薄いのではないかと思います。
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内の検索にコマンド自体置換されてしまっています)
ホワイトリストの自動登録について反対です。
他の方も書かれている様に、捨て垢、特に複数回線を持つ人物による荒らしに対応出来ないと考えます。
そもそも論、ホワイトリスト登録を自動承認制にするとブラックリストと呼ばれるべき機能になる気がします。
ロックダウン機能において編集とコメント投稿の制限を個別にできた方が良いという理由に関して書きます。
経験上、wiki利用者は閲覧のみのユーザーが一番多く、ついでコメントを投稿するユーザー、そして一番少ないのが編集に参加するユーザーのように思われます。提案されているロックダウンの仕様は閲覧のみのユーザーには影響がありせんし、編集に参加する熱心なユーザーにも抵抗感は少ないと思います。
しかし、中間層であるコメントを投稿するユーザーは匿名の場でやり取りを好んでいる傾向があり、アカウントを作成してまで利用し続けようとするユーザーは少数派です。
編集・解説がwikiの大きな役割であることは間違いありませんが、コメントによるユーザー間の交流も人気のコンテンツである事もまた事実です。コメントページのビューの多さからコメントのやり取りを見るために定期的に訪れている閲覧のみのユーザーもかなりの割合存在します。そのためロックダウンで一括して制限をかけた場合、wiki利用者の大部分にとってサービスとしての価値が失われた状態になります。
編集やコメント書き込みなど個別に制限を設定できるというのは選択肢の多さであり、個別設定できないよりも柔軟性があり利便性が高いのは明らかな事実です。
そもそもロックダウン機能は果たして荒らし行為に対して有効な対策なのか？という疑問も主張の根底に存在します。仮に荒らし行為が原因で一括のロックダウンを実施したとして、先述の通り多くのユーザーにとっては利用価値が大きく損なわれた状態にるわけであり、それこそが荒らしの思う壺ではないでしょうか？
仮に編集のみのロックダウンならば大半のユーザーに取って影響はありません。しかし、コメントのようなコミュニケーション部分はロックダウン機能との相性が極端に悪く、どちらかといえばミュート機能やシャドウバン、ユーザーが個別に設定できるNGワードなどより適した手段が存在するように思います。
ホワイトリストの自動登録について反対です。他Wikiでは、編集・利用ルールをちゃんと読んでいるかを確認するためのWiki管理者が用意した質問で、アカウント申請時にWiki管理者へのメッセージ欄を設けて回答を求めるようなところもあります。アカウント申請だけで質問に未回答だったりルール未読と判断出来れば、その時点で却下できます。
アカウント申請を全て自動承認にすると、BANされても困らないように大量の捨てメアドを用意して、複数アカウント登録されることが想定されます。上記のようなSMS認証の規制をしても回避できてしまうようになるので反対です。
もう少し柔らかく制限したい場合について
ホワイトリストに入っているアカウントに対して、
「コントロールパネル」の「規制ルール」を回避できるオプションを設けることも検討できます。
この仕組みがあれば、ロックダウンのようにすべての投稿を一律にブロックしなくても、
特定のホスト制限やSMS認証が必要な状況でも、
許可されたアカウントだけはそれらの制限を受けずに投稿できるという柔軟な対応が可能になります。
また、SMS認証が困難な海外在住ユーザーでも、アカウントを通じて投稿できるようになります。
この仕様についても、引き続きご意見をお待ちしています。
申請者のホワイトリスト自動登録について
実質的には「申請ボタン付きのゲスト投稿」となってしまいます。
本来の目的は、大規模な荒らしが発生した際に、投稿者を一時的に絞り込むための緊急対策です。
そのため、自動でホワイトリストに登録してしまう運用は、本来の意図を損なうことになるのではないかと思います。
安全性を確保するため、申請内容を確認してから許可する手動方式を想定しています。
この仕様についても、引き続き皆さまのご意見をお待ちしています。
また、このホワイトリストは今後、「信頼されたアカウント」としての扱いになる可能性があるため、
慎重に進めていく必要があると考えています。
ご不便をおかけして申し訳ありません。
ご利用のネットワークは、Googleが提供するクラウドサーバー（bc.googleusercontent.com）経由となっております。
この経路からは現在も多数の不正アクセスが確認されているため、特定の操作に一部制限をかけさせていただいております。
お手数ですが、別のネットワーク（ご自宅のWi-Fiやスマートフォンの通信など）からのご利用をお願いいたします。
ご確認ありがとうございます。
今後ともよろしくお願いします。
上記2点の変更をこちらでも確認できました。対応ありがとうございます。
不具合のご報告ありがとうございます。
次のように改善しました。
お手数ですが、ご確認のほどよろしくお願い申し上げます。
ご提案頂いた内容に概ね賛成します。アカウント機能については、現状のzawazawaアカウントと統合・再利用されるような形だと非常に分かりやすく、管理もしやすいのではないかと思います。
>> 23さんの仰っているコメントと編集のロックダウン分離については私も反対します。実際、荒らし行為が発生した際、どちらかのみを規制してももう一方で荒らし行為が継続するケースもあり、わざわざ分離するメリットはないかと思います。
賛成します。（Wikiとは本来そういうものです）
反対します。「利便性が高く」とありますが、何の利便性が向上するのでしょうか。
これをやると、編集は身内のみ可、ゲストユーザーはコメント投稿のみ可という閉鎖的なWikiが実現できてしまいます。
この機能（ロックダウン）は、閉鎖的なWikiの実現を目的とするものではなく、
あくまで大規模荒らしに対応するための（一時的な）機能であるべきです。
追記：
ホワイトリスト方式自体に反対はしませんが、
アカウントを申請すると自動でホワイトリストに登録されるようにした方が、
ユーザーの編集参加に対する敷居が低くなり、
閉鎖的なWikiを作ろうとする管理者の恣意的な運用も避けられるのではと思います。
運営が仰るように、
万が一、許可されたアカウントが不正な投稿を行った場合は、
そのアカウントをホワイトリストから削除することで対処すればよいので。
（リスト削除後に、同じID者の再登録をブロックできる機能がないとダメかな？）
追追記：
ホワイトリストの自動登録については反対意見が多いようですね。
運営自体が否定的な見解をお持ちなので、実現性は低いように思いますし、
別にそれでも構わないのですが、
一つ気になるのが「複数のメルアドで複数のアカウントが持てる」と考えている方が多いということです。
そんなザルのようなシステムなら、自動だろうと手動だろうとホワイトリスト方式自体に賛成できかねます。
「同じID者の再登録をブロックできる機能がないとダメかな？」と書きましたが、
ホワイトリストの（自動）登録には、
同一人物が別のアカウントを持とうとする行為を（自動で）BANできる機能が欠かせないように思います。
素人考えでは可能だと思うのですが、
仮に難しいということであれば、ホワイトリストの自動登録は難しいということになるでしょうし、
容易に複数アカウントが持てるシステムということなら、自動・手動以前の問題でしょう。
手動登録の場合は、上に書いたように、身内以外の申請を全て不許可にすることで、
閉鎖的なWikiを作ろうとする管理者に恣意的に運用される可能性があるため、
諸手を挙げての賛成はできないというのが正直な感想です。
ロックダウン機能に関して投稿・編集を制限できるとのことですが、これにはコメントの書き込みも含まれるのでしょうか？
一括で制限するのではなく、zawazawaのようにwiki編集とコメント投稿の制限を個別に設定できたほうが利便性が高く需要に合うと思います。
ご意見ありがとうございます。
これまでに寄せられたユーザーの皆さまのご要望・議論をふまえ、
総合的に検討した結果、以下のような仕様が適切ではないかと考えております。
ロックダウン機能とアカウント制の導入について、
現時点での案を以下にまとめました。
なお、本仕様はあくまで検討中の内容であり、確定ではありません。
今後、皆さまのご意見をいただきながら、柔軟に見直しを行っていく予定です。
仕様の背景と基本的な考え方
当サービスは、誰でも自由に投稿できることを基本としています。
そのため、アカウントを持つ人だけが投稿できるような恒久的な仕組みは設けない方針です。
ただし、大規模な荒らし行為が発生した場合に備え、
投稿を一時的に制限できる「ロックダウン」機能の導入により、緊急時の対応を可能にしたいと考えています。
仕様内容（ロックダウンとアカウント制）
ロックダウンは、管理者用のコントロールパネルからON/OFFを切り替えることができます。
ロックダウンがONになると、投稿・編集できるのは
「管理者」「サブ・パスワード保持者」「あらかじめ許可されたアカウント」に限定されます。
閲覧はロックダウン中も制限されず、これまで通り誰でも可能です。
投稿できるアカウントは申請制とし、
管理者やサブ・パスワード保持者が申請内容を確認し、許可した場合のみ使用可能とします（ホワイトリスト方式）。
申請時には、IPアドレス・Cookie・ブラウザ情報（User-Agentなど）もあわせて送信され、
過去の投稿と照らし合わせて、荒らし等の問題がないかを確認するために使用されます。
※ロックダウン後にアカウントを作成した場合でも、過去の投稿と紐づけて判断できるようにするための仕組みです。
アカウント名は投稿ログ（diff_log）には表示されず、匿名性はこれまで通り維持されます。
※ただし、管理者用のコントロールパネルではアカウント名を確認できます。
万が一、許可されたアカウントが不正な投稿を行った場合は、
そのアカウントをホワイトリストから削除することで対応します。
アカウント機能の設計について
現在、WIKIWIKIには一般ユーザー向けのアカウント機能は存在していません。
そのため、アカウント制を導入する場合は、新たな設計が必要となります。
一方、多くのユーザーがすでにzawazawaアカウントを利用しており、
別々のアカウントを併用する形にすると、ユーザー・運営の双方に管理負担が生じる可能性があります。
今後、WIKIWIKIとzawazawaは運用基盤の統合を予定しているため、
zawazawaアカウントをWIKIWIKI共通アカウントとして再利用する方向も検討中です。
仕様案についてのご確認
この仕様は、ユーザーの皆さまのご意見やこれまでの議論をもとに、運営として整理・検討中の内容です。
あくまで確定したものではなく、今後の調整にあたってもユーザーの皆さまのご意見を参考にしていきます。
この仕様については、引き続きユーザー同士で自由に議論・意見交換を行っていただければと思います。
おっしゃる通り、exceptのcounterを抜いてから、想定している挙動になりました。どうもありがとうございます。自身の検証では指摘内容に気づけませんでした。includexがexceptに合致した行は、無視してカウントする仕様だとは思わずに不具合を疑っていました。
不具合を疑うことになった記述内容
#includex(MenuBar,num=14:,except=_now|counter,titlestr=off)今回の場合、exceptに合致する行が3行あるので実際に表示させたい参照先の指定行が17行目であっても、14行目にするのが正しい
#を外して記述してプラグインとして殺せば期待通りの結果が得られるのですか。
inculdexのオプションがあると動作がちがうのですか。exceptのcounter抜いてみたらどうなりますか。
機能を疑うなら検討用のページを作って、シンプルな記述にして検証してみてください。
Steamはメジャーなサービスであるとは言え、基本的にはPCゲーム用の限定的なプラットフォームです。
専用プラグインがあるYoutubeやX(Twitter)はSNSサービスであり、どのWIKIでも汎用的に扱うことができますが、
Steamの場合は限定的な用途となってしまい汎用性に欠けると言わざるを得ません。
要望に関して反対はしませんが、個人的には導入された際のメリットがそれほどあるように思えず、
上記の点も考慮すると実装される見込みは薄いのではないかと思います。