WIKIの管理者向け機能「dump」が「コントロールパネル」の「高度な操作」から取得できるようになりました。 従来より改善され安定していますが、データ量が多いWIKIでは処理に負荷がかかるため、特別な場合を除き実行を避けてください。
もし大規模な荒らし行為などでWIKIが壊滅的なダメージを受けた場合でも、システム側で1日数回行っているスナップショットがありますので、dumpデータがなくても復旧可能です。その際はWIKIWIKI運営までご連絡いただけると幸いです。
wikiwikiの性格上ゲームの攻略サイトや動画配信者の情報まとめサイトとして使われることが多く、ゲームをしながら・動画を見ながらこのサイトを併用されることも多いと思うのですが、そう言う時にこちらのサイトから音の出る広告が出ると元のゲーム・動画の阻害になってコンテンツの価値をを損ないます。 音の出る広告やコンテンツをこのサイトに残すなら、そういった併用して使われるページの情報は音の出ない、元のコンテンツを阻害しない同業他社のサイトに移植されるべきです。
:RenameLogはローテションで直近50回まで記録するようにしました。
:RenameLog
この度はご不便をおかけし、誠に申し訳ございません。
動画広告の音声は、広告内の音声操作ボタンでミュートすることが可能です。 Chromeをご利用の場合、ブラウザのタブ上で右クリックし、「サイトをミュート」を選択することもできます。
また、当サービスでは、積極的にWIKIに参加するユーザー様には、広告の表示頻度を抑えるよう努めております。 以下の行動に基づいて、広告表示の調整を行っています。
なお、当サービスはアカウント制ではないため、ブラウザのCookieやローカルストレージ、セッションストレージの読み書きが制限されている場合や、これらがリセットされた場合、ユーザー様の識別が難しくなることがございます。 あらかじめご了承ください。
広告について https://wikiwiki.jp/pp/aboutad
利用規約 https://wikiwiki.jp/pp/policies
広告の露出頻度や挙動については、今後も柔軟に調整を進めてまいります。 引き続きご理解とご協力をお願いいたします。
同意です 音出る系の広告はできれば見直していただきたいです
ご指摘のとおり、:RenameLogをリネームしましたところ解決しました。 ご回答ありがとうございました。
上記の不具合を修正いたしました。 ご連絡およびご確認、ありがとうございます。
:RenameLogの容量がいっぱいのようです。 お手数をおかけしますが、削除してから再度お試しください。
https://wikiwiki.jp/control/:RenameLog
:RenameLogのローテーションを検討いたします。
修正していただいた内容を確認いたしました。ご対応ありがとうございます。
「ページ名 - Wiki名」となるように修正いたしました。 （ページ名はTITLE:が優先になります）
TITLE:
また、sns_share_imageおよびdescriptionプラグインを使用して、 ページ単位でシェア情報を変更できるようにしました。
sns_share_image
description
ただし、荒らし行為に利用されるリスクがあるため、管理者の許可が必要です。 許可するには、「コントロールパネル」→「各種設定」→「SNSシェア情報の変更を許可」をONにしてください。 現在の設定情報は、ページ右上のシェアアイコンからプレビューできます。
SNSシェア情報の変更のサンプルはこちらです。
上記の挙動を調整いたしました。
上記の不具合を修正いたしました。
構文ハイライト機能は現在、試験運用中です。 そのため、一部の環境で正常に動作しない場合がございますので、 その際は機能をOFFにして編集していただけると幸いです。
ご不便をおかけして申し訳ございません。
表題の不具合の修正を確認しました。ご対応いただきありがとうございました。
私も同じ症状が発生しています。削除テキスト
ハイライト自体が一定行を境に効かなくなっているようにも見えます
おそらく無関係のwikiで、運用方法も異なる(と、思われる)箇所でも同様の症状が発生したため、グローバルな問題であると思われます。 此方では80行程度で症状が発生しております。
一部のユーザーが想定以上の異常な数のタグ付けしていることによるサーバー高負荷により、タグリスト表示に制約を設けられたものと推察しています。タグリスト表示の上限数について公式より明らかにしてもらいたいです。
無制限に表示できていたことを運営からのアナウンスなしに仕様変更されては、ユーザーとしてプラグイン利用や今後の編集に不安が残ります。tablescrollプラグインの一件もそうですが、今までできていたことに制約を設けてお知らせすることなく仕様変更することはwiki管理者や編集だけするユーザー達を困惑させます。運営と一定の信頼関係を保つためにも、wikiの管理方法を見直させるような仕様変更はX公式アカウントなどでお知らせしてほしいです。なぜなら、当方もinclude系プラグインの使用上限についてで文中に「積極的にecacheプラグインを使用してください。」と記載があり、全ページに導入していました。現在も推奨する文言は訂正や削除されていませんが、非推奨を案内する公式アナウンスで知ってプラグインを無効化させることができました。運営さんにはエラー表示されるから、公式のアナウンスが必要ないと考えないで欲しいです。
#contentsxを使ってください。
タグを使いすぎなのが悪いと言われるとそのとおりなのですが、
・タグ数の上限がない想定で運用していたものを、今から上限を超えないように運用を変えるのは難しい ・ソシャゲのwikiでキャラクターの能力に合わせてタグを付与しており、必要性があるタグなので削減が難しい ・見直しをするとして、どこまで減らせばいいか明示されていない ・全タグのリスト表示自体が機能していないだけで、タグ自体は機能している
という事情から、できればタグのリスト表示自体を前の仕様に戻していただいたり(時期的に>> 3の仕様変更が行われるまでは読み込めていました)、リスト表示を1〜50件のような分割表示可能にしていただいたりとwikiwiki側で対応いただきたいです。
埋め込み型の天気予報動画に擬態した広告で、リンク先はgliacloudというサービスでした スポンサー表記がありません
同じ書式設定の二つの表をincludeなどで取得及び結合してだそうとしても取得元の時点で書式通りではなく表示優先になり同じ書式設定にも関わらず表がずれてしまいます(要は同じ書式にしても記載内容によって表幅が自動調整されてしまうため二つの表をincludeした際にずれてしまう)
対応も必要かもですがそれぞれのwikiでタグの見直しもやった方がいいのではと思います
私が利用するwikiでも Too many tags to display. (1129) となってしまい、taglistの利用ができない状況になりました。 また、tagcloudも最大100件までしか表示できないようになってしまっています。
>> 1で示されている上限を定める形式も機能しません。 ご対応いただきたいです。
質問です。 画像を中心として、メンバー間あるいはゲストの方とのコミュニケーションを図るような使い方をしたいと考えています。
この場合、最大画像サイズおよび一枚あたり容量の制限、および使用できる最大容量または枚数はどのようになっているでしょうか。
今朝、確認してみたら「ページタイトル名 - Wiki名」に仕様変更されていました。ご対応いただき、どうもありがとうございます。
エラーメッセージが Too many tags to display. (54507) になりました。
言ってることがよくわかりませんが おそらく現実的な対応は以下のように元のページの表内に、予め複数の書式定義行を仕込んでおいて、includexで呼び出すときにその書式定義を切り替えることです。 以下の例では元のページでは設定1の書式で表示されますが、 includexで呼び出すときは設定1が除外されて設定2の書式で表示されます。
|設定2|c |設定1|c |内容| --- include(表があるページ,except=設定1)
>> 1
エラーメッセージを見ると Warning: There are over 55,224 tags, which requires approximately 30MB of transfer data to display. This is an unintended use of tags.
なので容量オーバーを起こしていますね…
新たなキャッシュプラグインで同様に実装されないとecacheを使わざる追えないケースとして残るのが懸念ですね
その機能はすでにあります。
https://wikiwiki.jp/aniwota/?cmd=taglist&num=1:50&next あるいは #taglist(num=1:50,next)
ただ上記サイトで確認しようとしましたが上手く機能しません。 行数が多すぎるか、負荷が高すぎるか、異常な文字列が含まれるなどが考えられます。
iOS Safariで、特定のWikiのブックマークアイコンが 他のWikiのアイコンにも反映されてしまう問題についてご案内いたします。
この問題は、iOS Safariの仕様に関連している可能性があります。
（Safariのスタートページに表示されるアイコンは、独自のアルゴリズムで取得されるため、 正しくアイコンが反映されないことがあるようです）
現時点で具体的な解決策は確認されておりません。
Appleにフィードバックを送ることで、将来的な改善が期待できるかもしれません。
ご理解とご協力のほどよろしくお願いいたします。🙇♂️
原神wikiでも同様の現象が起きています。 wikiwikiがfaviconの設定を推奨しているので修正してほしいですし、外部的な要因でwikiwikiの問題でないのであればそのように公表して欲しいです。
同意します。 出来ればnavfoldのように切り替えて表示したタブが記憶されていると嬉しいです。
navfoldはfoldよりも折りたたみされた内容との行間が開くのが不恰好だと思います。 foldと同じ行間になると嬉しいです。
新たなキャッシュプラグインを開発中とのことなので、まだ古い仕様が残っている状態なのだと思います https://zawazawa.jp/wikiwiki/topic/8 https://x.com/WIKIWIKI_Japan/status/1797575512816234881
機能には満足していますが、開閉ボタンの見た目が普通のfoldと同じだと統一感があってもっと良いと思います
WIKIの管理者向け機能「dump」が「コントロールパネル」の「高度な操作」から取得できるようになりました。
従来より改善され安定していますが、データ量が多いWIKIでは処理に負荷がかかるため、特別な場合を除き実行を避けてください。
もし大規模な荒らし行為などでWIKIが壊滅的なダメージを受けた場合でも、システム側で1日数回行っているスナップショットがありますので、dumpデータがなくても復旧可能です。その際はWIKIWIKI運営までご連絡いただけると幸いです。
wikiwikiの性格上ゲームの攻略サイトや動画配信者の情報まとめサイトとして使われることが多く、ゲームをしながら・動画を見ながらこのサイトを併用されることも多いと思うのですが、そう言う時にこちらのサイトから音の出る広告が出ると元のゲーム・動画の阻害になってコンテンツの価値をを損ないます。
音の出る広告やコンテンツをこのサイトに残すなら、そういった併用して使われるページの情報は音の出ない、元のコンテンツを阻害しない同業他社のサイトに移植されるべきです。
:RenameLogはローテションで直近50回まで記録するようにしました。この度はご不便をおかけし、誠に申し訳ございません。
動画広告の音声は、広告内の音声操作ボタンでミュートすることが可能です。
Chromeをご利用の場合、ブラウザのタブ上で右クリックし、「サイトをミュート」を選択することもできます。
また、当サービスでは、積極的にWIKIに参加するユーザー様には、広告の表示頻度を抑えるよう努めております。
以下の行動に基づいて、広告表示の調整を行っています。
なお、当サービスはアカウント制ではないため、ブラウザのCookieやローカルストレージ、セッションストレージの読み書きが制限されている場合や、これらがリセットされた場合、ユーザー様の識別が難しくなることがございます。
あらかじめご了承ください。
広告について
https://wikiwiki.jp/pp/aboutad
利用規約
https://wikiwiki.jp/pp/policies
広告の露出頻度や挙動については、今後も柔軟に調整を進めてまいります。
引き続きご理解とご協力をお願いいたします。
同意です
音出る系の広告はできれば見直していただきたいです
ご指摘のとおり、:RenameLogをリネームしましたところ解決しました。
ご回答ありがとうございました。
上記の不具合を修正いたしました。
ご連絡およびご確認、ありがとうございます。
:RenameLogの容量がいっぱいのようです。お手数をおかけしますが、削除してから再度お試しください。
https://wikiwiki.jp/control/:RenameLog
:RenameLogのローテーションを検討いたします。修正していただいた内容を確認いたしました。ご対応ありがとうございます。
「ページ名 - Wiki名」となるように修正いたしました。
（ページ名は
TITLE:が優先になります）また、
sns_share_imageおよびdescriptionプラグインを使用して、ページ単位でシェア情報を変更できるようにしました。
ただし、荒らし行為に利用されるリスクがあるため、管理者の許可が必要です。
許可するには、「コントロールパネル」→「各種設定」→「SNSシェア情報の変更を許可」をONにしてください。
現在の設定情報は、ページ右上のシェアアイコンからプレビューできます。
SNSシェア情報の変更のサンプルはこちらです。
上記の挙動を調整いたしました。
上記の不具合を修正いたしました。
ご連絡およびご確認、ありがとうございます。
上記の不具合を修正いたしました。
ご連絡およびご確認、ありがとうございます。
上記の不具合を修正いたしました。
ご連絡およびご確認、ありがとうございます。
上記の不具合を修正いたしました。
構文ハイライト機能は現在、試験運用中です。
そのため、一部の環境で正常に動作しない場合がございますので、
その際は機能をOFFにして編集していただけると幸いです。
ご不便をおかけして申し訳ございません。
上記の不具合を修正いたしました。
ご連絡およびご確認、ありがとうございます。
表題の不具合の修正を確認しました。ご対応いただきありがとうございました。
私も同じ症状が発生しています。
削除テキストハイライト自体が一定行を境に効かなくなっているようにも見えます
おそらく無関係のwikiで、運用方法も異なる(と、思われる)箇所でも同様の症状が発生したため、グローバルな問題であると思われます。
此方では80行程度で症状が発生しております。
一部のユーザーが想定以上の異常な数のタグ付けしていることによるサーバー高負荷により、タグリスト表示に制約を設けられたものと推察しています。タグリスト表示の上限数について公式より明らかにしてもらいたいです。
無制限に表示できていたことを運営からのアナウンスなしに仕様変更されては、ユーザーとしてプラグイン利用や今後の編集に不安が残ります。tablescrollプラグインの一件もそうですが、今までできていたことに制約を設けてお知らせすることなく仕様変更することはwiki管理者や編集だけするユーザー達を困惑させます。運営と一定の信頼関係を保つためにも、wikiの管理方法を見直させるような仕様変更はX公式アカウントなどでお知らせしてほしいです。なぜなら、当方もinclude系プラグインの使用上限についてで文中に「積極的にecacheプラグインを使用してください。」と記載があり、全ページに導入していました。現在も推奨する文言は訂正や削除されていませんが、非推奨を案内する公式アナウンスで知ってプラグインを無効化させることができました。運営さんにはエラー表示されるから、公式のアナウンスが必要ないと考えないで欲しいです。
#contentsxを使ってください。
タグを使いすぎなのが悪いと言われるとそのとおりなのですが、
・タグ数の上限がない想定で運用していたものを、今から上限を超えないように運用を変えるのは難しい
・ソシャゲのwikiでキャラクターの能力に合わせてタグを付与しており、必要性があるタグなので削減が難しい
・見直しをするとして、どこまで減らせばいいか明示されていない
・全タグのリスト表示自体が機能していないだけで、タグ自体は機能している
という事情から、できればタグのリスト表示自体を前の仕様に戻していただいたり(時期的に>> 3の仕様変更が行われるまでは読み込めていました)、リスト表示を1〜50件のような分割表示可能にしていただいたりとwikiwiki側で対応いただきたいです。
埋め込み型の天気予報動画に擬態した広告で、リンク先はgliacloudというサービスでした
スポンサー表記がありません
同じ書式設定の二つの表をincludeなどで取得及び結合してだそうとしても取得元の時点で書式通りではなく表示優先になり同じ書式設定にも関わらず表がずれてしまいます(要は同じ書式にしても記載内容によって表幅が自動調整されてしまうため二つの表をincludeした際にずれてしまう)
対応も必要かもですがそれぞれのwikiでタグの見直しもやった方がいいのではと思います
私が利用するwikiでも
Too many tags to display. (1129)
となってしまい、taglistの利用ができない状況になりました。
また、tagcloudも最大100件までしか表示できないようになってしまっています。
>> 1で示されている上限を定める形式も機能しません。
ご対応いただきたいです。
質問です。
画像を中心として、メンバー間あるいはゲストの方とのコミュニケーションを図るような使い方をしたいと考えています。
この場合、最大画像サイズおよび一枚あたり容量の制限、および使用できる最大容量または枚数はどのようになっているでしょうか。
今朝、確認してみたら「ページタイトル名 - Wiki名」に仕様変更されていました。ご対応いただき、どうもありがとうございます。
エラーメッセージが
Too many tags to display. (54507)
になりました。
言ってることがよくわかりませんが
おそらく現実的な対応は以下のように元のページの表内に、予め複数の書式定義行を仕込んでおいて、includexで呼び出すときにその書式定義を切り替えることです。
以下の例では元のページでは設定1の書式で表示されますが、
includexで呼び出すときは設定1が除外されて設定2の書式で表示されます。
>> 1
エラーメッセージを見ると
Warning: There are over 55,224 tags, which requires approximately 30MB of transfer data to display.
This is an unintended use of tags.
なので容量オーバーを起こしていますね…
新たなキャッシュプラグインで同様に実装されないとecacheを使わざる追えないケースとして残るのが懸念ですね
その機能はすでにあります。
ただ上記サイトで確認しようとしましたが上手く機能しません。
行数が多すぎるか、負荷が高すぎるか、異常な文字列が含まれるなどが考えられます。
iOS Safariで、特定のWikiのブックマークアイコンが
他のWikiのアイコンにも反映されてしまう問題についてご案内いたします。
この問題は、iOS Safariの仕様に関連している可能性があります。
（Safariのスタートページに表示されるアイコンは、独自のアルゴリズムで取得されるため、
正しくアイコンが反映されないことがあるようです）
現時点で具体的な解決策は確認されておりません。
Appleにフィードバックを送ることで、将来的な改善が期待できるかもしれません。
ご理解とご協力のほどよろしくお願いいたします。🙇♂️
原神wikiでも同様の現象が起きています。
wikiwikiがfaviconの設定を推奨しているので修正してほしいですし、外部的な要因でwikiwikiの問題でないのであればそのように公表して欲しいです。
同意します。
出来ればnavfoldのように切り替えて表示したタブが記憶されていると嬉しいです。
navfoldはfoldよりも折りたたみされた内容との行間が開くのが不恰好だと思います。
foldと同じ行間になると嬉しいです。
新たなキャッシュプラグインを開発中とのことなので、まだ古い仕様が残っている状態なのだと思います
https://zawazawa.jp/wikiwiki/topic/8
https://x.com/WIKIWIKI_Japan/status/1797575512816234881
機能には満足していますが、開閉ボタンの見た目が普通のfoldと同じだと統一感があってもっと良いと思います