リクエスト広場

過去、WIKIWIKI運営チームが特定のwikiに
「FrontPageに設置している462KBの画像について、2週間の転送量が69.01GBもあるためどうにかして欲しい」
と要請していたのですね。
https://zawazawa.jp/spla3/topic/123/189

要請に有志が応じた結果も運営チームが公表しています。
5.42GB/24時間が1.27GB/24時間になり感謝しているとのことでした。
https://zawazawa.jp/spla3/topic/123/222

ということはFrontPageなど、確実にアクセスの多いページで上限を引き上げるのは危険であるとは言えますね...
1MBでも単純に約140GB/2週間の転送量となります。

zawazawaのアップロードできる最大画像サイズが20MBなので、利便性向上のために引き上げてほしいですね。

WIKIWIKIにて実装されている添付プラグインは「画像」のためだけに存在すると理解しております。
でなければ512KBをオーバーした際に、画像の自動変換処理を動かすよう実装する必要がないためです。
もしzipファイルをアップロードして、それがダウンロードできたとしてもたまたまである認識です。

では512KBが妥当かと言われると指摘されている通り少ないものです。
画像の自動変換は万能ではなく、変換された結果粗いものになってしまうこともあります。
せめて無変換の範囲として1MBは必要であると思います。

さらに新・カイロパーク攻略 Wiki 掲示板にある雑談(当Wikiにアクセスして確認しました。

コメントアウトしても位置ずれ発生のまま

#ecache
#flex_container
#flex_box
#contentsx
#includex

コメントアウトして位置ずれ改善

#zrecent
#zcomment

zrecentとzcommentはそれぞれ個別にコメントアウトしても位置ずれが発生しました。同時に2つコメントアウトしてようやく、位置ずれが改善されました。

zcommentの高さと件数を指定していたので、指定なしに変更してみましたが改善されませんでした。

返信ありがとうございます。
Chromeは2019年、Safariは2022年に対応している模様です。
助言どおりに各プラグインをコメントアウトした結果は以下になります。

コメントアウトしても位置ずれ発生のまま

#ecache
#flex_container
#flex_box
#twitter_timeline

コメントアウトして位置ずれ改善

#zcomment

zcommentに原因があるようです。元々あるトピック内(https://zawazawa.jp/kairoparknew/topic/187)にサムネイル画像があったため、問題の切り分け確認でサムネイル画像がない別のトピック(https://zawazawa.jp/kairoparknew/topic/133)を貼り付けて確認したところ、変わらず位置ずれが発生して改善されませんでした。

androidから見ましたがずれません。ページを読み込んでジャンプした後に、高さのあるコンテンツが後から展開されて位置がずれるのかもしれません。
そこよりより上にあるZコメントやTwitter、ecashを切ってどうなるなか原因を絞り込んでみてください。
類似の話題

すみませんでした。新しくトピックを立てることにします。

……MBの間違いですよね？
2GBの画像なんてものはそもそも現実的ではなく、8K画像の24bitBMPでさえ100MB弱です。
そこまで上限大きいとファイル偽装の違法ファイル取引の温床になりかねないので、
ceptさんがおっしゃるように3MB、多くて5MBぐらいが理想かなぁ

同意です。
不適切な文字列や、文字数制限を超える文章荒らしに対応できないのは少し痛いところです。「#zcomment」では禁止ワード機能が使用できるのに、ZAWAZAWA外のコメントプラグインやコメントの関係ないwikiページでの不適切な文字列の編集に柔軟に対応できないのは困るところがあります。

2GBの画像が添付されることはおそらく一般的でなく、ページ閲覧者のデータ使用量を不意打ち気味に奪いかねないといった懸念もあるのでちょっと上限としてどうかなと思いますね…その手のサイズはすでに仰っているように外部アップローダーを利用するのが適当かと思います。

ただ、現状の512KBはpng、gif等のアップロードに困るサイズだと日常的に感じています。
ざっくり他のサービスを調べたところ、wicurioが19.5MB、atwikiが1MB、seesaaが5MB、Wikihouseが16MB上限のようです。この数字を考えるとやはり512KBというのは小さく、せめて3MB程度はほしいなあと…

一つの単語ごとに一個戻るようになった。すまほでの編集が困難になってるから早急になんとかしてほしい

そうですか。それなら2GBの方が良いですね。

以前、運営さんから解決済みトピックに対する追加の問い合わせは新たにトピックを立ててくださいとメールにて、回答を頂いています。そのため、新たにトピックを立てることをおすすめします。

解決済みになって終わってる話かもしれませんが横から失礼します。

機能的には満足しているんですが、いつのころからかtablesortの動作が非常に遅くなってしまったと感じています。
うちのWikiでの使い方がtablesortの中にtrackerの出力を入れて数千行をソートする特殊な状況なので他のWikiでは問題にならないのかもしれませんが、以前は遅くても数秒だったのが10秒以上かかるようになったので感覚としては５倍ほど遅くなったかなと。
うちのWiki⇒https://wikiwiki.jp/psssale/-s/53f602c4

このトピックができた頃は気にならなかったと思うのでそれ以降じゃないかと思います(うろ覚え)
何かしら処理上の問題が無いか今一度調べていただけたらと思います。

なるほど、でもそこまで頻繁なケースでもないなら外部のアップローダーでもいい気がします。ただ今の容量は少ないとは思います

「二次創作 Wiki*」に2GBもする画像もしくは100GBもする二次創作作品(ゲームなど)を配布したい人もいます。

ちょっと気になったんですけど100GBも何に使うんですか？個人的には2GBもありゃ大体のことは足りるとは思ってます

WikiWikiにも大容量ファイルを添付したい人がいます。
それを避けるためにアップロード可能最大ファイルサイズを512KBから2GBもしくは100GBまで増加してほしいのです。

ひょっとしたらと思ってchromeでもやってみると案の定なった。誰かならないブラウザ教えてくだしぃ…できるのなら修正してほしい

edgeでもなるようになった。なにか変えた覚えもないし理由がわからなぃ…最近アプデがあったみたいだけどそれだろうか

ご対応ありがとうございます。

&br;を使用せずとも自動で改行が行われるようになったことを確認しました。ご対応いただきありがとうございます。😭🙏

現時点でPC、モバイル共にどちらの閲覧時でも01vさんの要望通りに修正されたことを確認しました。

トピック説明のところに「⚠この掲示板は運営に直接質問や要望を伝えるところではありません……基本的にはディスカッションに参加しません。」とあるので、元来そういう用途のトピックではないと思います。
ただ挙げていただいたようなデメリットは実際に存在するので、運営が確認しているならば早期の修正かサンプルwikiなどでの告知をお願いしたいですね。

せっかくご回答をいただいたのに、なかなか確認の時間が取れず、再度返信が遅くなりすみません。
brの改行での対処が可能なことは存じ上げませんでした。ありがとうございます。　
しかし、手動での改行はやや不便なところがあるので、できれば機能の改善が欲しいところだと個人的には思います。
ともあれ、一旦は解決することができたので助かりました。Yuuさんご教示ありがとうございました。

明らかな不具合なのに、運営が沈黙を続けているのが一番の問題ですね。

• プラグインの仕様（もしくは不具合）だが修正は可能
• プラグインの仕様で修正は不可能

前者なら修正待ち、後者ならbrで対処するということになりますが、
brで対処後に不具合修正された場合、再編集する手間が発生するため、
何も反応がないと、どうするのがベターか分からない状況が続きます。

掲示板を設けている以上、運営は無責任に放置せず、

• 「現在対応中（あるいは今後対応予定）なのでお待ちください」
• 「対応予定はない（あるいは修正不可能な）のでbrで対処してください」

一先ずどちらかのコメントを出すべきでしょう。

「&br;」を入れると注釈内でも改行されると思います。
想定と違うなら教えてください。

https://wikiwiki.jp/pokopoko/砂場a
返信遅くなりすみません。こんな感じです。

親切にも解説ありがとうございました
管理人に記述を依頼することにします

以下のようにできると思います。今PC無いので正確に確認できませんが。

InterWikiNameのページに以下のように定義して。

-[./?cmd=edit&page= 部分編集] raw

リンクを以下のように記述。

[[部分編集:ページ&id=アンカー]]

回答ありがとうございます

またInterwikiを使えばもう少し簡略に記述できます。

こちらについて、[[編集:(ページ名)#(見出しID)]]のようにすれば良いのかと思いましたがそうではなく、他の解説を探してみましたが答えが見つからなかったため、詳しい解説をいただけるとありがたいです

同じくoEmbed対応のサービスであるらしいjsFiddleを有効にしてほしいなというお願いです。
ゲーム系のwikiで、計算を行うコードをjsFiddleで書いて共有したいなと思ったのですが、#embedに入れても外部リンクとして表示されるだけでした。
ホワイトリスト式で有効・無効のドメインを決定しているのかなと思うのですが。

例に挙げられたページを見ましたが、その使い方なら見出し内編集で同じことができます。

見出し内編集は見出しの横の鉛筆マークから行います。
見出し毎編集機能

includeで呼び出したページで対象の見出し内を編集のリンクを作るなら以下のように書きます。

[[見出し編集>https://wikiwiki.jp/splatoon3mix/?cmd=edit&page=サーモンラン%2F特殊な状況%2Fラッシュ&id=v5d06fff]]

これも鉛筆のリンクからわかります。id=文字列はソースの見出しの各アンカーを任意に書き換えられます。
またInterwikiを使えばもう少し簡略に記述できます。

includexで抽出してaeraeditの数が減った場合、編集対象がずれるのは仕方がないと思います。
ページ内順位2番のエリアがincludexにより抽出され1番目に位置するようになればリンクは1番として生成されて、実体のある元ページの2番にはたどり着かないような状況でしょう。aeraeditはソースに固有idみたいな記述をしないので順番でしか見分けができないでしょう。

なんとしてもareaeditでやるなら、includexで呼び出したページに以下のようにリンクを作れば対象エリアを編集できます。

[[エリア編集>https://wikiwiki.jp/splatoon3mix/?cmd=areaedit&areaedit_no=2&inline_plugin=0&page=サーモンラン%2F特殊な状況%2Fラッシュ]]

areaedit_no=番号に対象のareaを指定します。対象のaeaeditの編集リンクのURLを確認すれば上記と同様のものがわかります。
/は%2Fに置き換えます。
エンコードされた読めない文字列を気にしないのであれば単純にリンクのURLをコピペでもよいです。

includexで呼び出したとき間違ったareaeditのリンクを消すには以下のようにします。

#includex(サーモンラン/特殊な状況/ラッシュ,titlestr=off,section=(filter=ムニ・エール海洋発電所),firsthead=off,except=#areaedit)

解決しました。
書式指定を使ってもできないと思ったんですが、列の数が相違してただけでした。

該当のWikiのページをみてみたいです。

返信ありがとうございます。
1番目の「ユニーク文字列とカッコ数を制御してexceptする方法」で試してみます。

現状のwikiwikiで使えない「行末コメント」のマルチラインは自分も試したんですが、最初にも書いてある通り書いても消されちゃうんですよね…残念です
表もそうですね、&null埋め込んで制御しようとこともありましたが、仰る通りごちゃごちゃし過ぎて…
ベースになってるpukiwikiがそういうのを許してないのかな

行末コメントを可能にする(今はできない)
上記の方法は色々面倒だったり、カッコの数で制御するのは分かりにくいのと書いた当人以外には何を意図してるのか理解できないでしょう。誰かがマルチライン記述を増減させてカッコの数が自動で変わったら破綻します。
新しい機能として行末に非表示コメントを入れられるようになれば、もっと直接特定の行を指定できるのでよいです。過去に何回か要望してますが。

• マルチライン

  #マルチライン{{//コメント
  文章
  }}//コメント
  

  特定のマルチラインプラグインをincludexで外したいケースに使える。(今回のケース)
  また1ページに閉じカッコが沢山あるとどの開きカッコに対応してるかわかりにくいので、開きカッコと閉じカッコにペアでコメントをつけられると良いです。

• 表

  |1|2|
  |3|4|//コメント
  |5|6|
  

  表の外側にコメントを入れられると行を分類したり検索したりincludexするのが楽です。表の中に不可視のプラグインでコメントを埋め込むこともできますが、スプレッドシートでの管理の観点からデータ列に余計な情報をいれてゴチャゴチャさせたくないです。

• ブロック型

  #プラグイン()//コメント
  

  includeで特定の行を指定したときはこの書き方ができると良いです。(オプションに落書きできないこともあるので)
  通常のコメントであれば次の行に説明書きでもいいのですが。

• 文章

  表示しない//コメント
  

  これをやると既存記述で//が入ってる文章に影響がありそうなので上手くないかもしれません。URLとか。
  &null(コメント);で運用するのがいいかも。

別ページで見出しで制御する方法
ページ1

*A
表示しない
*B
表示する

ページ2

#flex_container(flex-start){{{
#flex_box{{
#includex(ページ1,section=(filter=A))
}}
#flex_box{{
#includex(ページ1,section=(filter=B))
}}
}}}

ページ3

#flex_container(flex-start){{{
#flex_box{{
#includex(ページ1,section=(filter=B))
}}
}}}