ATOK for Android(買い切り版)、かつ構文ハイライトあり →カーソルが想定外の位置に行く現象が起こったので、01vさん>> 4の説が腑に落ちました。 買い切り版はサポートを終了しているためPOBox Touchと同じ状態です。
アリかなと思います。
データ編集用のページで全情報を入れておき、includexで取り込む際不要な列は非表示にしたいことがあります。 このケースの場合、行であればnullプラグインとincludex側指定で代替できますが、列はどうしようもありません。 導入されれば便利になると思います。
（tracker_plus_listでやれはごもっともですが）
https://pukiwiki.osdn.jp/?自作プラグイン/fa.inc.php
https://pukiwiki.osdn.jp/?欲しいプラグイン/407
いいですね。便利に使えそうです。
kanateko氏は便利なプラグインをいくつも作っていますね。 （sliderプラグインの実装も是非！）
https://pukiwiki.osdn.jp/?自作プラグイン/tab2.inc.php
https://jpngamerswiki.com/?21026aa838
閲覧制限ではなく「編集制限」ですよね? （閲覧制限はあり得ないです。 レンタルwikiだけでなく個人でサーバーを運用する場合も同様です）
閲覧を含めてグループ内だけで共有…ということなら、 グループウェアをご利用ください。
同じく、テーブルの行を格納・展開できる機能があると嬉しいです。 列の方を必要とする機会はあまりないですが、行の方は無暗に表が長くなるのを避けることができて便利そうですね。
運営が対応されるまで、しばらくの間は以下の記述で画像を表示してください。(編集プレビューで画像表示を確認済)
**譜面 [#score] //~BPMは中盤が172でそれ以外は258。 ~&attachref(https://cdn.wikiwiki.jp/to/w/taiko-fumen/%E5%8F%8E%E9%8C%B2%E6%9B%B2/%E3%81%8A%E3%81%AB/Spectral%20Rider/::attach/Spectral%20Rider5.png,nolink); ~見た目重視 ~&attachref(https://cdn.wikiwiki.jp/to/w/taiko-fumen/%E5%8F%8E%E9%8C%B2%E6%9B%B2/%E3%81%8A%E3%81%AB/Spectral%20Rider/::attach/Spectral%20Rider%E8%A6%8B%E3%81%9F%E7%9B%AE4.png,nolink);
そうだったのか、半年前に知りたかったぜ…
poboxもサービス終了してます。 想像ですが、どこかのタイミングでOSかブラウザ全般の入力仕様の変更があり 開発を中止してるIMEはそれに対応できてないのでは。
gboard使ったら確かにならなかった。poboxが悪かったのかな？
Android + Gboardで確認しましたがそのような現象にはなりません。 (構文ハイライトあり・なし、どちらも。) Gboardあるいは他の入力アプリで確認してみてください。 Google日本語入力Android版はサポートが終了し、Gboardに統合されてます。
同じ不具合でかれこれ半年以上困ってる…去年はまだedgeとか使えばならなかったけど最近はどのブラウザでもなる
ありがとうございます。 このことをヘルプページにも追記していただければ、利用者の方も混乱なくプラグインを利用できると思いますので、宜しければ追記の方をお願い申し上げます。
TITLE:やLEFT:などの後に半角スペースを入れると行頭スペースと同じように扱われ、整形済みテキストと解釈されるようです。 これは参照文字だけではなくインライン要素も展開されません。 半角スペースを参照文字にする必要があります。
LEFT: &color(lime){ボーカロイド}; LEFT: &color(lime){ボーカロイド}; LEFT:&color(lime){ボーカロイド};
ちなみに段落書式～の後に半角スペースを入れてもスペースは詰めて表示されます。
LEFT:~ &color(lime){ボーカロイド};
どちらのブラウザについても手動アップデートに設定変更していて、バージョンは変わっていませんでした。拡張アドオンも変更していないため改善された理由は不明です。今後とも、より良いサービスの提供をよろしくお願いします。
構文ハイライトは動作保証をしておりません。 使用している端末の環境設定によって使える機能、使えない機能があります。 今回、修正は行っておりませんので、環境設定をご確認ください。 ご理解いただけますと幸いです。🙇♂️
zawazawa掲示板で表データ作成は思うようにいかないので、いつか書式付き貼り付けが出来るようになると嬉しいです。
ご対応ありがとうございます。 本日、当環境でどちらのブラウザでもMicrosoft officeのExcel内の簡単なレイアウトの表をコピーして構文ハイライトβ版の編集画面に右クリックして貼り付けしてみたところ、書式付き貼り付けになっていることを確認しました。
Renameプラグインの中に置換などの機能も含まれてるのが大きな原因なのでしょうか。 管理者が積極的ではないのに毎回お願いするのも、編集者に新規作成を促すのも負担でしかないです。 https://pukiwiki.osdn.jp/dev/?BugTrack/506
>理論上、規制ルールとして、ページ名を対象に、ワイルドカードで*を指定、全ページをSMS認証必須ページとすることのみで、初回でのSMSトークン判別が可能かと思います。 >しかし、一般の利用者の編集等を委縮させてしまう効果があり、可能な限り運用したくはありません。
ページ内容で特定ワードの規制することに賛成です。 当wikiでも以前、荒らし対策として全ページをSMS認証に変更したことがあります。その結果、編集してくれる利用者が躊躇して激減したことがあります。ユーザー登録なしで簡単に誰でも編集できる場であることは、無償の情報提供行為をする上でとても重要だと感じました。
同意です
一括変換は1万ページの大量破壊行為が安易に出来るため、サブ・パスワードへの解放は反対です。方針にも明らかに反するでしょう。
しかし、改名は1ページ1ページ指定する必要があり大量に行うことが出来ないため、破壊行為が安易に出来るという機能とは少し離れています。（間違っていればご指摘ください） 改名ではバックアップを完全に維持することが出来るというメリットもあります。 そのためそちらは賛成です。万一暴走しても、サブ・パスワードを削除し再改名によって、被害を元に戻すことが出来ます。
なおリクエスト広場はディスカッション形式であり単なる要望通達掲示板ではないので、返信は問題ではないと考えます。 ささいなことで都度返信するようではさすがに問題だと思いますが、そうではないように見えます。
ログインユーザーのみ編集可能にできる機能が欲しいのなら、 別にトピックを立てられたら良いと思います。 （確かSeeSaaWikiやatwikiなどではできた筈です。 もっとも、その設定が可能なのは管理ユーザーだけですが） 追加されるかは運営次第ですが、 機能が増える分には誰も異は唱えないと思いますよ。
ページの新規作成に（パスワードによる）制限を掛けるのは現状でも可能です。 サブパスワード所持者でも行えるようです。
ページの削除に関しては、基本的には誰でもできるようにしておかないと、 管理放棄されたwikiに荒らしが悪戯で作成したページが増殖していくことになりかねないので、 運営は応じないだろうと思います。
ログインしてないと編集できないようにするというのは、編集するハードルを上げることで荒らしを抑制できるのではないかという意見です。 ログインしないとページの新規作成や削除ができない的なやり方でもいいと思います。
説明不足でした。私としては、手動でもできることを管理者権限で制限していることは矛盾していると感じています。手間か手間ではないかの違いで荒らされるリスクは開放しても変わらないと感じています。管理体制云々ではなく、そもそもが矛盾しているでしょって話です。 リネームを制限するのであれば、新規作成や削除も制限されるべきです。
＞何を根拠に信頼関係があると主張するのかさっぱりわかりません。 信頼してない人に編集合戦・荒らし対応をお任せしているというのであれば私から言うことは何もありません。
ログインしていないと編集できないようにすることと、 ページリネームの開放要請にどのような関係があるのでしょうか。 ログインメンバーのみ編集可能にする機能が導入されたとしても、 管理ユーザーはあくまで1人であり（他のwikiサービスも同じです）、 ページリネームは管理ユーザーだけの権限と運営が考えている以上、 権限が開放されることはないだろうと思います。
サブパスワード所持者の主たる役割についてはあくまで私見です。 コントロールパネルの解説ページを見ると、デザインや各種設定、高度な操作など、 編集合戦・荒らし対応と無関係なものはサブパスワード所持者には行えず、 サブパスワード所持者が行えるのは、編集差分ログ・規制ルール・編集制限・通報など、 編集合戦・荒らし対応に関連するものだけだからです。
信頼関係云々については、 何を根拠に信頼関係があると主張するのかさっぱりわかりません。 サブパスワード申請を認めてもらったのだから管理ユーザーから信頼されている →信頼されているのだからページリネームできるようにしてほしい そういう理屈でしょうか?
ページ名変更や一括変換はやり方によっては手動でもできると思いますが、その機能を管理者のみに制限してるにもかかわらず誰でも編集OKとしているのは矛盾しているのかなと感じたのでトピックを作成した次第です。 手間が掛かるか掛からないかの違いで、管理云々は何も関係なく致命的なダメージが与えられるリスクは常にあると感じています。 とりあえず要望を伝える目的でのトピック作成ですので、これ以上のコメントは控えます。
ページ名変更と一括変換機能の二つは利用しているWIKIでも時折、話題になります。私自身も開放してほしいと待ち望んでいる一人です。 ですがWIKIWIKIは運営開始当初から一貫して、1人の管理人が全体を管理することが前提であるシステムとなっています。 運営の方針がWIKIへの致命的ダメージを与えることもある管理権限を複数人で行使することを許容しない限り、なかなか仕様が変更されることはなさそうです。
何が的外れなのかは分かりませんが、例えばログインしてないと編集できないようにページ単位で制限するといった機能も荒らし対策の1つになると同時に、誰が編集したのかといった確認もやりやすくなります。
＞サブパスワード所持者の主な役割は編集合戦や荒らし対応 こちらはWikiWiki運営が示しているのですか？
>そもそも管理ユーザーとサブパスワード所持者の権限に差が無ければ、 >見ず知らずの他人のサブパスワード申請に応じる管理ユーザーはほとんどいなくなるのではないでしょうか。 信頼関係があってサブパスワード申請に応じるのではないですか？その理論でいうとサブパスワード保持者からしても管理人は見ず知らずの他人です。
運営が荒らしに敏感なのは当然のことであり、 指摘は的外れなものに思えます。
管理ユーザーが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週間の転送量となります。
ATOK for Android(買い切り版)、かつ構文ハイライトあり
→カーソルが想定外の位置に行く現象が起こったので、01vさん>> 4の説が腑に落ちました。
買い切り版はサポートを終了しているためPOBox Touchと同じ状態です。
アリかなと思います。
データ編集用のページで全情報を入れておき、includexで取り込む際不要な列は非表示にしたいことがあります。
このケースの場合、行であればnullプラグインとincludex側指定で代替できますが、列はどうしようもありません。
導入されれば便利になると思います。
（tracker_plus_listでやれはごもっともですが）
https://pukiwiki.osdn.jp/?自作プラグイン/fa.inc.php
https://pukiwiki.osdn.jp/?欲しいプラグイン/407
いいですね。便利に使えそうです。
kanateko氏は便利なプラグインをいくつも作っていますね。
（sliderプラグインの実装も是非！）
https://pukiwiki.osdn.jp/?自作プラグイン/tab2.inc.php
https://jpngamerswiki.com/?21026aa838
閲覧制限ではなく「編集制限」ですよね?
（閲覧制限はあり得ないです。
レンタルwikiだけでなく個人でサーバーを運用する場合も同様です）
閲覧を含めてグループ内だけで共有…ということなら、
グループウェアをご利用ください。
同じく、テーブルの行を格納・展開できる機能があると嬉しいです。
列の方を必要とする機会はあまりないですが、行の方は無暗に表が長くなるのを避けることができて便利そうですね。
運営が対応されるまで、しばらくの間は以下の記述で画像を表示してください。(編集プレビューで画像表示を確認済)
そうだったのか、半年前に知りたかったぜ…
poboxもサービス終了してます。
想像ですが、どこかのタイミングでOSかブラウザ全般の入力仕様の変更があり
開発を中止してるIMEはそれに対応できてないのでは。
gboard使ったら確かにならなかった。poboxが悪かったのかな？
Android + Gboardで確認しましたがそのような現象にはなりません。
(構文ハイライトあり・なし、どちらも。)
Gboardあるいは他の入力アプリで確認してみてください。
Google日本語入力Android版はサポートが終了し、Gboardに統合されてます。
同じ不具合でかれこれ半年以上困ってる…去年はまだedgeとか使えばならなかったけど最近はどのブラウザでもなる
ありがとうございます。
このことをヘルプページにも追記していただければ、利用者の方も混乱なくプラグインを利用できると思いますので、宜しければ追記の方をお願い申し上げます。
TITLE:やLEFT:などの後に半角スペースを入れると行頭スペースと同じように扱われ、整形済みテキストと解釈されるようです。
これは参照文字だけではなくインライン要素も展開されません。
半角スペースを参照文字にする必要があります。
ちなみに段落書式～の後に半角スペースを入れてもスペースは詰めて表示されます。
どちらのブラウザについても手動アップデートに設定変更していて、バージョンは変わっていませんでした。拡張アドオンも変更していないため改善された理由は不明です。今後とも、より良いサービスの提供をよろしくお願いします。
構文ハイライトは動作保証をしておりません。
使用している端末の環境設定によって使える機能、使えない機能があります。
今回、修正は行っておりませんので、環境設定をご確認ください。
ご理解いただけますと幸いです。🙇♂️
zawazawa掲示板で表データ作成は思うようにいかないので、いつか書式付き貼り付けが出来るようになると嬉しいです。
ご対応ありがとうございます。
本日、当環境でどちらのブラウザでもMicrosoft officeのExcel内の簡単なレイアウトの表をコピーして構文ハイライトβ版の編集画面に右クリックして貼り付けしてみたところ、書式付き貼り付けになっていることを確認しました。
Renameプラグインの中に置換などの機能も含まれてるのが大きな原因なのでしょうか。
管理者が積極的ではないのに毎回お願いするのも、編集者に新規作成を促すのも負担でしかないです。
https://pukiwiki.osdn.jp/dev/?BugTrack/506
>理論上、規制ルールとして、ページ名を対象に、ワイルドカードで*を指定、全ページをSMS認証必須ページとすることのみで、初回でのSMSトークン判別が可能かと思います。
>しかし、一般の利用者の編集等を委縮させてしまう効果があり、可能な限り運用したくはありません。
ページ内容で特定ワードの規制することに賛成です。
当wikiでも以前、荒らし対策として全ページをSMS認証に変更したことがあります。その結果、編集してくれる利用者が躊躇して激減したことがあります。ユーザー登録なしで簡単に誰でも編集できる場であることは、無償の情報提供行為をする上でとても重要だと感じました。
同意です
一括変換は1万ページの大量破壊行為が安易に出来るため、サブ・パスワードへの解放は反対です。方針にも明らかに反するでしょう。
しかし、改名は1ページ1ページ指定する必要があり大量に行うことが出来ないため、破壊行為が安易に出来るという機能とは少し離れています。（間違っていればご指摘ください）
改名ではバックアップを完全に維持することが出来るというメリットもあります。
そのためそちらは賛成です。万一暴走しても、サブ・パスワードを削除し再改名によって、被害を元に戻すことが出来ます。
なおリクエスト広場はディスカッション形式であり単なる要望通達掲示板ではないので、返信は問題ではないと考えます。
ささいなことで都度返信するようではさすがに問題だと思いますが、そうではないように見えます。
ログインユーザーのみ編集可能にできる機能が欲しいのなら、
別にトピックを立てられたら良いと思います。
（確かSeeSaaWikiやatwikiなどではできた筈です。
もっとも、その設定が可能なのは管理ユーザーだけですが）
追加されるかは運営次第ですが、
機能が増える分には誰も異は唱えないと思いますよ。
ページの新規作成に（パスワードによる）制限を掛けるのは現状でも可能です。
サブパスワード所持者でも行えるようです。
ページの削除に関しては、基本的には誰でもできるようにしておかないと、
管理放棄されたwikiに荒らしが悪戯で作成したページが増殖していくことになりかねないので、
運営は応じないだろうと思います。
ログインしてないと編集できないようにするというのは、編集するハードルを上げることで荒らしを抑制できるのではないかという意見です。
ログインしないとページの新規作成や削除ができない的なやり方でもいいと思います。
説明不足でした。私としては、手動でもできることを管理者権限で制限していることは矛盾していると感じています。手間か手間ではないかの違いで荒らされるリスクは開放しても変わらないと感じています。管理体制云々ではなく、そもそもが矛盾しているでしょって話です。
リネームを制限するのであれば、新規作成や削除も制限されるべきです。
＞何を根拠に信頼関係があると主張するのかさっぱりわかりません。
信頼してない人に編集合戦・荒らし対応をお任せしているというのであれば私から言うことは何もありません。
ログインしていないと編集できないようにすることと、
ページリネームの開放要請にどのような関係があるのでしょうか。
ログインメンバーのみ編集可能にする機能が導入されたとしても、
管理ユーザーはあくまで1人であり（他のwikiサービスも同じです）、
ページリネームは管理ユーザーだけの権限と運営が考えている以上、
権限が開放されることはないだろうと思います。
サブパスワード所持者の主たる役割についてはあくまで私見です。
コントロールパネルの解説ページを見ると、デザインや各種設定、高度な操作など、
編集合戦・荒らし対応と無関係なものはサブパスワード所持者には行えず、
サブパスワード所持者が行えるのは、編集差分ログ・規制ルール・編集制限・通報など、
編集合戦・荒らし対応に関連するものだけだからです。
信頼関係云々については、
何を根拠に信頼関係があると主張するのかさっぱりわかりません。
サブパスワード申請を認めてもらったのだから管理ユーザーから信頼されている
→信頼されているのだからページリネームできるようにしてほしい
そういう理屈でしょうか?
ページ名変更や一括変換はやり方によっては手動でもできると思いますが、その機能を管理者のみに制限してるにもかかわらず誰でも編集OKとしているのは矛盾しているのかなと感じたのでトピックを作成した次第です。
手間が掛かるか掛からないかの違いで、管理云々は何も関係なく致命的なダメージが与えられるリスクは常にあると感じています。
とりあえず要望を伝える目的でのトピック作成ですので、これ以上のコメントは控えます。
ページ名変更と一括変換機能の二つは利用しているWIKIでも時折、話題になります。私自身も開放してほしいと待ち望んでいる一人です。
ですがWIKIWIKIは運営開始当初から一貫して、1人の管理人が全体を管理することが前提であるシステムとなっています。
運営の方針がWIKIへの致命的ダメージを与えることもある管理権限を複数人で行使することを許容しない限り、なかなか仕様が変更されることはなさそうです。
何が的外れなのかは分かりませんが、例えばログインしてないと編集できないようにページ単位で制限するといった機能も荒らし対策の1つになると同時に、誰が編集したのかといった確認もやりやすくなります。
＞サブパスワード所持者の主な役割は編集合戦や荒らし対応
こちらはWikiWiki運営が示しているのですか？
>そもそも管理ユーザーとサブパスワード所持者の権限に差が無ければ、
>見ず知らずの他人のサブパスワード申請に応じる管理ユーザーはほとんどいなくなるのではないでしょうか。
信頼関係があってサブパスワード申請に応じるのではないですか？その理論でいうとサブパスワード保持者からしても管理人は見ず知らずの他人です。
運営が荒らしに敏感なのは当然のことであり、
指摘は的外れなものに思えます。
管理ユーザーが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週間の転送量となります。