リクエスト広場

運営が荒らしに敏感なのは当然のことであり、
指摘は的外れなものに思えます。

管理ユーザーがwikiを放置しているようなら、
管理者権限を委譲してもらうという方法もあります。

サブパスワード所持者の主な役割は編集合戦や荒らし対応ですし、
そもそも管理ユーザーとサブパスワード所持者の権限に差が無ければ、
見ず知らずの他人のサブパスワード申請に応じる管理ユーザーはほとんどいなくなるのではないでしょうか。

ページ名変更に関しては過去にも要望があり（コチラ）、
木主の問い合わせに回答できないという運営の塩対応で理由は不明のままですが、
wikiの破壊を防ぐなど何らかの理由があると思われるので、諦めるしかなさそうです。

1年ほど前、独自にecacheの挙動に関して調べていた者です。
大前提としてincludeに限らず、他のページや情報を参照する(≒表示される内容が変化する)書式に対してecacheを使用した場合、意図しない挙動になる可能性があります。
例えば「reset=new」は、使用しているページの内容が更新(編集)されないとecacheの更新を行いません。
そのため「reset=new」の指定範囲内にincludeが含まれている場合、そのページを更新しない限りincludeの表示内容は更新されません。
また、ecacheの製作者さんがプラグインのページで答えていますが、「reset=秒数」は「更新する頻度」ではなく「更新の確認をする頻度」です。
強制リセットではなく、内容が更新されていた場合にのみecacheを更新するようです。

(1)
一部の書式はecacheを無視？するようです。
例えば「#twitter_timeline」の場合は「5分に1度更新または新しいツイートは即更新」といった挙動で固定されます。
そのためこれ以外でも独自の挙動をとり、ecacheのオプションが適用されない書式がある可能性があります。
以前その他も個別に調べようかと思いましたが、作業が大変なので断念しました。
これらが問題になる場合は、それ以外にのみecacheを適用するなどすれば問題を解決できるかもしれません。
→1つのページ内で複数のecacheを使用できます。

例:
 #ecache(reset=new){{
 内容
 }}
 #include
 #ecache(reset=new){{
 内容
 }}

AutoAliasNameを含む「リンク化⇔非リンク化」も更新されなくなるので、「reset=new」で問題が起こらないほうが稀かもしれません。
蛇足ですが製作者さんのページ「http://pukiwiki.sonots.com 」にアクセスできないのが気になります(一部インターネットアーカイブ有)。

現在も解決していないのですが、応急処置として折り畳みメニュー内にzawazawa掲示板を表示させることにしました。

[e]を押して編集してみましたがしっかり反映・表示されてるようにみえました

既に同一の方によってzawazawa側に投稿されていますので、こちらをご覧の方で同意する方や意見のある方はそちらへお願いします。
https://zawazawa.jp/zawazawa-request/topic/10

wikiwiki側は対応済みなのにzawazawaで使えないのは不便です

無料で使わせてもらっているので、そう強く要求できないのですがアップロードできるサイズを大きくしてもらって、
画像描写が粗くならないように自動圧縮して表示できればいいんですけどね。
WIKIWIKIの既存の画像自動変換だと変換後の画質がとても粗いです。
>> 11にあるGoogle製の変換サービスやgif画像 圧縮のようなサービスだと使い物になります。

過去、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に入れても外部リンクとして表示されるだけでした。
ホワイトリスト式で有効・無効のドメインを決定しているのかなと思うのですが。