詳しく検証してみました。
応答不能になる条件 同じページに後半(末尾)が異なる文字列がある 文字列にアルファベットが多い場合(数字のみでは起こらない)
ページの例
HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0 (全41文字) HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA1 (全41文字)
HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0 (全41文字)
HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA1 (全41文字)
Chromeで「これらのキーワードがハイライトされています」が表示されるまでの時間は ”FFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(31文字)の場合6秒 ”GFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(32文字)の場合13秒 ”GGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(33文字)の場合32秒 ”GGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(34文字)の場合1分39秒 ”GGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(35文字)の場合2分15秒 と1文字増えるごとにかなり時間が伸びました。 (途中で「ページが応答しません」となっても放置した場合)
なお、どちらの行にも共通する ”HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA”(40文字)の場合は瞬時に表示されます。
運営の方に質問があるのですが、ディスコードなど外部に添付した画像をWikiに表示させたページがたくさん閲覧された場合は負担をかけることになるのでしょうか？ なるべく高画質なものを添付したい考えがありますので、Wikiのサイズ制限を回避するような形をとっておりました。
もし負担になるようでしたら、半年ごとで1日あたり10000~30000閲覧くらいあるページがいくつかあるので今まで結構な負担をかけてしまってたかなと懸念しております。 もし回避できる方法があればご教示いただければ対応いたします。
ご返信ありがとうございます。 再現性のある現象のようで安心しました。修正を期待しております。
ご回答ありがとうございます。参考にさせていただきます。
ダメもとでsvg(309KB)を試してみたところ、最適化されないことが分かりました。
申し訳ございません。 写真のような解像度のSVGは非推奨とさせていただきます。
ということですが、具体的にはどの解像度でどのくらいのサイズが理想なのでしょうか？ 今後も同じように画像を圧縮してほしくない際の参考にもなると思うので、共有いただければ幸いです。
パスする基準について、参考にしてください。 インライン表示の解像度とそのリミットサイズです。
32x32 6.87KB 50x50 8.35KB 200x200 25.29KB 400x400 54.97KB 500x500 71.79KB 800x600 107.06KB 800x800 128.00KB
sharp_yuv オプションは検討いたします。
色の劣化に限っては、非可逆圧縮時に-sharp_yuvオプション（より正確にRGBからYUVへの変換を行う）をつけることでかなりマシになるようです。
そのようなオプションがあったのですね。 自分が使用しているフリーの画像コンバーター(Converseen)には無かったので盲点でした。 88KBで試したところ、無事最適化をパス致しました。
なので、一先ずこのトピックは解決済みとさせていただきます。 るーさん、運営の方、ご協力いただいた皆様ありがとうございました。
ファイルサイズの大きいsvgでは画像圧縮の本来の目的である「転送量の削減」を悪化させてしまうので、やめておいた方が良いでしょう……。
仰る通りです。勿論止めにします。
WIKIWIKI側の自動圧縮でsharp_yuvオプションを使うのはどうでしょうか？
賛成です。使えるなら是非お願い致します。
色の劣化に限っては、非可逆圧縮時に-sharp_yuvオプション（より正確にRGBからYUVへの変換を行う）をつけることでかなりマシになるようです。 https://squoosh.app/ では「Sharp RGB→YUV conversion」にチェックを入れることで使えます。 ただ、圧縮に掛かる時間が少し長くなり、ファイルサイズも通常より少し増えます。
参考までにSquooshでEffort=6、Quality=70、Sharp RGB→YUV conversionにチェックして圧縮した画像です (約59KB)。パッと見で違いが分からないくらいにはなったかと思います。
スレ主さんはおそらく色の劣化が気になっていらっしゃると思うので、自前で前述の非可逆圧縮をするか、WIKIWIKI側の自動圧縮で前述のオプションを使うのはどうでしょうか？
個人的には文字色が明らかに薄くなっている以外では、他の劣化はほぼ気にならないレベルですし。
この画像（940x540pxの24bit画像）を89KB以下にロスレス圧縮する方法
こちらでlibwebp 1.3.0を使って最大のロスレス圧縮をしてみましたが、157.382KBでした。 画像の可逆圧縮ではwebpが最強だと思うので、これ以上小さくしたいなら非可逆圧縮するしかなさそうですね。
svg(309KB)を試してみたところ、最適化されないことが分かりました
最後にWIKIWIKI運営さんにおききしたいのですが、
解像度に見合った最適解のファイルサイズがある
89kb 以下の画像サイズにするとパスするかも知れません。
この画像（940x540pxの24bit画像）を89KB以下にロスレス圧縮する方法※を、 どなたかご教授頂けないでしょうか。 （※webで扱える画像形式で）
ちなみにpngでも8bitだとファイルサイズは46KBまで落ちるのですが、 gif同様256色表示になる（中間色の色が変わってしまう）ので論外です。
現在でも抜け道はありますが、対応する予定です。
ダメもとでsvg(309KB)を試してみたところ、最適化されないことが分かりました。 対応予定の抜け道とはベクター画像のことでしょうか? ベクター画像のsvgはctrl + マウスホイールで拡大しても劣化しない特徴があり、 仰っている抜け道でないのであれば、 この画像を含め、3枚程差し替えたいと思いますが、OKでしょうか。
webp からの webp は劣化が激しいと思います。
webpからwebpの再圧縮だから劣化が激しいのではなく、 最適化の際に非可逆圧縮されてしまうために劣化するのだと思われます。 最初からjpgや非可逆圧縮モードのwebpでアップしたのと同じことになってしまう訳です。
jpgや非可逆圧縮モードのwebpでも劣化が気にならないケースは多いですが、 この画像の場合、非可逆圧縮ではどうしても劣化が目立ってしまうので、 ロスレス圧縮のwebp（あるいはpng）でアップしているのです。
利用者が認識困難でなければ、許容範囲内ではないかと思います。
ええ、そうなんです。本当に些細なことなんですが、 画像最適化導入以降ずっと引っかかっているのも事実なので、 なんとか改善されないものかと思い、リクエストしてみた次第です。
一個人の意見でありますが文字認識及び、グラフィックがぼやける等で利用者が認識困難でなければ、許容範囲内ではないかと思います。
640x540 ですと 89kb 以下の画像サイズにするとパスするかも知れません。 下の ds_command panel.png 640x360 29kb はパスしてますね。
共有ありがとうございます。 許容範囲かどうか、みなさんのご意見を聞かせていただけたらと思います。
画像直リンク
もとの画像がwebpでアップされています。 webp の 181kb はサイズが大きいと判断して再圧縮されている可能性があります。 webp からの webp は劣化が激しいと思います。
他のフォーマットでも妥当な画像サイズなら最適化なしでそのまま表示されますので、 お試しいただけたら幸いです。
こちらのページになります。 問題の画像は中央のインベントリー画像(640x540px)で、以前はpngでしたが、 現在はロスレスのwebp(176MB)に差し替えて、以前のpngは削除済みです。
敢えてnolink指定していないので、クリックで実際の添付画像と容易に比較できます。 比較すると、特にカラー文字（ブルー、オレンジ、グリーン）が劣化しているのが一目瞭然かと思います。 画像最適化が導入されて以降、こうなっているのですが、 その下のpng画像(640x360px, 28KB)は現在でも問題ありません。
ページの最大添付画像数はどのくらいなら許容できるでしょうか？
「総容量」ではなく「総枚数」なのですね… 咄嗟には見当がつかないので、自分も皆さんの意見を伺ってみたいです。 小さい画像を沢山貼っていると不利になると思うので、 （当wikiだと各種所持品一覧とかが該当するんですよね…） 可能なら「総枚数」でなく「総容量」にしていただけるとありがたいです。 （枚数は減らせなくても、ファイルサイズならある程度の調整が可能です）
アクセスがあるページほど、画像の圧縮率が高くなるようなことは避けたいと考えております
同意致します。 運営側から見れば、アクセス数の多いページ程データ転送量が増えるので、 シビアな調整をお願いしたい…となるのでしょうが、 アクセス数の多いwikiとそうでないwikiとの処遇格差につながりかねないので、 それはやめた方がいいと思います。
上記のように、640x540pxのwebp画像を640x540で表示していますが、劣化して表示されます。 それとも解像度に見合った最適解のファイルサイズがあるということでしょうか。
あります。 よろしければ掲載しているURLをここで共有していただくことは可能でしょうか？ 今後の最適化の調整の参考とさせていただきます。
上記画像の添付ページは、添付枚数が3枚(jpg,webp,png各1枚)、容量は合計674KBですが、 「ページあたりの上限設定を超えない限り、そのページの画像最適化は行わない」とした場合、 ページ上限は、どの程度が想定されるでしょうか。
申し訳ございません。 逆に質問になってしまうのですが、ページの最大添付画像数はどのくらいなら許容できるでしょうか？
例えば、計算しやすいように1ページあたり最大4枚とします。 容量は1ページあたり最大2MB、1日1000人がそのページを閲覧すると、転送量が1日およそ2GBになります。 （そのくらい訪問数があるページが多数あります）
実際は「Lagy load」や「ブラウザキャッシュ」でそこまで転送量が発生しません。 でも、最大4枚は少なすぎなのに転送量がそこそこあります。
新しい機能を実装すると全てのWIKIに適用されることになります。 個別のWIKIだけに適用することはできません。 アクセス数があるWIKIに適用されることも想定しているのでシビアになってしまいます。
また、アクセス数で調整する方法もありますが、アクセスがあるページほど、画像の圧縮率が高くなるようなことは避けたいと考えております。アクセス数で画像の解像度が動的に変わると気持ち悪いですし、CDNのキャシュ効率も悪くなります。
今後の開発の参考にさせていただきますので、 引き続き、他のユーザーの意見も交えて議論いただけたら幸いです。
返答ありがとうございます。
具体例として挙げた画像(png, webp)は640x540pxで、 縮小・拡大表示はしていないのですが、 webpでもロスレス圧縮だとこれ以上ファイルサイズが小さくならないようなので、 対応できないということであれば一先ず諦めるしかなさそうですね…
表示させたい画像サイズ(ピクセル)に合わせた画像を用意していただくことで劣化を防ぐことができます。
どういう意味でしょうか? 上記のように、640x540pxのwebp画像を640x540で表示していますが、劣化して表示されます。 それとも解像度に見合った最適解のファイルサイズがあるということでしょうか。
1ページあたりの使える画像数の制限を入れる(実装は容易)
ご不便をおかけして申し訳ございません。 転送量削減のため、表示画像の最適化を行っております。
実際の画像サイズ(容量)と画像サイズ(ピクセル)、圧縮フォーマットをもとにして、 表示させる画像サイズ(ピクセル)に合わせて最適化しています。
極端な例ですが、実際の画像サイズ(100px,100px)なのに、アイコンとして画像サイズ(25px,25px)で表示させようとすると画像サイズ(25px,25px)より、ちょっと大きめで最適化されます。
512MBを超過しない限り最適化されないように設定変更していただくか、 あるいは指定画像のみ最適化されない表示オプションを追加していただくことは可能でしょうか。
このような抜け道を追加することは難しいです。 現在でも抜け道はありますが、対応する予定です。
良いアイディアがあれば、引き続きこちらで議論していただけると幸いです。
例えば… 以下の条件で画像を最適化しない
など…
同事象でお困りの管理者やWiki関係者にも当トピックがお役に立つよう、願っております。
また、このSMS認証は制限に巻き込まれた場合の救済措置機能です。
「投稿するにはSMS認証が必要です」とでた場合 https://wikiwiki.jp/pp/sms
かしこまりました。運営としてできる限りの対処を行っていただき、ありがとうございます。 規制対象者が立ち去るまでは、その他多くの利用者にも不便を強いられることになるのは致し方ないですね。
既にご存知の通り、SMS認証のCookieを削除することで未認証端末になります。 永続的に特定のユーザーをマーキングすることができません。 ご理解いただきますようお願い申し上げます。
追記: つまり、SMSトークン単体の規制だけでは、クッキーでの規制と同じことになります。
上記は「その他/旧WIKI/*」についてです。 SMS認証の必要のあるページにしか効力が発生せず、通常ユーザーにもSMS認証を求められます。 通常ユーザーにはSMS認証が心理的負担が大きく、情報提供される機会を阻害されてしまいます。 すでに当Wikiにも過去に検証しており、Wikiの改善や情報提供などの編集される日が激減して、規制ルールを取りやめております。
要望としてSMSトークンの規制対象者のみ、ワイルドカードを使用している対象ページまたは、全ページに効果があるように仕様の変更を希望いたします。 多くの利用者は、SMS認証をしてまでWikiの編集をしてくれません。他のWikiでは、SMS認証せずに編集できるからと思う人もいるからです。電話番号を伝えることに抵抗を感じる人は少なくありません。少なくとも通常の利用者には、これまで通りにSMS認証なく編集ができる上で、SMSトークンの規制が働くことが望ましいです。
修正のご対応を行っていただき、ありがとうございます。 当方でも規制されて編集できないことを確認いたしました。
ご不便をおかけして申し訳ございません。 半角のスラッシュ/がワイルドカードでマッチできていませんでした。 修正しましたので再度お試し下さい。
/
承知しました。 ご検討よろしくお願いします。
複合ルール (高度な設定)を追加しました。
コントロールパネル/規制ルール https://wikiwiki.jp/sample/-s/4e3dc6ec
要望ありがとうございます。 検討いたします。
要望ありがとうございます。 この機能を追加することは簡単ですが、荒らし行為で利用されたりすることも考えられます。 どのくらい需要があるのか判断が難しいので、引き続きこちらで議論いただけたら幸いです。
#rtcommentはオンライン人数が100人以上になっても軽快に動作するように機能を制限しています。 荒らしがきたら「この投稿者を非表示にする」ボタンで消し込むか#rtcommentを一時的に撤去してください。
#rtcomment
または#pcommentや#zcommentにすることも検討してください。
#pcomment
#zcomment
申し訳ございません。
当サービスは複数人が共同でWebサイトを構築していく利用法を想定しており、 閲覧者が簡単にページを作成や修正、削除することができるようになっています。
閲覧制限の機能は今のところ考えておりません。
ご心配いただきありがとうございます。 今では記事内の画像は自動で最適化表示され、転送量を削減しています。 画像をクリックすると最適化前の画像が表示されます。
ご対応ありがとうございました
アップロード上限が引き上げ不可の件、了解しました。
ご回答ありがとうございます。 応急処置のままで継続させていただきます。
ご不便をおかけして申し訳ございません。 今後の開発の参考とさせていただきます。
構文ハイライト機能は動作保証しておりません。 気になるようでしたら、通常のプレーンテキストモードをお使いください。
ご不便をおかけして申し訳ございません。 環境によって上記の現象が発生するようです。 リアルタイムで表示することでブラウザに負荷がかかっている可能性があります。 今後の開発の参考とさせていただきます。
ご不便をおかけして申し訳ございません。 データの容量が大きいとサーバー側で時間がかかりタイムアウトします。 dumpプラグインを廃止にして「コントロールパネル」からダウンロードができるように検討いたします。
ご報告ありがとうございます。 上記の不具合、修正いたしました。
申し訳ございません。アップロードの上限を引き上げることは難しいです。 大容量のファイルがページ内で展開されると閲覧者の回線や端末、サーバーに負荷がかかります。 他のWIKIにも影響がありますので、制限させていただいております。 また、倉庫としてのご利用は利用規約で禁止となっております。
Twitterなど埋め込んだコンテンツは後から読み込まれ、高さが決まります。 そのコンテンツの配信が遅いほど、ズレることがあります。
Fandom (Wikia) については知らないですが、 日本のレンタルwikiはどこも管理ユーザー登録は1人だと思います。 管理ユーザー1名 + 管理ユーザーが認めた副管理者複数名による管理で、 wikiwikiも同様です。 管理ユーザーが複数名になることでどんなメリットがあるのか自分は思い当たりませんし、 あなたの簡素過ぎる文章からも伝わってきません。 （逆に管理者同士が対立したり編集合戦を繰り広げたらどうなるのかなと思います）
「具体的な提案や理由を書いて下さい」とあるように、 具体的なメリットが伝わるように書かないと共感は得られないと思いますよ。
詳しく検証してみました。
応答不能になる条件
同じページに後半(末尾)が異なる文字列がある
文字列にアルファベットが多い場合(数字のみでは起こらない)
ページの例
Chromeで「これらのキーワードがハイライトされています」が表示されるまでの時間は
”FFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(31文字)の場合6秒
”GFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(32文字)の場合13秒
”GGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(33文字)の場合32秒
”GGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(34文字)の場合1分39秒
”GGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA0”(35文字)の場合2分15秒
と1文字増えるごとにかなり時間が伸びました。
(途中で「ページが応答しません」となっても放置した場合)
なお、どちらの行にも共通する
”HHHHHGGGGGFFFFFEEEEEDDDDDCCCCCBBBBBAAAAA”(40文字)の場合は瞬時に表示されます。
運営の方に質問があるのですが、ディスコードなど外部に添付した画像をWikiに表示させたページがたくさん閲覧された場合は負担をかけることになるのでしょうか？
なるべく高画質なものを添付したい考えがありますので、Wikiのサイズ制限を回避するような形をとっておりました。
もし負担になるようでしたら、半年ごとで1日あたり10000~30000閲覧くらいあるページがいくつかあるので今まで結構な負担をかけてしまってたかなと懸念しております。
もし回避できる方法があればご教示いただければ対応いたします。
ご返信ありがとうございます。
再現性のある現象のようで安心しました。修正を期待しております。
ご回答ありがとうございます。参考にさせていただきます。
申し訳ございません。
写真のような解像度のSVGは非推奨とさせていただきます。
パスする基準について、参考にしてください。
インライン表示の解像度とそのリミットサイズです。
32x32 6.87KB
50x50 8.35KB
200x200 25.29KB
400x400 54.97KB
500x500 71.79KB
800x600 107.06KB
800x800 128.00KB
sharp_yuv オプションは検討いたします。
そのようなオプションがあったのですね。
自分が使用しているフリーの画像コンバーター(Converseen)には無かったので盲点でした。
88KBで試したところ、無事最適化をパス致しました。
なので、一先ずこのトピックは解決済みとさせていただきます。
るーさん、運営の方、ご協力いただいた皆様ありがとうございました。
仰る通りです。勿論止めにします。
賛成です。使えるなら是非お願い致します。
色の劣化に限っては、非可逆圧縮時に-sharp_yuvオプション（より正確にRGBからYUVへの変換を行う）をつけることでかなりマシになるようです。
https://squoosh.app/ では「Sharp RGB→YUV conversion」にチェックを入れることで使えます。
ただ、圧縮に掛かる時間が少し長くなり、ファイルサイズも通常より少し増えます。
参考までにSquooshでEffort=6、Quality=70、Sharp RGB→YUV conversionにチェックして圧縮した画像です (約59KB)。パッと見で違いが分からないくらいにはなったかと思います。
スレ主さんはおそらく色の劣化が気になっていらっしゃると思うので、自前で前述の非可逆圧縮をするか、WIKIWIKI側の自動圧縮で前述のオプションを使うのはどうでしょうか？
個人的には文字色が明らかに薄くなっている以外では、他の劣化はほぼ気にならないレベルですし。
こちらでlibwebp 1.3.0を使って最大のロスレス圧縮をしてみましたが、157.382KBでした。
画像の可逆圧縮ではwebpが最強だと思うので、これ以上小さくしたいなら非可逆圧縮するしかなさそうですね。
ファイルサイズの大きいsvgでは画像圧縮の本来の目的である「転送量の削減」を悪化させてしまうので、やめておいた方が良いでしょう……。
最後にWIKIWIKI運営さんにおききしたいのですが、
ということですが、具体的にはどの解像度でどのくらいのサイズが理想なのでしょうか？
今後も同じように画像を圧縮してほしくない際の参考にもなると思うので、共有いただければ幸いです。
この画像（940x540pxの24bit画像）を89KB以下にロスレス圧縮する方法※を、
どなたかご教授頂けないでしょうか。
（※webで扱える画像形式で）
ちなみにpngでも8bitだとファイルサイズは46KBまで落ちるのですが、
gif同様256色表示になる（中間色の色が変わってしまう）ので論外です。
ダメもとでsvg(309KB)を試してみたところ、最適化されないことが分かりました。
対応予定の抜け道とはベクター画像のことでしょうか?
ベクター画像のsvgはctrl + マウスホイールで拡大しても劣化しない特徴があり、
仰っている抜け道でないのであれば、
この画像を含め、3枚程差し替えたいと思いますが、OKでしょうか。
webpからwebpの再圧縮だから劣化が激しいのではなく、
最適化の際に非可逆圧縮されてしまうために劣化するのだと思われます。
最初からjpgや非可逆圧縮モードのwebpでアップしたのと同じことになってしまう訳です。
jpgや非可逆圧縮モードのwebpでも劣化が気にならないケースは多いですが、
この画像の場合、非可逆圧縮ではどうしても劣化が目立ってしまうので、
ロスレス圧縮のwebp（あるいはpng）でアップしているのです。
ええ、そうなんです。本当に些細なことなんですが、
画像最適化導入以降ずっと引っかかっているのも事実なので、
なんとか改善されないものかと思い、リクエストしてみた次第です。
一個人の意見でありますが文字認識及び、グラフィックがぼやける等で利用者が認識困難でなければ、許容範囲内ではないかと思います。
640x540 ですと 89kb 以下の画像サイズにするとパスするかも知れません。
下の ds_command panel.png 640x360 29kb はパスしてますね。
共有ありがとうございます。
許容範囲かどうか、みなさんのご意見を聞かせていただけたらと思います。
画像直リンク
もとの画像がwebpでアップされています。
webp の 181kb はサイズが大きいと判断して再圧縮されている可能性があります。
webp からの webp は劣化が激しいと思います。
他のフォーマットでも妥当な画像サイズなら最適化なしでそのまま表示されますので、
お試しいただけたら幸いです。
こちらのページになります。
問題の画像は中央のインベントリー画像(640x540px)で、以前はpngでしたが、
現在はロスレスのwebp(176MB)に差し替えて、以前のpngは削除済みです。
敢えてnolink指定していないので、クリックで実際の添付画像と容易に比較できます。
比較すると、特にカラー文字（ブルー、オレンジ、グリーン）が劣化しているのが一目瞭然かと思います。
画像最適化が導入されて以降、こうなっているのですが、
その下のpng画像(640x360px, 28KB)は現在でも問題ありません。
「総容量」ではなく「総枚数」なのですね…
咄嗟には見当がつかないので、自分も皆さんの意見を伺ってみたいです。
小さい画像を沢山貼っていると不利になると思うので、
（当wikiだと各種所持品一覧とかが該当するんですよね…）
可能なら「総枚数」でなく「総容量」にしていただけるとありがたいです。
（枚数は減らせなくても、ファイルサイズならある程度の調整が可能です）
同意致します。
運営側から見れば、アクセス数の多いページ程データ転送量が増えるので、
シビアな調整をお願いしたい…となるのでしょうが、
アクセス数の多いwikiとそうでないwikiとの処遇格差につながりかねないので、
それはやめた方がいいと思います。
あります。
よろしければ掲載しているURLをここで共有していただくことは可能でしょうか？
今後の最適化の調整の参考とさせていただきます。
申し訳ございません。
逆に質問になってしまうのですが、ページの最大添付画像数はどのくらいなら許容できるでしょうか？
例えば、計算しやすいように1ページあたり最大4枚とします。
容量は1ページあたり最大2MB、1日1000人がそのページを閲覧すると、転送量が1日およそ2GBになります。
（そのくらい訪問数があるページが多数あります）
実際は「Lagy load」や「ブラウザキャッシュ」でそこまで転送量が発生しません。
でも、最大4枚は少なすぎなのに転送量がそこそこあります。
新しい機能を実装すると全てのWIKIに適用されることになります。
個別のWIKIだけに適用することはできません。
アクセス数があるWIKIに適用されることも想定しているのでシビアになってしまいます。
また、アクセス数で調整する方法もありますが、アクセスがあるページほど、画像の圧縮率が高くなるようなことは避けたいと考えております。アクセス数で画像の解像度が動的に変わると気持ち悪いですし、CDNのキャシュ効率も悪くなります。
今後の開発の参考にさせていただきますので、
引き続き、他のユーザーの意見も交えて議論いただけたら幸いです。
返答ありがとうございます。
具体例として挙げた画像(png, webp)は640x540pxで、
縮小・拡大表示はしていないのですが、
webpでもロスレス圧縮だとこれ以上ファイルサイズが小さくならないようなので、
対応できないということであれば一先ず諦めるしかなさそうですね…
どういう意味でしょうか?
上記のように、640x540pxのwebp画像を640x540で表示していますが、劣化して表示されます。
それとも解像度に見合った最適解のファイルサイズがあるということでしょうか。
上記画像の添付ページは、添付枚数が3枚(jpg,webp,png各1枚)、容量は合計674KBですが、
「ページあたりの上限設定を超えない限り、そのページの画像最適化は行わない」とした場合、
ページ上限は、どの程度が想定されるでしょうか。
ご不便をおかけして申し訳ございません。
転送量削減のため、表示画像の最適化を行っております。
実際の画像サイズ(容量)と画像サイズ(ピクセル)、圧縮フォーマットをもとにして、
表示させる画像サイズ(ピクセル)に合わせて最適化しています。
極端な例ですが、実際の画像サイズ(100px,100px)なのに、アイコンとして画像サイズ(25px,25px)で表示させようとすると画像サイズ(25px,25px)より、ちょっと大きめで最適化されます。
表示させたい画像サイズ(ピクセル)に合わせた画像を用意していただくことで劣化を防ぐことができます。
このような抜け道を追加することは難しいです。
現在でも抜け道はありますが、対応する予定です。
良いアイディアがあれば、引き続きこちらで議論していただけると幸いです。
例えば… 以下の条件で画像を最適化しない
など…
同事象でお困りの管理者やWiki関係者にも当トピックがお役に立つよう、願っております。
また、このSMS認証は制限に巻き込まれた場合の救済措置機能です。
「投稿するにはSMS認証が必要です」とでた場合
https://wikiwiki.jp/pp/sms
かしこまりました。運営としてできる限りの対処を行っていただき、ありがとうございます。
規制対象者が立ち去るまでは、その他多くの利用者にも不便を強いられることになるのは致し方ないですね。
既にご存知の通り、SMS認証のCookieを削除することで未認証端末になります。
永続的に特定のユーザーをマーキングすることができません。
ご理解いただきますようお願い申し上げます。
追記:
つまり、SMSトークン単体の規制だけでは、クッキーでの規制と同じことになります。
上記は「その他/旧WIKI/*」についてです。
SMS認証の必要のあるページにしか効力が発生せず、通常ユーザーにもSMS認証を求められます。
通常ユーザーにはSMS認証が心理的負担が大きく、情報提供される機会を阻害されてしまいます。
すでに当Wikiにも過去に検証しており、Wikiの改善や情報提供などの編集される日が激減して、規制ルールを取りやめております。
要望としてSMSトークンの規制対象者のみ、ワイルドカードを使用している対象ページまたは、全ページに効果があるように仕様の変更を希望いたします。
多くの利用者は、SMS認証をしてまでWikiの編集をしてくれません。他のWikiでは、SMS認証せずに編集できるからと思う人もいるからです。電話番号を伝えることに抵抗を感じる人は少なくありません。少なくとも通常の利用者には、これまで通りにSMS認証なく編集ができる上で、SMSトークンの規制が働くことが望ましいです。
修正のご対応を行っていただき、ありがとうございます。
当方でも規制されて編集できないことを確認いたしました。
ご不便をおかけして申し訳ございません。
半角のスラッシュ
/がワイルドカードでマッチできていませんでした。修正しましたので再度お試し下さい。
承知しました。
ご検討よろしくお願いします。
複合ルール (高度な設定)を追加しました。
コントロールパネル/規制ルール
https://wikiwiki.jp/sample/-s/4e3dc6ec
要望ありがとうございます。
検討いたします。
要望ありがとうございます。
検討いたします。
要望ありがとうございます。
この機能を追加することは簡単ですが、荒らし行為で利用されたりすることも考えられます。
どのくらい需要があるのか判断が難しいので、引き続きこちらで議論いただけたら幸いです。
#rtcommentはオンライン人数が100人以上になっても軽快に動作するように機能を制限しています。荒らしがきたら「この投稿者を非表示にする」ボタンで消し込むか
#rtcommentを一時的に撤去してください。または
#pcommentや#zcommentにすることも検討してください。申し訳ございません。
当サービスは複数人が共同でWebサイトを構築していく利用法を想定しており、
閲覧者が簡単にページを作成や修正、削除することができるようになっています。
閲覧制限の機能は今のところ考えておりません。
ご心配いただきありがとうございます。
今では記事内の画像は自動で最適化表示され、転送量を削減しています。
画像をクリックすると最適化前の画像が表示されます。
ご対応ありがとうございました
アップロード上限が引き上げ不可の件、了解しました。
ご回答ありがとうございます。
応急処置のままで継続させていただきます。
ご不便をおかけして申し訳ございません。
今後の開発の参考とさせていただきます。
構文ハイライト機能は動作保証しておりません。
気になるようでしたら、通常のプレーンテキストモードをお使いください。
ご不便をおかけして申し訳ございません。
環境によって上記の現象が発生するようです。
リアルタイムで表示することでブラウザに負荷がかかっている可能性があります。
今後の開発の参考とさせていただきます。
ご不便をおかけして申し訳ございません。
データの容量が大きいとサーバー側で時間がかかりタイムアウトします。
dumpプラグインを廃止にして「コントロールパネル」からダウンロードができるように検討いたします。
ご報告ありがとうございます。
上記の不具合、修正いたしました。
申し訳ございません。アップロードの上限を引き上げることは難しいです。
大容量のファイルがページ内で展開されると閲覧者の回線や端末、サーバーに負荷がかかります。
他のWIKIにも影響がありますので、制限させていただいております。
また、倉庫としてのご利用は利用規約で禁止となっております。
Twitterなど埋め込んだコンテンツは後から読み込まれ、高さが決まります。
そのコンテンツの配信が遅いほど、ズレることがあります。
Fandom (Wikia) については知らないですが、
日本のレンタルwikiはどこも管理ユーザー登録は1人だと思います。
管理ユーザー1名 + 管理ユーザーが認めた副管理者複数名による管理で、
wikiwikiも同様です。
管理ユーザーが複数名になることでどんなメリットがあるのか自分は思い当たりませんし、
あなたの簡素過ぎる文章からも伝わってきません。
（逆に管理者同士が対立したり編集合戦を繰り広げたらどうなるのかなと思います）
「具体的な提案や理由を書いて下さい」とあるように、
具体的なメリットが伝わるように書かないと共感は得られないと思いますよ。