リクエスト広場

1,450 件中 1,121 から 1,160 までを表示しています。
8
koishiba 2023/02/13 (月) 20:15:40 0b3fb@3e4f2 >> 2

ログインユーザーのみ編集可能にできる機能が欲しいのなら、
別にトピックを立てられたら良いと思います。
(確かSeeSaaWikiやatwikiなどではできた筈です。
もっとも、その設定が可能なのは管理ユーザーだけですが)
追加されるかは運営次第ですが、
機能が増える分には誰も異は唱えないと思いますよ。

ページの新規作成に(パスワードによる)制限を掛けるのは現状でも可能です。
サブパスワード所持者でも行えるようです。

ページの削除に関しては、基本的には誰でもできるようにしておかないと、
管理放棄されたwikiに荒らしが悪戯で作成したページが増殖していくことになりかねないので、
運営は応じないだろうと思います。

7
名前なし 2023/02/13 (月) 18:00:45 修正 50f3f@94f39 >> 2

ログインしてないと編集できないようにするというのは、編集するハードルを上げることで荒らしを抑制できるのではないかという意見です。
ログインしないとページの新規作成や削除ができない的なやり方でもいいと思います。

6
名前なし 2023/02/13 (月) 17:55:13 修正 50f3f@94f39 >> 2

説明不足でした。私としては、手動でもできることを管理者権限で制限していることは矛盾していると感じています。手間か手間ではないかの違いで荒らされるリスクは開放しても変わらないと感じています。管理体制云々ではなく、そもそもが矛盾しているでしょって話です。
リネームを制限するのであれば、新規作成や削除も制限されるべきです。

>何を根拠に信頼関係があると主張するのかさっぱりわかりません。
信頼してない人に編集合戦・荒らし対応をお任せしているというのであれば私から言うことは何もありません。

5
koishiba 2023/02/13 (月) 17:52:10 0b3fb@27dcd >> 2

ログインしていないと編集できないようにすることと、
ページリネームの開放要請にどのような関係があるのでしょうか。
ログインメンバーのみ編集可能にする機能が導入されたとしても、
管理ユーザーはあくまで1人であり(他のwikiサービスも同じです)、
ページリネームは管理ユーザーだけの権限と運営が考えている以上、
権限が開放されることはないだろうと思います。

サブパスワード所持者の主たる役割についてはあくまで私見です。
コントロールパネルの解説ページを見ると、デザインや各種設定、高度な操作など、
編集合戦・荒らし対応と無関係なものはサブパスワード所持者には行えず、
サブパスワード所持者が行えるのは、編集差分ログ・規制ルール・編集制限・通報など、
編集合戦・荒らし対応に関連するものだけだからです。

信頼関係云々については、
何を根拠に信頼関係があると主張するのかさっぱりわかりません。
サブパスワード申請を認めてもらったのだから管理ユーザーから信頼されている
→信頼されているのだからページリネームできるようにしてほしい
そういう理屈でしょうか?

4
名前なし 2023/02/13 (月) 17:32:33 修正 50f3f@94f39 >> 3

ページ名変更や一括変換はやり方によっては手動でもできると思いますが、その機能を管理者のみに制限してるにもかかわらず誰でも編集OKとしているのは矛盾しているのかなと感じたのでトピックを作成した次第です。
手間が掛かるか掛からないかの違いで、管理云々は何も関係なく致命的なダメージが与えられるリスクは常にあると感じています。
とりあえず要望を伝える目的でのトピック作成ですので、これ以上のコメントは控えます。

3
アカサカ 2023/02/13 (月) 15:57:52 a0551@119fb

ページ名変更と一括変換機能の二つは利用しているWIKIでも時折、話題になります。私自身も開放してほしいと待ち望んでいる一人です。
ですがWIKIWIKIは運営開始当初から一貫して、1人の管理人が全体を管理することが前提であるシステムとなっています。
運営の方針がWIKIへの致命的ダメージを与えることもある管理権限を複数人で行使することを許容しない限り、なかなか仕様が変更されることはなさそうです。

2
名前なし 2023/02/13 (月) 14:44:29 修正 50f3f@94f39 >> 1

何が的外れなのかは分かりませんが、例えばログインしてないと編集できないようにページ単位で制限するといった機能も荒らし対策の1つになると同時に、誰が編集したのかといった確認もやりやすくなります。

