リクエスト広場

関連してお伺いしたいのですが、
日付形式はコントロールすることは不可能という理解であってますよね？
＃yyyy/mm/dd だけ表示したくても 2023-05-14 (日) 11:35:13 とフルで表示

前方からx文字切り取って表示、みたいな機能は（汎用性もなさそうだし）存在しませんね？

()内はリンクで記載ということですね
お二方ともご回答いただきありがとうございました！

ご検討ありがとうございます。
機能追加がされない場合には代替案で対応したく思います。
＃機能追加に関して、いちユーザでアクションできることはなくて、様子見しかできない理解でよかったですかね？

失礼しました。以下のように記載することでお望みの動作になります。

&lastmod([[Wiki管理/リセマラおススメ人格・EGO]]); 更新

TOPページを指定する場合
&lastmod(FrontPage); 更新

&lastmod([[Wiki管理/リセマラおススメ人格・EGO]]);

すみません、詳細の書き方が悪かったですね。

FrontPage に Wiki管理/リセマラおススメ人格・EGO の更新日時を表示させたい
＃文字列「随時更新」→「yyyy/mm/dd 更新」に置き換えたいイメージ

という場合に、以下の書き方で更新日時を取得できると考えていましたが、更新日時が表示されません。
 &lastmod(Wiki管理/リセマラおススメ人格・EGO);
＃Wiki管理/リセマラおススメ人格・EGO内で 引数なしで &lastmod(); 記載した場合は正しく機能している

プラグインの説明では引数にページ名を指定すればよさそうですが、
①理解を間違えているのか、②機能としてバグってるのか、③説明自体が誤っている/古いのか判別付かないためご報告させていただきました。

機能追加
非表示機能を作る。

ソースを解釈しhtml変換した上で、ブラウザー上非表示にする機能。
対象は見出しに限定しない。何か他でも使えるかもしれない。
null{{}}は内容を解釈しないので、今回の件では使えない。
accordion、contents、contentsx、contents2_1の方をいじるより効率的。

例えばnodisplayというマルチライン機能として以下のようになればよい。
この書き方ならaccordionが見出し2の配下に置けるので、素直に掛ける。
ただ非表示だとアンカーに飛べないかもしれないので、contentsリンクに対応するanameは自分で書く必要があるかも。

