ご意見ありがとうございます。
言葉通り、データを差し戻すために使用するものなので、そういったデータを誰でも触れるようにはしてほしくないです。
誰でもではないですね。 今回の提案はあくまでも、個々でアップした添付ファイルを 個々でバックアップも含めて削除できるようにしてほしいという事です。
管理者の方、又は他の方の添付ファイルなどは 自由に削除することは出来ませんので。
上に書いていますのでまとめます。
サイズ間違え、更に画質の不具合で添付した場合は バックアップなどから差し戻す必要はありませんよね？
しかも、そのようなものを他の人に見られてしまうと 何か恥ずかしい気持ちにもなりますし 添付するのも躊躇してしまいますよね？ その為にアップロード者がバックアップも含めて 削除できるようにして頂きたいです。 そうすれば、もっと気軽に添付も出来るような気がします
簡潔に言うと、上記の失敗してアップした画像などのバックアップは 必要なく、正しく添付されたバックアップが必要かと思います。 そうすることにより管理者の管理がしやすくなるメリットもあります。
以上の事から提案をさせたいただきました。 ご意見をお待ちしています。
バックアップを削除できるようにするのは反対です。 言葉通り、データを差し戻すために使用するものなので、そういったデータを削除したいという考え方は変えるべきです。 管理の面から考えて誰でも消せる状態にあるほうがおかしいです。
添付されてるファイルは誰でも削除できますが、バックアップされたものは用途が変わります。
管理者がいないというのは、そのWikiの事情になるので言われても分かりませんが サブパスワードで削除できれば、サブパスワード持ちを増やすなりすることで1人しか対応できないなどの問題は解決すると思います。 サブパスワードで削除できないのであれば、削除権限を与える要望などを運営に出してみるといいと思います。
管理者が不在というのはそのWikiの特別な事情なので別の問題ではないですか？ wiki内で立候補者を募って運営に引き継ぎの申請をするのがいいと思います。
それは、時にはアラシが無断転載をしてファンアートを添付しているのが見えるためにもあります。
そもそもwiki全体に渡る容量制限があるわけでもないので、 削除したページの添付画像も削除したいのはどうしてかという意図が見えません。 まずはそこを書いた方が良いかと思います。
ごめんなさい、急いで投稿した為、書き忘れたことがありますので ここで補足させてください。
サイズ間違え、更に画質の不具合で添付した場合は バックアップなどから差し戻す必要はありませんよね？ バックアップから差し戻す場合は、荒らしなどが悪意を持って いたずらに削除したりした際に、差し戻す必要があるだけなので
個々で画像添付の場合はサイズ間違え、更に画質の不具合などは 添付した後でないと分からないこともありますので その為、バックアップその物の意味がありません。 その為、個々の画像添付者の判断でもバックアップも含めて 削除できるようにして頂きたいです。
>> 10 このようなことにはならず
test.jpg [詳細] test.jpg (バックアップ No.1) [詳細] test.jpg (バックアップ No.2) [詳細] test.jpg (バックアップ No.3) [詳細] test.jpg (バックアップ No.4) [詳細] test.jpg (バックアップ No.5) [詳細]
簡素化することも可能となります。
どうすれば成功で、そしてそれは誰が判断するのですか? 例えばあなたがアップした画像を私や他の誰かが失敗、もしくは不要と判断して削除したらどうでしょう? 誰でもページや添付ファイルを各自の判断や思惑で削除できるからこそ、 自動バックアップに意味があります。
ですから、前回ご賛同いただいた通り
現在2段階で削除できるようになっていますが 1段階目で従来通り、誰でも削除でき（バックアップは残ります） 2段階目でバックアップの削除のみ管理者に加えてアップロード者も行えるようにする。
こちらの内容で問題はないかと思いますがいかがでしょうか？
もしくは、こちらに変わる、それ以外の方法と言う事になります。
ご意見ありがとうございます
こちらも同感です。 >> 4
管理者がページをきちんと管理できていなかったり 連絡がつかない場合などは非常に不便です。
修正されたようです。
削除を依頼するにしろしないにしろ管理者不在では意味がありませんし。
再度の返信ありがとうございます。
バックアップから差し戻すことも可能です。
下に書いている通りそのような失敗した物をバックアップから 差し戻す必要はありませんよね。 しかも、そのようなものを他の人に見られてしまうと 何か恥ずかしい気持ちにもなりますし 添付するのも躊躇してしまいますよね。 その為にアップロード者がバックアップも含めて 削除できるようにして頂きたいです。 そうすれば、もっと気軽に添付も出来るような気がします。
そもそも、アップロードに失敗するとはどういう意味でしょうか。
それは例えば、画像でしたらサイズ・画質等などです。
失敗・成功? はアップロード者だけが判断できるというのがあなたの主張で、 だから自分がアップした画像のバックアップを削除させて欲しいという依頼なのでしょう。
その通りです。 同じ事の繰り返しになりますが、そもそも、各自で添付したファイルを削除するのに （バックアップも含む）何故、管理者の判断になるのかが理解できません。
上記にも書いていますが、ページ等の物事でしたら理解できますが 添付ファイルについてはアップロード者の個々の判断に任せて頂きたいです。
管理上問題が生じない形で実現可能なら、私自身は賛成ですが…
管理上の問題はないと思います。 こちらの提案はあくまでも添付ファイルの一切管理の物事なので。
何度も差し替えるとバックアップが増えていきます。
それも考えとしてはあります、どれがどれか分からなくなるので。 整理するのが大変なので。
一度削除して削除した名前と同じにすると添付の上に上書きされるという解釈でよろしいでしょうか？
既に削除済みなので、上書きではないです。（普通に差し替えです） バックアップから差し戻すことも可能です。
そもそも、失敗してアップした添付をバックアップとして残す必要があるのでしょうか？
そもそも、アップロードに失敗するとはどういう意味でしょうか。 どうすれば成功で、そしてそれは誰が判断するのですか? 例えばあなたがアップした画像を私や他の誰かが失敗、もしくは不要と判断して削除したらどうでしょう? 誰でもページや添付ファイルを各自の判断や思惑で削除できるからこそ、 自動バックアップに意味があります。
失敗・成功? はアップロード者だけが判断できるというのがあなたの主張で、 だから自分がアップした画像のバックアップを削除させて欲しいという依頼なのでしょう。 管理上問題が生じない形で実現可能なら、私自身は賛成ですが、 失敗したなら差し替えれば済む話なのも事実です。 何度も差し替えるとバックアップが増えていきます。 （記事（ページ）も同様で、更新する毎にバックアップが増えていきます） 古いパックアップが残っているのが気持ち悪いというのは分かりますが、 そういう「仕様」なので、基本的には気にせずとも大丈夫です。
追記： とりあえず、何度も失敗してしまった場合は、wikiの編集ノートに 「管理者さんへ。何度もアップし直してゴメンナサイ。気になるなら古いバックアップを削除してください」 とでも記しておけば良いでしょう。
>> 10
1段階目の削除をすると(バックアップがあると)ファイルの添付のページにファイル名に取り消し線が付いて表示されます。この状態であれば同じ名前で再添付できて現行版になります。
勘違いさせてしまったようですが、要望した一括削除は管理者が行う添付したファイルのバックアップを一括削除できるようにしてほしいということで、ページ破壊を起こすものではありません。
大変失礼いたしました。 こちらはが思っていたことは 管理者以外の方がホームページのバックアップの一括削除の事かと思っていました。 管理者の方が一つ一つ削除するのが大変なので一括で削除できるようにしてほしいと言うことでしたら 管理者なので問題はないかと思います。
そもそも、失敗してアップした添付をバックアップとして残す必要があるのでしょうか？ このあたりも疑問に思います。
↑勘違いしました。 ページ破壊があったときに復旧できるようにするため一括削除が難しいという意味でしたか。
でも現状、ページ自体のバックアップを管理者が一括削除することは可能ですし、添付ファイルのバックアップも管理者の判断で一括削除できてもいいと思います。
削除直後に[バックアップを含む一覧]でみると
test.jpg test.jpg (バックアップ No.1) [詳細]
のように表示され、再添付して詳細を見ると
バックアップ一覧 現行版 バックアップ No.1
バックアップ一覧
現行版 バックアップ No.1
のように表示されます。
勘違いさせてしまったようですが、要望した一括削除は管理者が行う添付したファイルのバックアップを一括削除できるようにしてほしいということで、ページ破壊を起こすものではありません。 削除・再添付を繰り返すと
のようにバックアップがたくさんできて現状ひとつひとつパスワード入力して削除しなければなりません。 管理者のパスワード入力を1回で済ませてほしいということです。
>> 7
1段階目の削除の後同じ名前で添付できますよ？
試したことがないので分かりませんが バックアップにはどのような形で、添付名で残るのでしょうか？
管理者の負担軽減の為に同じページもしくは同じ名前のバックアップは選択削除や一括削除があればいいんですけど。
それは難しいかも知れません。 ページなどのバックアップ等一括削除などは ページ破壊されてしまったときバックアップがないと 復旧することが出来なくなるので運営が認めないと思います。 こちらが思っていることは あくまでも個々でアップした添付ファイルを個々でバックアップも含めた削除の事で ページについては現状のまま管理者が管理を行えば良いと思っています。
間違えて添付しても削除して添付しなおすことは可能なので、都度管理者にお願いする必要はないと思います。 ただ、バックアップの削除は管理者にお願いすることになります。 現在のバックアップの削除は一つ一つパスワード入力が必要なのでバックアップが多いと管理者が大変です。 管理者の負担軽減の為に同じページもしくは同じ名前のバックアップは選択削除や一括削除があればいいんですけど。
ご返信ありがとうございます。
管理者しか削除できないのは「バックアップ」です。 添付ファイルは誰でも削除可能です。
こちらも繰り返しになりますが バックアップが残ると次にアップする際、同じ名前では添付出来ませんので それも含めて削除できるようにして頂きたいと思います。
ファイルの削除はこれまで通り誰でも行え、 バックアップの削除のみ 管理者に加えてアップロード者も行えるようにするという木主の案ならば 管理上の問題・不都合は生じないだろうと思われるので、 それが可能なら自分も賛成です。
ご賛同いただきありがとうございます。
また、あくまでもこちらの案としてですがドロップダウン方式にして 一般（ここは誰でもOK）、アップロード者、管理者と分けて パスワードを入力できるようにするのもありかと思います。（管理者のみ全てに対応）
ただし、パスワードシステムの導入と、 それを管理者だけに可視化できるようにする必要があろうかと思うので、 大規模なシステム改修が必要になる気がします。 なので、運営がそこまでやってくれるかは大いに疑問です。
現在のシステムに、少し手を加えると言う方法があればよいのですが こちらの方は、運営でないと分かりませんので、何とも言えないところです。
また、これらの内容で変わる良い方法があれば、それでも構わないのですが。
各自で添付したファイルを削除するのに 何故、管理者の判断になるのかが分かりません。
繰り返しになりますが、 管理者しか削除できないのは「バックアップ」です。 添付ファイルは誰でも削除可能です。
前提とすべきは、きちんと管理されているwikiです。 仰っている事情は、 そのwikiの特別な事情になってしまいます。
ファイルの削除はこれまで通り誰でも行え、 バックアップの削除のみ、管理者に加えてアップロード者も行えるようにするという木主の案ならば、 管理上の問題・不都合は生じないだろうと思われるので、 それが可能なら自分も賛成です。
ただし、新たなパスワードシステムの導入と、 それを管理者だけに可視化できるようにする必要があろうかと思うので、 大規模なシステム改修が必要になる気がします。 なので、運営がそこまでやってくれるかは大いに疑問です。 なぜなら、この案件は、
この何れかで対処できてしまう案件だからです。
追記： そういえば、バックアップの自動作成はアップロード時ではなく、 ファイルの削除時だった気がします。 そうなるとパスワードシステムは成立しない気もします。
そもそも、各自で添付したファイルを削除するのに 何故、管理者の判断になるのかが分かりません。 添付した各自の判断で問題ないと思います。
しかも、添付ファイルが簡単に削除できなければ 添付するのも躊躇してしまいます。
他の管理者様・利用者様のご意見もお伺いしたいです。
ご意見 ありがとうございます。
誰でも行えないのは「バックアップ」の削除
バックアップが残ると次にアップする際同じ名前では添付出来ませんので それも含めて削除できるようにして頂きたいです。
荒らしがイタズラでアップした画像が誰も消せなくなってしまうので
そのあたりは2段階になっていますので1段階目で誰でも削除できるようにして 2段階目（バックアップ）はアップロードの際にパスワードの設定で完全削除と言う形ではいかがでしょうか？ もちろん管理者はパスワードに関係なく削除できるようにすれば問題ないかと思いますが いかがでしょうか？
勘違いされているかも知れませんが、 添付画像の削除は誰でも行えます。 誰でも行えないのは「バックアップ」の削除で、 削除された画像のバックアップをどうするかは管理者の判断になります。
ページでも画像でも、バックアップが誰でも消せないのは、 ページや画像の削除が誰でも行えることの裏返しでもあります。 バックアップが残っていれば、 悪意を持った誰かに削除されても復旧できるからです。
アップロードの際にパスワードを設定するのは可能かも知れませんが、 そうすると荒らしがイタズラでアップした画像が誰も消せなくなってしまうので、 論外だろうと思います。
自動削除のONにしない限り自動的に削除されないというのはどうですか？
以下の可能性があるので自動で削除されては困ります。
改めて。<td style="display:none;"></td>このやり方は悪くない気がしてきました。htmlのルール的に問題がなければ。
<td style="display:none;"></td>
|A|1| |~|2| |B|3|
こう書いて|~|の部分を<td style="display:none;">A</td>と変換すれば、 fix-colの解決と同時に、結合を使ったtablesortが壊れる問題の解決の足掛かりにならないでしょうか。 tablesortをどう実現してるのかわかってないですが、ソートを掛けたときだけrowspanやdisplayの記述を無視あるいは削除してくれれば、ソートしても崩れないような気がします。
<td style="display:none;">A</td>
またすでにある書式の|~|の変換ルールを変えると影響が見えないので、新しい書式として例えば|^|みたいな書き方で上記変換に対応されれば互換性の問題が回避できないでしょうか。
検証できてませんが、tablescrollの高さ指定を数値(px)固定だけではなく、%とかautoとか使えるようになれば閲覧環境の違いは対処できそうな気がします。
ページ毎に表示高さを変えるほうは、tablescroll側が自在になればcssboxの高さ指定と連動してコントロールできるのか?あるいはoverflowというプロパティが使えればいいのか? overflowは現在使えませんが、試しに直接htmlに追記するとboxで指定した高さを内容がはみ出さすときはスクロールバーが出るようです。tablescrollの件とは関係なくoverflowは使い勝手があるかもしれません。
7) 先頭列が縦方向に結合した状態でfix-colを使うと|~|の隣の2列目が固定される問題
htmlの知識はないですが、中を覗いて見た感じ結合セル|~|の部分は記述が省略されるようで、 一方fix-colはhtmlの各行一番最初の要素を拾って固定するという動作のようで、 つまり|~|の隣に記述した|2列目|が先頭要素という扱いになってしまっているように見えます。 試しに|~|があるべき位置に<td style="display:none;"></td>とか不可視のダミーセルを記述して辻褄を合わせると、それが先頭列として拾われて期待通りに動作するようです。
ただこれを自動でやるにはtablescrollの機能ではなく、元々のテーブルの変換規則を変更する必要があるはずで、全体として成り立つのか考慮が必要でしょう。 他のtablesortも結合があると期待通りに動作しないのは従来からで、これらを利用するときは結合を避けるという運用となるか。
なお横結合|>|は左詰めになるようですが、今のところ問題は見えません。しかし同様に先頭から何番目みたいな指定があるときは同様の考慮が必要と思われます。
Wikiトップページで試したところ、ヘッダ行でなくても起こるようです。
#tablescroll{{
有用なプラグインの実装ありがとうございます。 画像はこちらのページで試した結果です。以下の赤枠を修正してほしいです。ヘッダ行が2列以上あるときに起こるようです。
#tablescroll(fix-col)
#tablescroll(screen-sticky){{
実装ありがとうございます。大型の表を閲覧しやすくなりました。
大変助かっているのですが、１つ問題点を確認しています。 先頭列のヘッダーが縦に結合していると、fix-colで先頭列以外のヘッダーセルが固定されてしまいます。
以下に一例を示します。
#tablescroll(,fix-col){{ |~先頭ヘッダー|>|~項目カテゴリー|~その他|h |~|~項目A|~項目B|~|h ||||500|c |~先頭|||| }}
この表を右にスクロールしていくと、『項目A』が『先頭ヘッダー』の上に重なってしまうのがわかると思います。
追記: このような場合でも、先頭列のみが固定されるようになるとありがたいです。
「画面上部にヘッダ貼り付け」で、横はみ出しが切れないようにしてほしいです。 何とかならないでしょうか？
ページ編集フォームごと表示されないようです
さらに。 行と列の追加、挿入、削除、コピペが出来るように。 特に列は従来エディタだと面倒だったところ。ミスをすると表が崩れて壊滅的になり、しかもどこを間違えたのか捜索が大変。巨大な表だとスプレッドシートを使うか正規表現置換を駆使する必要があるが、出来る人は限られる。
セル内改行を&brとするか↲キーで可能にするかはエディタの表示メニューで選択。
スプレッドシートから範囲コピペ可能に。
0ベースで検討できる贅沢な状況のようですが。 閲覧状態から対象箇所を直接指定で編集できるのは魅力的です。｜棒が沢山並んだ巨大な表のソースでは、どこを編集してるのかわからないので、大抵スプレッドシートに展開してから編集してます。 一方でそれをダブルクリックなどで手軽に編集可能になってしまうと、誤操作や意図せぬ書き換え、イタズラの敷居が下がります。 またもし一箇所ごとに変更が反映されるなら、その度に更新が入り負荷が高そうです。編集が競合したときどうなるのかも気になります。
見出し内編集のように特定のボタンを押すと表編集エディタが開くのが良いと思います。ボタンは表外の右上が良いと思います。目に付きにくい所がいいです。
エディタはスプレッドシートのように扱えると良いです。つまり縦横二次元の表のまま、コピペ、範囲指定、セルごとの書式など操作できるように。ショートカットやスマホで操作出来るようボタンメニューも。左側に入力エリア、c書式行や//コメント行を含めて。(UI的にコメント行が難しければなしで)。右側にプレビュー画面。
エディタは通常編集画面からも呼び出せると良い。
上記だけだとプラグインではなく、見出し内編集のように標準組み込みでも良いかもしれません。ただ完成した表をロックしたいとかあるかもしれないので、逆にプラグインで編集ロックできると良いかも。既にそんなプラグインがあったような。
私の場合zrecentはコメント更新確認の目的で使っているので、新規トピックや本文側の更新が反映されなくても不便は無いです。
zawazawaをwikiwikiのコンテンツのコメント機能のために使うのか、zawazawaの内容を方を主としてそちらの状況をwikiwikiで確認したいのかの違いだと思いますが、zrecentはpcommentの代替として前者の目的で登場したと思います。
機能拡張しても損はないとおもいますが。例えば本文をコメント0番として反映させるとか。
6) 状況に応じて縦スクロール幅制限を外したい 私も似たような問題ですが、以下の条件を同時に満たしたいです。
ページ構成
期待する動作
問題点
#tablescroll(高さ指定){{ #popout{ includex(表ページ) }} }}
どうなれば良いか tablescrollで高さ未指定時は最大とし、表示領域の高さ指定は別のプラグインで担当する。 時間がないので試せてないですが、cssboxの高さ指定でできるだろうか。
本文ページ #表示領域指定プラグイン(高さ){{ includex(表ページ) }} 表ページ #popout{{ #tablescroll(高さ最大){{ |表| }} }}
>画面上部にヘッダ貼り付け >横はみ出しは切れる。 なのですが、横はみ出しは切れないように（というより先頭列を固定した横スクロールと併用できるように）ならないでしょうか？
上2つだと、高さを指定しなければならず、スクロールバーを複数設定したくない・レイアウト的に表全体が見えてほしい、という場合に不便があります。
確認いたしました。期待していた挙動です。修正ありがとうございます。 より深いところ、プラグイン名やパラメータのパターンマッチのところに原因があったのですね。根源の調査と根本的な対策、その修正規模感に比してとても素早い対応をしていただき、ありがとうございました。
自分は最近使い始めたばかりですが、新着が表示されないことに今まで誰も不満が無いのであれば需要が無いということなのでしょうか？ 他に利用されている方のご意見も聞きたいです。
もし改善される見込みがある場合の仕様提案です ・現在の表記はタイトル全文が表示されて長すぎることがあるのである程度の文字数以降は省略する ・新着トピックにNewをつける
こんなイメージです
24時間以内に投稿 ・新たな編集可能テーブルプラグイン(table_edit2.inc... 2023-06-07 ・表の見出しを固定する機能 ・zrecentプラグインで表示されないトピックがある ・「recent」ページ名でフィルタをかけられるようにする... ・ ページ名変更と一括変換機能をサブパスワード保持者に... 2023-06-06 ・flexboxの境界線と背景色指定 ・コメントフォームでの画像展開時のリロード不具合 ・tooltipプラグインのterm引数に、他のインラインプラ... ・構文解析の不具合仕様について New
仕様が古く実装できなかったのですね、それは失礼いたしました
自分がよく編集しているWikiにはこのようなとてつもないサイズの表があるのですが、入力する量が多いため、入力フォームを作成できるようになればかなり楽になると思います また、この表は下にどんどん追加していくという追記のやり方よりは、対応するグループに応じて間に挿入していく追記がメインですので、
表のセルをダブルクリックするとセルが入力フォームになって直接入力できる
もしこのような実装に決定した場合、下の行を追加するような機能もあると嬉しいです
ただ、直近のアップデートでスプレッドシートからコピペで表を貼り付けできるようになったので スプレッドシートを運用するのであればプラグインが拡張することに魅力はあまり感じないのかなと思います。
複数人でスプレッドシートをメンテできるのと、Wiki側で表を調整できる人が1人いればいいので
ご意見ありがとうございます。
誰でもではないですね。
今回の提案はあくまでも、個々でアップした添付ファイルを
個々でバックアップも含めて削除できるようにしてほしいという事です。
管理者の方、又は他の方の添付ファイルなどは
自由に削除することは出来ませんので。
上に書いていますのでまとめます。
以上の事から提案をさせたいただきました。
ご意見をお待ちしています。
バックアップを削除できるようにするのは反対です。
言葉通り、データを差し戻すために使用するものなので、そういったデータを削除したいという考え方は変えるべきです。
管理の面から考えて誰でも消せる状態にあるほうがおかしいです。
添付されてるファイルは誰でも削除できますが、バックアップされたものは用途が変わります。
管理者がいないというのは、そのWikiの事情になるので言われても分かりませんが
サブパスワードで削除できれば、サブパスワード持ちを増やすなりすることで1人しか対応できないなどの問題は解決すると思います。
サブパスワードで削除できないのであれば、削除権限を与える要望などを運営に出してみるといいと思います。
管理者が不在というのはそのWikiの特別な事情なので別の問題ではないですか？
wiki内で立候補者を募って運営に引き継ぎの申請をするのがいいと思います。
それは、時にはアラシが無断転載をしてファンアートを添付しているのが見えるためにもあります。
そもそもwiki全体に渡る容量制限があるわけでもないので、
削除したページの添付画像も削除したいのはどうしてかという意図が見えません。
まずはそこを書いた方が良いかと思います。
ごめんなさい、急いで投稿した為、書き忘れたことがありますので
ここで補足させてください。
サイズ間違え、更に画質の不具合で添付した場合は
バックアップなどから差し戻す必要はありませんよね？
バックアップから差し戻す場合は、荒らしなどが悪意を持って
いたずらに削除したりした際に、差し戻す必要があるだけなので
個々で画像添付の場合はサイズ間違え、更に画質の不具合などは
添付した後でないと分からないこともありますので
その為、バックアップその物の意味がありません。
その為、個々の画像添付者の判断でもバックアップも含めて
削除できるようにして頂きたいです。
簡潔に言うと、上記の失敗してアップした画像などのバックアップは
必要なく、正しく添付されたバックアップが必要かと思います。
そうすることにより管理者の管理がしやすくなるメリットもあります。
>> 10
このようなことにはならず
test.jpg [詳細]
test.jpg (バックアップ No.1) [詳細]
test.jpg (バックアップ No.2) [詳細]
test.jpg (バックアップ No.3) [詳細]
test.jpg (バックアップ No.4) [詳細]
test.jpg (バックアップ No.5) [詳細]
簡素化することも可能となります。
ですから、前回ご賛同いただいた通り
こちらの内容で問題はないかと思いますがいかがでしょうか？
もしくは、こちらに変わる、それ以外の方法と言う事になります。
ご意見ありがとうございます
こちらも同感です。
>> 4
管理者がページをきちんと管理できていなかったり
連絡がつかない場合などは非常に不便です。
修正されたようです。
削除を依頼するにしろしないにしろ管理者不在では意味がありませんし。
再度の返信ありがとうございます。
下に書いている通りそのような失敗した物をバックアップから
差し戻す必要はありませんよね。
しかも、そのようなものを他の人に見られてしまうと
何か恥ずかしい気持ちにもなりますし
添付するのも躊躇してしまいますよね。
その為にアップロード者がバックアップも含めて
削除できるようにして頂きたいです。
そうすれば、もっと気軽に添付も出来るような気がします。
それは例えば、画像でしたらサイズ・画質等などです。
その通りです。
同じ事の繰り返しになりますが、そもそも、各自で添付したファイルを削除するのに
（バックアップも含む）何故、管理者の判断になるのかが理解できません。
上記にも書いていますが、ページ等の物事でしたら理解できますが
添付ファイルについてはアップロード者の個々の判断に任せて頂きたいです。
管理上の問題はないと思います。
こちらの提案はあくまでも添付ファイルの一切管理の物事なので。
それも考えとしてはあります、どれがどれか分からなくなるので。
整理するのが大変なので。
既に削除済みなので、上書きではないです。（普通に差し替えです）
バックアップから差し戻すことも可能です。
そもそも、アップロードに失敗するとはどういう意味でしょうか。
どうすれば成功で、そしてそれは誰が判断するのですか?
例えばあなたがアップした画像を私や他の誰かが失敗、もしくは不要と判断して削除したらどうでしょう?
誰でもページや添付ファイルを各自の判断や思惑で削除できるからこそ、
自動バックアップに意味があります。
失敗・成功? はアップロード者だけが判断できるというのがあなたの主張で、
だから自分がアップした画像のバックアップを削除させて欲しいという依頼なのでしょう。
管理上問題が生じない形で実現可能なら、私自身は賛成ですが、
失敗したなら差し替えれば済む話なのも事実です。
何度も差し替えるとバックアップが増えていきます。
（記事（ページ）も同様で、更新する毎にバックアップが増えていきます）
古いパックアップが残っているのが気持ち悪いというのは分かりますが、
そういう「仕様」なので、基本的には気にせずとも大丈夫です。
追記：
とりあえず、何度も失敗してしまった場合は、wikiの編集ノートに
「管理者さんへ。何度もアップし直してゴメンナサイ。気になるなら古いバックアップを削除してください」
とでも記しておけば良いでしょう。
>> 10
一度削除して削除した名前と同じにすると添付の上に上書きされるという解釈でよろしいでしょうか？
大変失礼いたしました。
こちらはが思っていたことは
管理者以外の方がホームページのバックアップの一括削除の事かと思っていました。
管理者の方が一つ一つ削除するのが大変なので一括で削除できるようにしてほしいと言うことでしたら
管理者なので問題はないかと思います。
そもそも、失敗してアップした添付をバックアップとして残す必要があるのでしょうか？
このあたりも疑問に思います。
↑勘違いしました。
ページ破壊があったときに復旧できるようにするため一括削除が難しいという意味でしたか。
でも現状、ページ自体のバックアップを管理者が一括削除することは可能ですし、添付ファイルのバックアップも管理者の判断で一括削除できてもいいと思います。
1段階目の削除をすると(バックアップがあると)ファイルの添付のページにファイル名に取り消し線が付いて表示されます。この状態であれば同じ名前で再添付できて現行版になります。
削除直後に[バックアップを含む一覧]でみると
のように表示され、再添付して詳細を見ると
のように表示されます。
勘違いさせてしまったようですが、要望した一括削除は管理者が行う添付したファイルのバックアップを一括削除できるようにしてほしいということで、ページ破壊を起こすものではありません。
削除・再添付を繰り返すと
のようにバックアップがたくさんできて現状ひとつひとつパスワード入力して削除しなければなりません。
管理者のパスワード入力を1回で済ませてほしいということです。
>> 7
試したことがないので分かりませんが
バックアップにはどのような形で、添付名で残るのでしょうか？
それは難しいかも知れません。
ページなどのバックアップ等一括削除などは
ページ破壊されてしまったときバックアップがないと
復旧することが出来なくなるので運営が認めないと思います。
こちらが思っていることは
あくまでも個々でアップした添付ファイルを個々でバックアップも含めた削除の事で
ページについては現状のまま管理者が管理を行えば良いと思っています。
1段階目の削除の後同じ名前で添付できますよ？
間違えて添付しても削除して添付しなおすことは可能なので、都度管理者にお願いする必要はないと思います。
ただ、バックアップの削除は管理者にお願いすることになります。
現在のバックアップの削除は一つ一つパスワード入力が必要なのでバックアップが多いと管理者が大変です。
管理者の負担軽減の為に同じページもしくは同じ名前のバックアップは選択削除や一括削除があればいいんですけど。
ご返信ありがとうございます。
こちらも繰り返しになりますが
バックアップが残ると次にアップする際、同じ名前では添付出来ませんので
それも含めて削除できるようにして頂きたいと思います。
ご賛同いただきありがとうございます。
現在2段階で削除できるようになっていますが
1段階目で従来通り、誰でも削除でき（バックアップは残ります）
2段階目でバックアップの削除のみ管理者に加えてアップロード者も行えるようにする。
また、あくまでもこちらの案としてですがドロップダウン方式にして
一般（ここは誰でもOK）、アップロード者、管理者と分けて
パスワードを入力できるようにするのもありかと思います。（管理者のみ全てに対応）
現在のシステムに、少し手を加えると言う方法があればよいのですが
こちらの方は、運営でないと分かりませんので、何とも言えないところです。
また、これらの内容で変わる良い方法があれば、それでも構わないのですが。
繰り返しになりますが、
管理者しか削除できないのは「バックアップ」です。
添付ファイルは誰でも削除可能です。
前提とすべきは、きちんと管理されているwikiです。
仰っている事情は、
そのwikiの特別な事情になってしまいます。
ファイルの削除はこれまで通り誰でも行え、
バックアップの削除のみ、管理者に加えてアップロード者も行えるようにするという木主の案ならば、
管理上の問題・不都合は生じないだろうと思われるので、
それが可能なら自分も賛成です。
ただし、新たなパスワードシステムの導入と、
それを管理者だけに可視化できるようにする必要があろうかと思うので、
大規模なシステム改修が必要になる気がします。
なので、運営がそこまでやってくれるかは大いに疑問です。
なぜなら、この案件は、
この何れかで対処できてしまう案件だからです。
追記：
そういえば、バックアップの自動作成はアップロード時ではなく、
ファイルの削除時だった気がします。
そうなるとパスワードシステムは成立しない気もします。
そもそも、各自で添付したファイルを削除するのに
何故、管理者の判断になるのかが分かりません。
添付した各自の判断で問題ないと思います。
管理者がページをきちんと管理できていなかったり
連絡がつかない場合などは非常に不便です。
しかも、添付ファイルが簡単に削除できなければ
添付するのも躊躇してしまいます。
他の管理者様・利用者様のご意見もお伺いしたいです。
ご意見 ありがとうございます。
バックアップが残ると次にアップする際同じ名前では添付出来ませんので
それも含めて削除できるようにして頂きたいです。
そのあたりは2段階になっていますので1段階目で誰でも削除できるようにして
2段階目（バックアップ）はアップロードの際にパスワードの設定で完全削除と言う形ではいかがでしょうか？
もちろん管理者はパスワードに関係なく削除できるようにすれば問題ないかと思いますが
いかがでしょうか？
勘違いされているかも知れませんが、
添付画像の削除は誰でも行えます。
誰でも行えないのは「バックアップ」の削除で、
削除された画像のバックアップをどうするかは管理者の判断になります。
ページでも画像でも、バックアップが誰でも消せないのは、
ページや画像の削除が誰でも行えることの裏返しでもあります。
バックアップが残っていれば、
悪意を持った誰かに削除されても復旧できるからです。
アップロードの際にパスワードを設定するのは可能かも知れませんが、
そうすると荒らしがイタズラでアップした画像が誰も消せなくなってしまうので、
論外だろうと思います。
自動削除のONにしない限り自動的に削除されないというのはどうですか？
以下の可能性があるので自動で削除されては困ります。
改めて。
<td style="display:none;"></td>このやり方は悪くない気がしてきました。htmlのルール的に問題がなければ。こう書いて|~|の部分を
<td style="display:none;">A</td>と変換すれば、fix-colの解決と同時に、結合を使ったtablesortが壊れる問題の解決の足掛かりにならないでしょうか。
tablesortをどう実現してるのかわかってないですが、ソートを掛けたときだけrowspanやdisplayの記述を無視あるいは削除してくれれば、ソートしても崩れないような気がします。
またすでにある書式の|~|の変換ルールを変えると影響が見えないので、新しい書式として例えば|^|みたいな書き方で上記変換に対応されれば互換性の問題が回避できないでしょうか。
検証できてませんが、tablescrollの高さ指定を数値(px)固定だけではなく、%とかautoとか使えるようになれば閲覧環境の違いは対処できそうな気がします。
ページ毎に表示高さを変えるほうは、tablescroll側が自在になればcssboxの高さ指定と連動してコントロールできるのか?あるいはoverflowというプロパティが使えればいいのか?
overflowは現在使えませんが、試しに直接htmlに追記するとboxで指定した高さを内容がはみ出さすときはスクロールバーが出るようです。tablescrollの件とは関係なくoverflowは使い勝手があるかもしれません。
7) 先頭列が縦方向に結合した状態でfix-colを使うと|~|の隣の2列目が固定される問題
htmlの知識はないですが、中を覗いて見た感じ結合セル|~|の部分は記述が省略されるようで、
一方fix-colはhtmlの各行一番最初の要素を拾って固定するという動作のようで、
つまり|~|の隣に記述した|2列目|が先頭要素という扱いになってしまっているように見えます。
試しに|~|があるべき位置に
<td style="display:none;"></td>とか不可視のダミーセルを記述して辻褄を合わせると、それが先頭列として拾われて期待通りに動作するようです。ただこれを自動でやるにはtablescrollの機能ではなく、元々のテーブルの変換規則を変更する必要があるはずで、全体として成り立つのか考慮が必要でしょう。
他のtablesortも結合があると期待通りに動作しないのは従来からで、これらを利用するときは結合を避けるという運用となるか。
なお横結合|>|は左詰めになるようですが、今のところ問題は見えません。しかし同様に先頭から何番目みたいな指定があるときは同様の考慮が必要と思われます。
Wikiトップページで試したところ、ヘッダ行でなくても起こるようです。
#tablescroll{{
有用なプラグインの実装ありがとうございます。
画像はこちらのページで試した結果です。以下の赤枠を修正してほしいです。ヘッダ行が2列以上あるときに起こるようです。
#tablescroll{{
#tablescroll(fix-col)
#tablescroll(screen-sticky){{
実装ありがとうございます。大型の表を閲覧しやすくなりました。
大変助かっているのですが、１つ問題点を確認しています。
先頭列のヘッダーが縦に結合していると、fix-colで先頭列以外のヘッダーセルが固定されてしまいます。
以下に一例を示します。
この表を右にスクロールしていくと、『項目A』が『先頭ヘッダー』の上に重なってしまうのがわかると思います。
追記: このような場合でも、先頭列のみが固定されるようになるとありがたいです。
「画面上部にヘッダ貼り付け」で、横はみ出しが切れないようにしてほしいです。
何とかならないでしょうか？
ページ編集フォームごと表示されないようです
さらに。
行と列の追加、挿入、削除、コピペが出来るように。
特に列は従来エディタだと面倒だったところ。ミスをすると表が崩れて壊滅的になり、しかもどこを間違えたのか捜索が大変。巨大な表だとスプレッドシートを使うか正規表現置換を駆使する必要があるが、出来る人は限られる。
セル内改行を&brとするか↲キーで可能にするかはエディタの表示メニューで選択。
スプレッドシートから範囲コピペ可能に。
0ベースで検討できる贅沢な状況のようですが。
閲覧状態から対象箇所を直接指定で編集できるのは魅力的です。｜棒が沢山並んだ巨大な表のソースでは、どこを編集してるのかわからないので、大抵スプレッドシートに展開してから編集してます。
一方でそれをダブルクリックなどで手軽に編集可能になってしまうと、誤操作や意図せぬ書き換え、イタズラの敷居が下がります。
またもし一箇所ごとに変更が反映されるなら、その度に更新が入り負荷が高そうです。編集が競合したときどうなるのかも気になります。
見出し内編集のように特定のボタンを押すと表編集エディタが開くのが良いと思います。ボタンは表外の右上が良いと思います。目に付きにくい所がいいです。
エディタはスプレッドシートのように扱えると良いです。つまり縦横二次元の表のまま、コピペ、範囲指定、セルごとの書式など操作できるように。ショートカットやスマホで操作出来るようボタンメニューも。左側に入力エリア、c書式行や//コメント行を含めて。(UI的にコメント行が難しければなしで)。右側にプレビュー画面。
エディタは通常編集画面からも呼び出せると良い。
上記だけだとプラグインではなく、見出し内編集のように標準組み込みでも良いかもしれません。ただ完成した表をロックしたいとかあるかもしれないので、逆にプラグインで編集ロックできると良いかも。既にそんなプラグインがあったような。
私の場合zrecentはコメント更新確認の目的で使っているので、新規トピックや本文側の更新が反映されなくても不便は無いです。
zawazawaをwikiwikiのコンテンツのコメント機能のために使うのか、zawazawaの内容を方を主としてそちらの状況をwikiwikiで確認したいのかの違いだと思いますが、zrecentはpcommentの代替として前者の目的で登場したと思います。
機能拡張しても損はないとおもいますが。例えば本文をコメント0番として反映させるとか。
6) 状況に応じて縦スクロール幅制限を外したい
私も似たような問題ですが、以下の条件を同時に満たしたいです。
ページ構成
ほぼ表だけが書かれてるページ。簡単な凡例や説明書きなどはある。
includexで複数ページがから呼び出される。
ページソースは文書を主として、表(複数)をincludexで呼び出す。
期待する動作
文章の中に表を組み込んでいるため、表示されるとき表が大きすぎると邪魔。ページ全体に対する表の表示領域を限定したい。
表ページへリンクとPopoutを組み込んで、必要なときは表だけに着目できるようにする。
表ページ及びPopoutは表を最大限活用するために使う。
このときはページバランスを気にする必要はないので画面幅を最大限利用したい。
ただし表が大きすぎると、やはりヘッダーが画面の外に逃げてしまう問題はあるので、tablescrollは使いたい。
閲覧者ごとに表示環境が違うため、高さは固定値ではなく表示環境ごとの最大としたい。
同様に横が収まるか分からないのでfix-colも使いたい。
問題点
screen-stickyは高さ最大相当になるが、fix-colと同時に使えない。
またfix-colを使わずとも横方向にはみ出し部分は表示できない。
以下の書き方だと、表ページ及びPopout時にtablescrollが機能しない。
あるいは内側にtablescrollを入れれば高さ制限が掛かってしまう。
どうなれば良いか
tablescrollで高さ未指定時は最大とし、表示領域の高さ指定は別のプラグインで担当する。
時間がないので試せてないですが、cssboxの高さ指定でできるだろうか。
>画面上部にヘッダ貼り付け
>横はみ出しは切れる。
なのですが、横はみ出しは切れないように（というより先頭列を固定した横スクロールと併用できるように）ならないでしょうか？
上2つだと、高さを指定しなければならず、スクロールバーを複数設定したくない・レイアウト的に表全体が見えてほしい、という場合に不便があります。
確認いたしました。期待していた挙動です。修正ありがとうございます。
より深いところ、プラグイン名やパラメータのパターンマッチのところに原因があったのですね。根源の調査と根本的な対策、その修正規模感に比してとても素早い対応をしていただき、ありがとうございました。
自分は最近使い始めたばかりですが、新着が表示されないことに今まで誰も不満が無いのであれば需要が無いということなのでしょうか？
他に利用されている方のご意見も聞きたいです。
もし改善される見込みがある場合の仕様提案です
・現在の表記はタイトル全文が表示されて長すぎることがあるのである程度の文字数以降は省略する
・新着トピックにNewをつける
こんなイメージです
仕様が古く実装できなかったのですね、それは失礼いたしました
自分がよく編集しているWikiにはこのようなとてつもないサイズの表があるのですが、入力する量が多いため、入力フォームを作成できるようになればかなり楽になると思います
また、この表は下にどんどん追加していくという追記のやり方よりは、対応するグループに応じて間に挿入していく追記がメインですので、
もしこのような実装に決定した場合、下の行を追加するような機能もあると嬉しいです
ただ、直近のアップデートでスプレッドシートからコピペで表を貼り付けできるようになったので
スプレッドシートを運用するのであればプラグインが拡張することに魅力はあまり感じないのかなと思います。
複数人でスプレッドシートをメンテできるのと、Wiki側で表を調整できる人が1人いればいいので