>サブパスワード所持者の主な役割は編集合戦や荒らし対応
こちらはWikiWiki運営が示しているのですか?

>そもそも管理ユーザーとサブパスワード所持者の権限に差が無ければ、
>見ず知らずの他人のサブパスワード申請に応じる管理ユーザーはほとんどいなくなるのではないでしょうか。
信頼関係があってサブパスワード申請に応じるのではないですか?その理論でいうとサブパスワード保持者からしても管理人は見ず知らずの他人です。

1
koishiba 2023/02/13 (月) 14:30:23 0b3fb@83373

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

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

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

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

1
名前なし 2023/02/12 (日) 05:39:15 80cc4@2e980

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 」にアクセスできないのが気になります(一部インターネットアーカイブ有)。

5
款冬華 2023/02/05 (日) 10:08:26 修正 >> 2

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

1
モデレーター 2023/02/02 (木) 11:22:09

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

2
名前なし 2023/01/27 (金) 18:54:04 68c4a@d06d0

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

1
名前なし 2023/01/26 (木) 09:03:34 06e64@16f2f

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

12
アカサカ 2023/01/26 (木) 01:39:57 a0551@3cb94

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

11
名前なし 2023/01/25 (水) 18:46:14 68c4a@d2185

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

10
アカサカ 2023/01/24 (火) 22:14:59 a0551@3cb94

zawazawaのアップロードできる最大画像サイズが20MBなので、利便性向上のために引き上げてほしいですね。

9
名前なし 2023/01/24 (火) 21:58:20 f94fd@7752b

WIKIWIKIにて実装されている添付プラグインは「画像」のためだけに存在すると理解しております。
でなければ512KBをオーバーした際に、画像の自動変換処理を動かすよう実装する必要がないためです。
もしzipファイルをアップロードして、それがダウンロードできたとしてもたまたまである認識です。

では512KBが妥当かと言われると指摘されている通り少ないものです。
画像の自動変換は万能ではなく、変換された結果粗いものになってしまうこともあります。
せめて無変換の範囲として1MBは必要であると思います。

4
款冬華 2023/01/21 (土) 19:35:50 修正 >> 2

さらに新・カイロパーク攻略 Wiki 掲示板にある雑談(当Wikiにアクセスして確認しました。

コメントアウトしても位置ずれ発生のまま

#ecache
#flex_container
#flex_box
#contentsx
#includex

コメントアウトして位置ずれ改善

#zrecent
#zcomment

zrecentとzcommentはそれぞれ個別にコメントアウトしても位置ずれが発生しました。同時に2つコメントアウトしてようやく、位置ずれが改善されました。

3
款冬華 2023/01/21 (土) 17:25:15 修正 >> 2

zcommentの高さと件数を指定していたので、指定なしに変更してみましたが改善されませんでした。

2
款冬華 2023/01/21 (土) 17:20:49 修正 >> 1

返信ありがとうございます。
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)を貼り付けて確認したところ、変わらず位置ずれが発生して改善されませんでした。

1
01v 2023/01/21 (土) 08:57:45

androidから見ましたがずれません。ページを読み込んでジャンプした後に、高さのあるコンテンツが後から展開されて位置がずれるのかもしれません。
そこよりより上にあるZコメントやTwitter、ecashを切ってどうなるなか原因を絞り込んでみてください。
類似の話題

12
psssale管理人 2023/01/12 (木) 22:36:26 07856@bfcb5 >> 11

すみませんでした。新しくトピックを立てることにします。

8
名前なし 2023/01/12 (木) 16:28:22 0b324@64795

……MBの間違いですよね?
2GBの画像なんてものはそもそも現実的ではなく、8K画像の24bitBMPでさえ100MB弱です。
そこまで上限大きいとファイル偽装の違法ファイル取引の温床になりかねないので、
ceptさんがおっしゃるように3MB、多くて5MBぐらいが理想かなぁ

1
LEGLEG 2023/01/11 (水) 15:29:59 修正

同意です。
不適切な文字列や、文字数制限を超える文章荒らしに対応できないのは少し痛いところです。「#zcomment」では禁止ワード機能が使用できるのに、ZAWAZAWA外のコメントプラグインやコメントの関係ないwikiページでの不適切な文字列の編集に柔軟に対応できないのは困るところがあります。