#contents
*1 [#a1]
#nodisplay{{
*2 [#a2]
}}
//&aname(a2);
#accordion(2,*,close){{
内容
}}
*3 [#a3]

accordionをあたかも通常見出しのようにcontentsに出力させる

代替案1
accordionの中にcontentsに表示させたい見出し行を書く。
ただしcloseだとcontentsのLinkから飛べないので次のようにする。

• 見出しのアンカーを自分で指定するか、ランダムで与えられたIDを確認
• accordionの手前に同名のアンカーを設置

  #contents
  *1 [#a1]
  &aname(a2);
  #accordion(2,*,close){{
  *2 [#a2]
  内容
  }}
  *3 [#a3]
  

この方法の問題点として
accordionを開いたとき、accordion帯と見出し帯が二重に表示される。
accordionの書き出し位置が前の見出しの途中にあり、終了位置は次の見出し内にあることが、何か問題あるかもしれない。

代替案2
contentsを使わずに手書きで目次を書く。

-[[1>#a1]]
-[[2>#a2]]
-[[3>#a3]]

*1 [#a1]
&aname(a2);
#accordion(2,*,close){{
内容
}}
*3 [#a3]

ただしaccordionは1の配下にいる。
accordionは1と同格扱いにしたいのでバランスが悪い。
includexのsectionでも*2を指定できない。

おそらくページタイトル下のLast-modifiedが実際の最終更新した日時と違う場合は、スパム・BOT対策などの理由で運営のシステムが定期的に巡回した時刻になっています。その際、時刻右横にアイコンが表示されます。人の手で最終更新した日時は、そのアイコンを押すと判明します。各ページの最終更新履歴も併せて、ご確認ください。

Braveなど広告非表示機能をもったブラウザを使うか、Adblockerのような拡張機能を導入すればよいと思います。運営が対応するようなことではないかと。

Firefox→先程113リリース、アニメーション正式対応
Edge→Dev版+オプション付与で確認済み（Windows Storeから入手できるAV1拡張を一旦削除しても正常に見れましたが、なぜかWindows SandboxにDev・Canary版をインストールしてオプションを付与しても見れませんでした）（あと数日後にはBeta版リリース予定のはずです）

なお、想定しているユースケースをWebPでアップロードしようとしましたが「複雑過ぎます」と出て失敗しました。AVIFだと縦横の幅を各1.3倍ずつに増やしても容量を7割ほどに減量できます。

現在の機能で問題を解決する方法として

#memoxでコピーしたい内容を書いて、
当該領域を全選択(Ctrl + A)+コピーすればよいです。
memoxなら表示領域の高さも制御できるので長い内容も場所を取られません。

また、ページ丸ごとコピーなら画面上部の複製ボタンが使えます。

1ページに複数のテンプレートが記述されてるなら
見出しに別に内容を分けて、見出し内編集画面を開いて、全選択(Ctrl + Aか、編集ボタン→すべてを選択)してコピーとか色々方法はあります。

#copy{{
内容
}}

みたいに書いて、内容htmlではなくソースで出力され、Copyボタンを押すと内容がクリップボードに送られるような感じですか。
あるいは画面上の表示はhtml出力で、Copyされるのはソースの内容か。

そんなに利用頻度は多くないんじゃないでしょうか。
私なら、編集画面開いて直接内容をコピーするか、メモ帳にでも書いておきます。

ただ機能の目的がwiki編集のテンプレートコピーだけではなく、例えば
#codeに書かれた内容を他のソフト(スクリプトとかスプレッドシートとか)で流用するとか
どこかのサイトに入力する申し込みコードだったりとかなら、多少使い勝手があるかもしれません。
あとは操作が面倒なスマホ向けには需要があるかもしれません。

そうであるなばら、前者なら#code(copy){{内容}}みたいな#codeのオプションのほうが使いやすく
後者なら表に組み込めるインライン型のプラグインが良いと思います。&copy{};のような。

トピック作成者です。
>> 2の方の方法で概ね目的を達成できたので当面問題はなさそうです。ご提案いただきありがとうございました。（お礼が遅くなりすみません。）

私も開閉の記憶機能が欲しいです。私がよく使うのはntbrプラグインなのですが、記憶機能があったほうがどこに何があったのかいちいち覚えておく必要がなくて操作が楽になるだろうなと感じていました。

(1)について、こちらでも検証してみたところreset=offとreset=newでは処理時間が全く短くならなかったので、確かに機能していないようです。reset=秒数だと爆速になりました。
ecacheを利用する際の混乱の元になると思うので、運営様には動作の修正、またはこの問題が認知されやすいように発表や文書への注意書きなどをお願いしたいですね。

ページ毎のMenuBar、私の要求だけならだいたいこれですね。関連ページは多いですが、逆に多いほど使える気分です。全く念頭から抜けていたので、助かりました。ありがとうございます。

「ページ遷移時にfoldの開閉状態を維持する」機能に変わる方法

• ブラウザーの操作で新規タブやWindowで開く
  私の場合、リンク先に遷移後戻ってくる状況が予めわかっていれば、新規タブ(Ctlr + クリック)で開きます。
  リンク先の用が済んだらページを閉じて(Ctlr + W)、リンクを開いた画面に戻ります。
  操作の煩雑さが人により異なりますが、マウスのボタンに機能を割り当てれば右手だけで完結します。

• ページ毎に個別にMenuBarを設定する
  ページ毎にメニューは独自に設置できます。
  例えば各foldのカテゴリーページにはそれらのをopen状態にしたメニュー(#menu(MenuBar/A)とか#menu(MenuBar/B)とか)を設置すれば要求通りの動作になると思います。ただページ数が多いと面倒ですが。
  関連してSideMenu(#side(ページ名))とか、
  foldカテゴリーを階層化してるならSideBarなどの機能も使えるかもしれません。

「ページ遷移時にfoldの開閉状態を維持する」をメニューに限定せず意見を述べると次の通りです。

• 記憶型foldはあっても良いが、個人的にはメニューでは使わない。
  ページ本文のほうは使えるかもしれない。(明確な計画はない。)
• 導入するならpluginのオプション書式で従来型か記憶型か選択式であるべき。
• 閲覧者がそのfoldが従来型か記憶型か判別できること。
  例えば、記憶型を初期状態から変えた場合、田マークが点滅してアピールする。初期状態がOpenの場合もあり。
• リセットコマンドがあること。
  どこを触ったのか覚えてられないし目で探すのも大変、入れ子になってるとさらに面倒。
  コマンドリンクはメニューやHeaderに仕込んでおく。リセットがページ毎のなのかサイト全体なのか選べるとなお良いが。
• includeでfoldを呼び出してる場合どうなるのか

ご検討ありがとうございます。
「動画」というほどでもなく、アニメーションGIFの代替です。音声は不要です。
本物の動画形式はすっかり枯れたH.264の代替の再生環境が整っていないのでまだ時期尚早です。

個別にトピックを設置した方がよければ修正します。

なお、「やや改善」のタグが付いているのは自分のミスです。
全く改善されていません。

Wikipediaが最近、UIデザインをこの仕様に変更されて私はPC閲覧時に使い勝手が良くなりました。
表示画面の横幅が狭くなると、目次が左上にアイコン化もされ、コンパクトサイズになる点も良いです。
表示領域が狭い人向けに選択肢があると良いかもしれません、
参考記事

たくさん#foldを開いた後、戻すために一括開閉があってもいいですが、初期状態に戻すというのもできればほしいと思います。

1つのボタンで開閉
2つのボタンで開/閉
3つのボタンで開/閉/初期化
をオプションで選択できればいいな

>11で別フレームで本文を表示して本文だけページ遷移する提案をしましたが、これが実現できる場合はメニューの状態はそのままの方がいいと思います。
別フレームが実現できなければそれもありかなと思います。

スマホのことだけではないですが
メニューの表示方法についての要望としてトピックを立てました。

ついでにスマホのメニューの提案からの派生ですが、PCのメニューでも閲覧者が任意にメニューを非表示にして本文を広くできるようにしてもいいかもしれません。
ただし、スマホは本文の上にかぶさって現れるイメージですが、PCの場合は本文の幅自体が変化するということなので動作はちょっと異なります。
また、#nomenubarを使っているページに対する動作をどうするかという問題もあります。

「より細かい角度の調節」ができるようになりました。

スマホでのメニューは編集のメニューみたいに左からピロっと出るようにしてほしいかも。
こちらは別にトピック立てた方がいいかな？

別トピックで詳しく書いていただけたら幸いです。

議論していただきありがとうございます。
MenuBarに#foldを多数設置した場合、ユーザーによってはいくつもクリックして開くと思います。
これらも全て記録した場合、ページ遷移後に見にくくなる気がします。

メニューにある現在関心のあるカテゴリの開いている部分については開いたままにしておいてほしい欲求があります。

例えば、ページ遷移後、「最後にクリックしたリンク」の位置を確認できるようにして、
もし、#foldの中だったら開く。このような動きはいかがでしょうか？

引き続き議論いただけたら幸いです。

PC閲覧時に便利そうです。状況によって、PCとモバイルを使い分けしながら同じWikiを利用する方には、PCの操作記憶がモバイルでも適用されてしまうと手間が増えて、使い勝手が悪くなります。そのため、同じネット回線でも使用環境が違えば、個別に記憶される仕様なら良いです。その様に利用することが多いので、機能を追加されるのならば配慮していただけると嬉しいです。

メニューの開閉を覚えておくことの弊害として思いついたんですが、スマホで見る場合はメニューがサイドではなく下に行ってしまうので開いた下のメニューへ行くためには開いた項目を閉じるかさらにスクロールする必要がでてきます。

あと、このトピックの趣旨とは異なりますが、長い本文を見てメニューに行きたくなる場合は上までスクロールで戻る必要があるのでメニューと本文が別フレームになってるといいなと思います。
そしてメニューの開閉はそのままに本文だけページが変わるようにできたらいいなと思います。
スマホでのメニューは編集のメニューみたいに左からピロっと出るようにしてほしいかも。
こちらは別にトピック立てた方がいいかな？

うーん、サイドメニューって主要なものだけ必要最低限載せるイメージがあるんですが
折り畳みのみを膨大な数載せる使い方をしていると言われたら、個別のWikiの事情になるのでは？
どちらにしてもURLのリンク集的な感じではない限り、1度開いた折り畳みを閉じずにずっと見る状況ってなかなかないと思いますが、僕はどちらでもOKです。

レディース・メンズのような"主要なものが閲覧者によって異なる"場合、そしてそれが膨大である場合、
全部closeにして一括開閉ボタンを置いたとしても一括開閉をクリックした後にスクロールする二度手間になってしまうのではないでしょうか？
そう考えると私は記憶しておいてくれる方がありがたいと思います。
たかが1クリックと言えどメニュー内の開閉は一度二度ではありませんから、それが減るというのは大きなメリットでしょう。

一括開閉はメニューよりもむしろページ内で活きる機能なのではないかと思います。
何らかの長くなる話題を細かく折り畳んでいる際、掻い摘んで読まずに全てを読みたいという場面で役立つでしょうね。
今回の要望内容からは外れますし局地的ですが。

一括開閉ボタンいいですね！メニューバーとかに設置できると利便性高そうです

あ、言葉足らずでした
全部closeにするか、主要なものだけopenにして他はcloseにするのではだめなんですか？
便利な機能だとは思うんですが、1クリックを面倒くさがるかどうかの話なような気がしています。

他の情報を見たい場合はクリックする手間は発生すると思うので、無いことのメリットを考えるほうが難しい気がしていますがあんまり魅力を感じないです。一括開閉ボタンでもいい気がします。

設定する場合はコントロールパネルからサブパスワード保持者か管理者ができるようにすればいいと思います。
詳しくなくて申し訳ないんですが、wikiwikiってゲストユーザ単位で何かを設定するようの画面ってあるんですかね？あればそちらでオンオフするような形にすればいいのかなと思います。

結局この仕様(?)不具合(?)は解消されたのでしょうか。個人的にはreset=newが動いているとは思えないのですが…

利用者としては主要な目的はinclude系プラグインの上限緩和であり、こちらは機能しているので差し迫った問題ではないのですが、
>負荷をかけているWIKIについて
>サーバーに負荷をかけているWIKIはサーバーのリソースを食い潰さないようにするため、
>専用の隔離サーバーにダウングレードいたします。
>積極的にecacheプラグインを使用してください
とあり、reset=newでecacheプラグインを導入しているにも関わらずサーバー負荷軽減に寄与できていないケースがあるとすれば互いに損失かと思います。

ずっと開きっぱなしがいいのであれば、編集時にそうするではだめなんですか？

全部開きっぱなしではメニューが冗長になるが、その中で閲覧者が見たい項目は開いたままにしておきたい。という話なのだと思います

他所のサービスですが、PSO2:NGS攻略Wikiのように大規模なWikiの場合に必要とされる機能だと思います
例に挙げた作品はクエスト、フィールド、武器防具、キャラクリと分けても要素が相当量あるので、閲覧者側で開閉を記憶しておけないと少々見辛いでしょうね

ありがとうございます😍

私が利用しているWikiではサイドメニューにaccordionとfoldをどちらも使っていますが特に問題ないと思いますよ
使った上で適切かどうか判断してそれをこちらに記載するのがいいと思います

サイドメニューにaccordionを用いるのが適切なのかはあまり了知していません。