脚注の文字色の修正を確認いたしました。
デザインテンプレートのsampleページを閲覧したところ、 モバイルだけでなくPCでもソースコードが表示され、 あらためてよく見ると、ページのソースコードではなく、 こちらの内容が表示されているようです。 これにどのような意味があるのか、知識がない自分にはさっぱりわかりませんが、 右上にCopyボタンがあることから、一先ず仕様と判断いたしました。
従ってトピックは解決済みとさせていただきます。
ご対応いただきありがとうございました！
(行頭#とかが有効なことに気づかず謎フォーマットになったけど気にしないでね🐱)
結論から言うと、提示してくれたページは現状のままで全く問題なしです！✨ 理由は、このページのPV(T.7, Y.11)なら、少しくらい負荷が高くてもサーバー全体への影響はほとんどないからです。 トップページ(T.4523, Y.11151)のレベルなら話は別ですが、このページなら今のままで大丈夫。💡
■ なぜ #lazy_fold でも本文コストが減らないの？ 右上の「本文コスト」は、サーバーが「wiki構文を読み込んでHTML表示用のデータを作る手間」を表しています。
サーバー側の「ページを組み立てる作業(コスト)」自体を減らす魔法ではないんです。 ■ 計測結果(参考) 全体: 11.1ms 本文コスト: 659.5ms この数値なら、メーターがオレンジ〜赤に見えても実際はスムーズに動いている範囲内(安全圏)ですよ。(※1) ■ 今後の対策 どうしても根本的にコストを下げたいなら「ページ分割」が必要になりますが、 現在の画像一覧(wiki共用のファイル置き場)という構成上、分割は少し難しそうですよね。
ってGemini(代筆)がいってた 【補足】 ・このページは3.に該当 (あとこのページは画像サイズ小さいので#lazy_なしでもいいかもね) ・#lazy_が機能していることは「読み込みリソース数」(画像数)が減ったことで確認できるよ ・部分的なコメントアウトをしていってコスト食いポイントを確認するのもいいね 【脚注】 (※1) アクセスめちゃ多いページの場合は対策取ろうね
こちら私が運営する別のwikiでも同様の問題が発生しております。有用な情報があればぜひお教えいただきたいです。
SteamのF12キーで撮影するスクリーンショットは画質の悪いjpegか画質はいいけどWIKIに適さない大きさのpngの他にAVIF形式が選択できるので、PCゲームのプレイヤー層としてはAVIF形式ができると非常に助かりますね。現状だと画質恒常のためにはpngで保存してからWebPに再圧縮しなければならない都合上手間も容量も食いますし
たしかに、外部のサイトにある画像をcssboxの背景に利用可能です。 ですが、使いる画像は外部である必要はなく、CDN上のURL（例としてサンプルWIKIの添付ファイルを使う場合：https://cdn.wikiwiki.jp/to/w/sample/FrontPage/::attach/bn_image2.gif ）を参照することでwikiwikiに添付した画像も利用可能です。 しかしながら、CDN上のURLを直接参照する手段は、正規の方法とは言えません。 やはり、何らかの変更が必要に思いますし、background-imageでURLの参照が禁止されても妥当という印象です。
指摘が事実であれば単純にコミュニティ疲弊要因ですので賛同します。 ただし、対応困難ということでbackground-image自体の禁止となってもそれはそれで賛同します。
新機能の実装ありがとうございます！ 添付時に画像を複数同時に選択してアップロードできるようにすることは可能でしょうか
同じ症状に悩まされていたので投稿させて頂きます 私自身もiPhone端末で編集することがあるので、ご対処して貰いたいです
新しいファイルマネージャの要望はこちらでよろしいのでしょうか？ 軽く使ってみましたが、添付する際に毎回スクロールが発生するので現行同様に上部に配置希望です。 添付ファイルドラッグの仕様も現行同様に新しいファイルをドラッグした場合は上書き出来るようにして欲しいです。間違ったファイルを選択した際にキャンセルを押す手間が増えているので
ファイル添付の画面右上に「新しいファイルマネージャを使う」というリンクを設置いたしました。
将来的にファイルの管理はこちらの画面に移行する予定です。 現在はページ単位の操作となりますが、WIKI全体のファイル操作につきましても、 今後別のアプローチにてアクセスできるよう準備を進めております。
なお、初見での操作状況を把握したいため、現時点では詳細な操作説明の記載は控えさせていただきます。
個人的にはemailでの認証が欲しいかな 6桁のコードを入力するやつ
ちなみに「やや改善」（ややのレベルじゃない）、「不具合」（不具合ではないが普通に不便）、 「要望」（運営に要望するようなことでは十分あります,自分も引っ掛かりまくってます）、です。
(￣￣￣￣￣@ |￣￣￣￣￣|゜人 |2026年| Ｙ |¨¨¨¨¨| ゜＋ ＋| 実 |人 | 家 | Ｙ 。 | 安 の | ＋ 。| 心 様 |∩ /フ | 感 な |||㎜ | ！ |=¨=
迅速なご対応ありがとうございました！ タグを「解決済」に変更しました。
下部に余白が生じる原因は、スタイルシートのimg.vertical-alignの設定がbaseline（デフォルト値）になっているためと思われます。 文章中に小さな画像をアイコンとして挿入した際に上へズレる原因にもなっているので、この設定をbottomなどに変えてほしいです。
二年前のトピックのようですが、私も困っていたので横から失礼します。
実際に試せばわかると思いますが、CENTER:MIDDLE:だろうがMIDDLE:CENTER:だろうが何を指定しても指定しなくても上に寄ります。 そもそも表内ではデフォルトでLEFT/MIDDLE指定になっており、あくまでc行でTOP等を指定したときに一部を例外的にMIDDLEにするための機能という認識です。
ではなぜこの問題が起きるのかという話ですが、添付した画像の下側に1割ほど謎の余白が追加されることが原因です。 背景が白以外の画像を貼り、ブラウザの範囲選択をして強調表示（こういうやつ）にすると余白があることがわかります。 表がこの余白を含めた大きさで画像を表示しているせいで、下が空く＝上に寄るというわけです。
というわけで、この謎の余白を追加しないようにできればこの問題は解決するはずです。 よろしくお願いします。
要望であるならば、なぜ・どのような場面で必要なのか記載するべきです。 察するに、下記トピックの作成者と同一人物ではないでしょうか。 https://z.wikiwiki.jp/wikiwiki-request/topic/482 ページ編集時のSMS認証についてのお話であるならば、既に上記トピックにて解決していますし、そうでないならより詳細に説明をするべきです。 強い言い方ですが、意味のない提案を繰り返されても迷惑になるだけです。
ここ（リクエスト広場）に投稿するトピックとして不適当に思えます。 また、タグが3つ付いていますが、 「やや改善」（意味不明）、「不具合」（不具合ではない）、 「要望」（運営に要望するようなことではない）、です。
日本語、理解できていますか？
追記：
元のトピックは、サガ用語辞典というWikiの新管理人募集だったのが、 タイトル&内容を書き換えられて意味不明なリプライになってしまいました。 下で副管理人(WoTBWiki)さんも仰っていますが、 ホントあなたは迷惑です。
いつの間にかできるようになってたし上にあげてたpcブラウザ版のものも解決してた
Google Chrome 143.0.7499.170 Microsoft Edge 144.0.3719.35 どちらも現象継続確認(どちらもごく稀に「検証に予想以上に時間がかかっています」のメッセージは出る)
他の認証方法 リクエスト広場 - zawazawa https://z.wikiwiki.jp/wikiwiki-request/topic/482
SMSが何の略か、何故電話番号が必要なのか一度考えた方がよいかと思います メールアドレスで認証できるようにするとしても、GoogleやYahooなどのメールアドレスは認証に使えないようにしなければ意味を成さないでしょう
oembedによる埋め込みですし、それはPixivやImgurに言ってくださいという話では……
もしかして生成AIで記事を作成・編集していたからですか？
そもそもSMS認証を設けている理由は、荒らし等の迷惑行為を抑止するためです。提案されている手法は、どれも本人確認を行う(一意性を確認する)ための手法でSMS認証の意図と異なります。
コメントのあと、確かに複数ファイルの添付ができた方が楽だと感じたのでREST APIを利用したツールを作りました。 解決策になるか分かりませんが、お役に立てば幸いです。 https://github.com/chansei/wikiwiki-attachment-tool
こちら実装を確認しました。アップロード後のリロード待機時間が無くなり快適です。 実装ありがとうございました。
直接的な解決策ではありませんが、REST APIを使うことで手間を減らすことは可能です。 (参考)https://z.wikiwiki.jp/wikiwiki-rest-api/topic/3 例えば指定ディレクトリ配下の画像に対して、自動で繰り返しアップロードをするといったスクリプトが考えられます。 ご参考になれば。
同時に10枚アップすれば、単純に同時処理負荷は10倍になり、 複数人でDoS攻撃を仕掛けるDDoS攻撃がそれだけやり易くなります。 wikiwiki.jpにアクセスし難い状況になれば、 利用者全員が迷惑を被るということに思い至りませんか？ それとも自分が楽できれば他のことは知らんがなということでしょうか。
枚数や容量で制限したところで、悪意ある人物が簡単にサーバーをいじめること(DoS攻撃)がやりやすくなってしまうことは大して変わりませんよ…… そうでなくとも、グロ画像のような不快な画像を大量に添付するイタズラは随分やりやすくなりそうです
私も複数枚まとめてアップデートできるようになると助かります。 一括添付は画像10枚まで、または合計○○KBまで、などの制限付きでも良いので、いくらか編集作業の負担が減るととても嬉しいです。
おそらく同様の現象を今年の3月あたりから確認しています。 https://z.wikiwiki.jp/wikiwiki-request/topic/386 こちらも未だに継続しており困っています…。
必死ですね。
無理な要望だと思います。 （何故1枚ずつしかアップできない仕様なのか考えたことありますか？）
貴方のリクエストは、 （貴方にその自覚がなくても）DoS攻撃させろと言っているのと同義です。
しばらく、元の仕様、一枚ずつアップロードのままやっています。「アップロード時にページをリロードしない」機能で少し便利になりましたが、やはり一度にたくさんの画像を添付したいです。どうにかできないでしょうか？
https://z.wikiwiki.jp/wikiwiki-request/topic/427/16
私のほうでも確認できました ご対応いただきありがとうございました！
恐らく今日？「アップロード後にページをリロードしない(チェックマーク)」の機能が添付ページ追加されたようです。 「1回開くための負荷」と「添付ページに更新を反映させるために再読み込みする負荷(添付自体は行われているため必須ではない)」以外は高負荷にならなくなったため、非常に助かりました。 暫定的な対応か分かりませんが、対応ありがとうございました。
https://wikiwiki.jp/p/information/view?id=10
・WikiWiki全体に季節性の荒らし行為が多発している。 ・管理人以外のユーザーには規制が必要。 ・生成AIが多い。 ・他のWikiから引用している。 ・永久にSMS認証を続けてほしい。 ・その他
脚注の文字色の修正を確認いたしました。
デザインテンプレートのsampleページを閲覧したところ、
モバイルだけでなくPCでもソースコードが表示され、
あらためてよく見ると、ページのソースコードではなく、
こちらの内容が表示されているようです。
これにどのような意味があるのか、知識がない自分にはさっぱりわかりませんが、
右上にCopyボタンがあることから、一先ず仕様と判断いたしました。
従ってトピックは解決済みとさせていただきます。
ご対応いただきありがとうございました！
(行頭#とかが有効なことに気づかず謎フォーマットになったけど気にしないでね🐱)
結論から言うと、提示してくれたページは現状のままで全く問題なしです！✨
理由は、このページのPV(T.7, Y.11)なら、少しくらい負荷が高くてもサーバー全体への影響はほとんどないからです。
トップページ(T.4523, Y.11151)のレベルなら話は別ですが、このページなら今のままで大丈夫。💡
■ なぜ #lazy_fold でも本文コストが減らないの？
右上の「本文コスト」は、サーバーが「wiki構文を読み込んでHTML表示用のデータを作る手間」を表しています。
lazy_foldは「ブラウザが画像を表示するタイミング」を遅らせてデータ転送量を減らすためのもので、
サーバー側の「ページを組み立てる作業(コスト)」自体を減らす魔法ではないんです。
■ 計測結果(参考) 全体: 11.1ms 本文コスト: 659.5ms
この数値なら、メーターがオレンジ〜赤に見えても実際はスムーズに動いている範囲内(安全圏)ですよ。(※1)
■ 今後の対策
どうしても根本的にコストを下げたいなら「ページ分割」が必要になりますが、
現在の画像一覧(wiki共用のファイル置き場)という構成上、分割は少し難しそうですよね。
現状維持でOKです！サーバーの負荷軽減に協力しようというそのお気持ちだけで100点満点です！💖
ってGemini(代筆)がいってた
【補足】
・このページは3.に該当 (あとこのページは画像サイズ小さいので#lazy_なしでもいいかもね)
・#lazy_が機能していることは「読み込みリソース数」(画像数)が減ったことで確認できるよ
・部分的なコメントアウトをしていってコスト食いポイントを確認するのもいいね
【脚注】
(※1) アクセスめちゃ多いページの場合は対策取ろうね
こちら私が運営する別のwikiでも同様の問題が発生しております。有用な情報があればぜひお教えいただきたいです。
SteamのF12キーで撮影するスクリーンショットは画質の悪いjpegか画質はいいけどWIKIに適さない大きさのpngの他にAVIF形式が選択できるので、PCゲームのプレイヤー層としてはAVIF形式ができると非常に助かりますね。現状だと画質恒常のためにはpngで保存してからWebPに再圧縮しなければならない都合上手間も容量も食いますし
たしかに、外部のサイトにある画像をcssboxの背景に利用可能です。
ですが、使いる画像は外部である必要はなく、CDN上のURL（例としてサンプルWIKIの添付ファイルを使う場合：https://cdn.wikiwiki.jp/to/w/sample/FrontPage/::attach/bn_image2.gif ）を参照することでwikiwikiに添付した画像も利用可能です。
しかしながら、CDN上のURLを直接参照する手段は、正規の方法とは言えません。
やはり、何らかの変更が必要に思いますし、background-imageでURLの参照が禁止されても妥当という印象です。
指摘が事実であれば単純にコミュニティ疲弊要因ですので賛同します。
ただし、対応困難ということでbackground-image自体の禁止となってもそれはそれで賛同します。
新機能の実装ありがとうございます！
添付時に画像を複数同時に選択してアップロードできるようにすることは可能でしょうか
同じ症状に悩まされていたので投稿させて頂きます
私自身もiPhone端末で編集することがあるので、ご対処して貰いたいです
新しいファイルマネージャの要望はこちらでよろしいのでしょうか？
軽く使ってみましたが、添付する際に毎回スクロールが発生するので現行同様に上部に配置希望です。
添付ファイルドラッグの仕様も現行同様に新しいファイルをドラッグした場合は上書き出来るようにして欲しいです。間違ったファイルを選択した際にキャンセルを押す手間が増えているので
ファイル添付の画面右上に「新しいファイルマネージャを使う」というリンクを設置いたしました。
将来的にファイルの管理はこちらの画面に移行する予定です。
現在はページ単位の操作となりますが、WIKI全体のファイル操作につきましても、
今後別のアプローチにてアクセスできるよう準備を進めております。
なお、初見での操作状況を把握したいため、現時点では詳細な操作説明の記載は控えさせていただきます。
個人的にはemailでの認証が欲しいかな
6桁のコードを入力するやつ
ちなみに「やや改善」（ややのレベルじゃない）、「不具合」（不具合ではないが普通に不便）、
「要望」（運営に要望するようなことでは十分あります,自分も引っ掛かりまくってます）、です。
(￣￣￣￣￣@
|￣￣￣￣￣|゜人
|2026年| Ｙ
|¨¨¨¨¨| ゜＋
＋| 実 |人
| 家 | Ｙ 。
| 安 の | ＋
。| 心 様 |∩ /フ
| 感 な |||㎜
| ！ |=¨=
(＿＿＿＿＿@ U―U
¨¨¨¨¨¨¨¨¨
(￣￣￣￣￣@
|￣￣￣￣￣|゜人
|2026年| Ｙ
|¨¨¨¨¨| ゜＋
＋| 実 |人
| 家 | Ｙ 。
| 安 の | ＋
。| 心 様 |∩ /フ
| 感 な |||㎜
| ！ |=¨=
(＿＿＿＿＿@ U―U
¨¨¨¨¨¨¨¨¨
迅速なご対応ありがとうございました！
タグを「解決済」に変更しました。
下部に余白が生じる原因は、スタイルシートのimg.vertical-alignの設定がbaseline（デフォルト値）になっているためと思われます。
文章中に小さな画像をアイコンとして挿入した際に上へズレる原因にもなっているので、この設定をbottomなどに変えてほしいです。
二年前のトピックのようですが、私も困っていたので横から失礼します。
実際に試せばわかると思いますが、CENTER:MIDDLE:だろうがMIDDLE:CENTER:だろうが何を指定しても指定しなくても上に寄ります。
そもそも表内ではデフォルトでLEFT/MIDDLE指定になっており、あくまでc行でTOP等を指定したときに一部を例外的にMIDDLEにするための機能という認識です。
ではなぜこの問題が起きるのかという話ですが、添付した画像の下側に1割ほど謎の余白が追加されることが原因です。
背景が白以外の画像を貼り、ブラウザの範囲選択をして強調表示（こういうやつ）にすると余白があることがわかります。
表がこの余白を含めた大きさで画像を表示しているせいで、下が空く＝上に寄るというわけです。
というわけで、この謎の余白を追加しないようにできればこの問題は解決するはずです。
よろしくお願いします。
要望であるならば、なぜ・どのような場面で必要なのか記載するべきです。
察するに、下記トピックの作成者と同一人物ではないでしょうか。
https://z.wikiwiki.jp/wikiwiki-request/topic/482
ページ編集時のSMS認証についてのお話であるならば、既に上記トピックにて解決していますし、そうでないならより詳細に説明をするべきです。
強い言い方ですが、意味のない提案を繰り返されても迷惑になるだけです。
ここ（リクエスト広場）に投稿するトピックとして不適当に思えます。
また、タグが3つ付いていますが、
「やや改善」（意味不明）、「不具合」（不具合ではない）、
「要望」（運営に要望するようなことではない）、です。
日本語、理解できていますか？
追記：
元のトピックは、サガ用語辞典というWikiの新管理人募集だったのが、
タイトル&内容を書き換えられて意味不明なリプライになってしまいました。
下で副管理人(WoTBWiki)さんも仰っていますが、
ホントあなたは迷惑です。
いつの間にかできるようになってたし上にあげてたpcブラウザ版のものも解決してた
Google Chrome 143.0.7499.170
Microsoft Edge 144.0.3719.35
どちらも現象継続確認(どちらもごく稀に「検証に予想以上に時間がかかっています」のメッセージは出る)
他の認証方法 リクエスト広場 - zawazawa https://z.wikiwiki.jp/wikiwiki-request/topic/482
SMSが何の略か、何故電話番号が必要なのか一度考えた方がよいかと思います
メールアドレスで認証できるようにするとしても、GoogleやYahooなどのメールアドレスは認証に使えないようにしなければ意味を成さないでしょう
oembedによる埋め込みですし、それはPixivやImgurに言ってくださいという話では……
もしかして生成AIで記事を作成・編集していたからですか？
そもそもSMS認証を設けている理由は、荒らし等の迷惑行為を抑止するためです。提案されている手法は、どれも本人確認を行う(一意性を確認する)ための手法でSMS認証の意図と異なります。
コメントのあと、確かに複数ファイルの添付ができた方が楽だと感じたのでREST APIを利用したツールを作りました。
解決策になるか分かりませんが、お役に立てば幸いです。
https://github.com/chansei/wikiwiki-attachment-tool
こちら実装を確認しました。アップロード後のリロード待機時間が無くなり快適です。
実装ありがとうございました。
直接的な解決策ではありませんが、REST APIを使うことで手間を減らすことは可能です。
(参考)https://z.wikiwiki.jp/wikiwiki-rest-api/topic/3
例えば指定ディレクトリ配下の画像に対して、自動で繰り返しアップロードをするといったスクリプトが考えられます。
ご参考になれば。
同時に10枚アップすれば、単純に同時処理負荷は10倍になり、
複数人でDoS攻撃を仕掛けるDDoS攻撃がそれだけやり易くなります。
wikiwiki.jpにアクセスし難い状況になれば、
利用者全員が迷惑を被るということに思い至りませんか？
それとも自分が楽できれば他のことは知らんがなということでしょうか。
枚数や容量で制限したところで、悪意ある人物が簡単にサーバーをいじめること(DoS攻撃)がやりやすくなってしまうことは大して変わりませんよ……
そうでなくとも、グロ画像のような不快な画像を大量に添付するイタズラは随分やりやすくなりそうです
私も複数枚まとめてアップデートできるようになると助かります。
一括添付は画像10枚まで、または合計○○KBまで、などの制限付きでも良いので、いくらか編集作業の負担が減るととても嬉しいです。
おそらく同様の現象を今年の3月あたりから確認しています。
https://z.wikiwiki.jp/wikiwiki-request/topic/386
こちらも未だに継続しており困っています…。
必死ですね。
無理な要望だと思います。
（何故1枚ずつしかアップできない仕様なのか考えたことありますか？）
貴方のリクエストは、
（貴方にその自覚がなくても）DoS攻撃させろと言っているのと同義です。
しばらく、元の仕様、一枚ずつアップロードのままやっています。「アップロード時にページをリロードしない」機能で少し便利になりましたが、やはり一度にたくさんの画像を添付したいです。どうにかできないでしょうか？
https://z.wikiwiki.jp/wikiwiki-request/topic/427/16
私のほうでも確認できました
ご対応いただきありがとうございました！
恐らく今日？「アップロード後にページをリロードしない(チェックマーク)」の機能が添付ページ追加されたようです。
「1回開くための負荷」と「添付ページに更新を反映させるために再読み込みする負荷(添付自体は行われているため必須ではない)」以外は高負荷にならなくなったため、非常に助かりました。
暫定的な対応か分かりませんが、対応ありがとうございました。
https://wikiwiki.jp/p/information/view?id=10
・WikiWiki全体に季節性の荒らし行為が多発している。
・管理人以外のユーザーには規制が必要。
・生成AIが多い。
・他のWikiから引用している。
・永久にSMS認証を続けてほしい。
・その他