7

2GBの画像が添付されることはおそらく一般的でなく、ページ閲覧者のデータ使用量を不意打ち気味に奪いかねないといった懸念もあるのでちょっと上限としてどうかなと思いますね…その手のサイズはすでに仰っているように外部アップローダーを利用するのが適当かと思います。

ただ、現状の512KBはpng、gif等のアップロードに困るサイズだと日常的に感じています。
ざっくり他のサービスを調べたところ、wicurioが19.5MB、atwikiが1MB、seesaaが5MB、Wikihouseが16MB上限のようです。この数字を考えるとやはり512KBというのは小さく、せめて3MB程度はほしいなあと…

6
まるね 2023/01/07 (土) 12:50:13

一つの単語ごとに一個戻るようになった。すまほでの編集が困難になってるから早急になんとかしてほしい

6
nemesislivezx 2023/01/06 (金) 00:10:05 >> 2

そうですか。それなら2GBの方が良いですね。

11
アカサカ 2023/01/03 (火) 06:58:02 f417f@233c1 >> 10

以前、運営さんから解決済みトピックに対する追加の問い合わせは新たにトピックを立ててくださいとメールにて、回答を頂いています。そのため、新たにトピックを立てることをおすすめします。

10
psssale管理人 2023/01/02 (月) 22:59:10 07856@bfcb5

解決済みになって終わってる話かもしれませんが横から失礼します。

機能的には満足しているんですが、いつのころからかtablesortの動作が非常に遅くなってしまったと感じています。
うちのWikiでの使い方がtablesortの中にtrackerの出力を入れて数千行をソートする特殊な状況なので他のWikiでは問題にならないのかもしれませんが、以前は遅くても数秒だったのが10秒以上かかるようになったので感覚としては5倍ほど遅くなったかなと。
うちのWiki⇒https://wikiwiki.jp/psssale/-s/53f602c4

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

4

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

3
nemesislivezx 2023/01/01 (日) 13:30:32 修正 >> 2

「二次創作 Wiki*」に2GBもする画像もしくは100GBもする二次創作作品(ゲームなど)を配布したい人もいます。

2

ちょっと気になったんですけど100GBも何に使うんですか?個人的には2GBもありゃ大体のことは足りるとは思ってます

1
nemesislivezx 2022/12/28 (水) 00:19:06 修正

WikiWikiにも大容量ファイルを添付したい人がいます。
それを避けるためにアップロード可能最大ファイルサイズを512KBから2GBもしくは100GBまで増加してほしいのです。

5

ひょっとしたらと思ってchromeでもやってみると案の定なった。誰かならないブラウザ教えてくだしぃ…できるのなら修正してほしい

4

edgeでもなるようになった。なにか変えた覚えもないし理由がわからなぃ…最近アプデがあったみたいだけどそれだろうか

9
01v 2022/12/17 (土) 11:13:18

ご対応ありがとうございます。

7
もちチーズ 2022/12/15 (木) 21:41:27

&br;を使用せずとも自動で改行が行われるようになったことを確認しました。ご対応いただきありがとうございます。😭🙏

8
アカサカ 2022/12/14 (水) 15:14:39 f417f@cf6d3 >> 2

現時点でPC、モバイル共にどちらの閲覧時でも01vさんの要望通りに修正されたことを確認しました。

6
名前なし 2022/12/10 (土) 00:08:36 4799d@55fea >> 4

トピック説明のところに「この掲示板は運営に直接質問や要望を伝えるところではありません……基本的にはディスカッションに参加しません。」とあるので、元来そういう用途のトピックではないと思います。
ただ挙げていただいたようなデメリットは実際に存在するので、運営が確認しているならば早期の修正かサンプルwikiなどでの告知をお願いしたいですね。

5
名前なし 2022/12/09 (金) 23:59:56 4799d@55fea >> 2

せっかくご回答をいただいたのに、なかなか確認の時間が取れず、再度返信が遅くなりすみません。
brの改行での対処が可能なことは存じ上げませんでした。ありがとうございます。 
しかし、手動での改行はやや不便なところがあるので、できれば機能の改善が欲しいところだと個人的には思います。
ともあれ、一旦は解決することができたので助かりました。Yuuさんご教示ありがとうございました。