リクエスト広場

ありがとうございます。
このことをヘルプページにも追記していただければ、利用者の方も混乱なくプラグインを利用できると思いますので、宜しければ追記の方をお願い申し上げます。

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週間の転送量となります。

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

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

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