既存の機能だけで実現する手段はちょっと思いつきませんが、比較的軽微と思われる機能拡張で実現できる可能性があります。 cssboxプラグインが「overflow: scroll」を使えるようになれば、ツイートに限らず縦に長い様々なものを、小さなスペースに収めることができると思います。
ちなみに、このアイディアはここで既に提案されています。
twitter_timelineを廃止するとのことですが、 今後運営からの告知はhttps://z.wikiwiki.jp/wikiwiki/ が使われるという理解で良いのでしょうか。 できれば https://wikiwiki.jp/ トップ（例えば現在の「お知らせ」や「みんなが評価しているWIKI」の位置など）に、 最新の告知（1～数件分）を表示してもらえると助かります。
そのような趣旨であれば賛同します。 当方そのようなケースに遭遇しなかったため特に気に留めていませんでしたが、簡易的なものとはいえ、残存しないページを一覧に出力する仕組みというのはプラグインとしてあまりにお粗末なものに感じます。
その上で、一般の利用者に対し(具体的なカウント数は不要としても)アクセスランキングという形を提供することは価値があると思います。Googleアナリティクスで十分だという指摘もありますが、あくまで管理者に重きをおいたサービスで、当然、一般の利用者向けにGoogleアナリティクスのデータを手動でWikiに反映するのは不毛な話です。
popularは統計としてどの様に役立つのでしょうか。 ページ構成や閲覧者次第でページ閲覧者ののべ人数など如何様にもなりませんか。 ページを編集する立場として考えた場合でもcounterの値のみが役立つケースはごく稀であり、その様なページ作りをしたければGoogleアナリティクス等のツールを使わない理由は考えられません。 仮に使えない理由が存在したとしてBAN等の限定的な話ではありませんか。
削除されたページにおいてcounterの数は原則増えない事を前提とすれば長期的に運営していくにつれ削除されたページはpopularから消えてゆく事でしょう。 短期的であればtodayオプションが存在しますから必要性に疑問が残ります。 直前の投稿内容を鑑みてもpopularにおいてweeklyやmonthlyの表示を行えれば十分ではありませんか。
私やはやしさんのように他社サービスであるGoogleアナリティクスを扱い、全員が使いこなせるのであれば必要ないと思います。
プラグインは誰でも気軽にその場で即座に使えます。そのようなWiki内サービスは管理者の手助けツールとして役立ちます。今回、私自身が困ったときに他者が管理するWikiでも使えそうと判断して要望を出しています。
今回の件で言えば、①Googleアナリティクスの利用が何らかの事情で使えていない人でも困らないような調整をしてほしい。②管理者でなくても統計を確認できるプラグインは重宝する。例え、管理者が不在となったWikiでも後継者にとって、このプラグインはページ作りに役立つと考えられます。
また、本件の要望よりも別のことを優先してほしいという意見ですが、それは要望トピックを出された方や賛同意見を出した方は皆、そう思われているのではないでしょうか。どんなに便利で使い勝手の良さそうな要望で多くの意見が飛び交っても、採用を見送りされたりしています。開発の進捗フェーズの状況で運営さんにメンションされていても都合上、未回答のままであるトピックもあります。運営側は実装後のコストの見積りや他サービス・プラグインへの影響の有無、セキュリティ面などを全てクリアできると判断してから要望を一つひとつ叶えてくれていると思います。
話の流れで本件よりも他の要望に目を向けてほしいと暗に示していますが、私は気落ちしました。私だけでなく、>> 1さんや同じく必要とする利用者には感じ悪く思います。
おっしゃられている通り、現存しないページが多くてフィルターに負荷がかかるのでどうにか軽減したいこととプラグインが『...loading』状態のまま機能しなくなることを防げるのであれば、リセット機能でなくても手段は問いません。
統計的な情報が必要であればGoogleアナリティクスを参照するので、ここを変えるよりもっと別のことを優先してほしい、というのが自分の意見です。
リクエスト広場のトップページには様々な注意書きがありますが、そのなかに「なぜそれが必要か理由を書く」とあります。 この点が少し欠けているのではないでしょうか。
個人的にはカウンターのリセット機能は不要だと思っています。本題は「削除したページをpopularから除外したい」ということであり、wikiwiki側でどのようなデータ管理となっているかは存じ上げませんが、ページ削除フラグのようなものがあればそれを目印にフィルターすればよいのではないでしょうか。
ご回答ありがとうございます。
そのため、「popular の通算リセット機能」を設けることは、実質的に 管理者が counter をリセットできる機能 と同等の意味合いを持ちます。
管理者が counter をリセットできる機能の実装を希望します。運営側はWiki発足当初からのカウントと利用者側が見れるカウントの2つを用意するなど、運営方針に影響でない形が望ましいです。機能追加していただけるならコントロールパネルにて単一ページを指定してカウントをリセットができたら助かります。システム負荷を考慮の上でテスト/*などのサブディレクトリ対応や複数ページ(hoge1/テスト、hoge2/testなどの指定)を同時にリセットできる機能があれば、さらに嬉しいです。システム的に実際の挙動はタスク同時ではなく、一つひとつ行って遅延処理するなどの対応イメージです。
Wiki利用者(Wiki管理者を含む)は現存しないページや通算カウントを一旦、リセットしたいページがあります。現状は除外しないと現存しないページも表示されて大変、不便です。
さらに、多数のフィルタをかけた場合は負荷が大きくなり、結果として「対象外とするページが多すぎると、文字数が増えてプラグインが『...loading』状態のまま機能しなくなる」ことがあります。
運営側も認識している通りで長く続けられているWikiほど、途中で削除されたページや不要のページも多くなるので当Wikiように除外ページの記述内容がどんどん増えていき、システム負荷も増えて使い勝手が悪くなっていきます。最終的にはカウント機能しなくなるほどに文字数も多くなります。実際に当Wikiは何度も限界に達して、その度に記述内容を見直しています。(①hoge/1、hoge/2などのページ→hoge/.*②二度目の限界後にhoge、hoge/*→hoge(/.*)? )しかし、https://wikiwiki.jp/WIKIWIKI ID/のようなWIKIWIKI ID直下のページはそれぞれ、指定する必要があるのでこれ以上に増えた場合は現状、回避手段はなく見直しすることはできません。
*
https://wikiwiki.jp/WIKIWIKI ID/
ご検討のほど、よろしくお願いいたします。
運営の意図(試験運用後置き換える予定など)は分かりませんが、個人的にも後継ではないと思っています。 工夫の余地に関しても理解しているつもりですが、問題はそれに関する手間です。 ecache利用時も、それの対応で時間を割くハメになったので他の編集者に利用を推奨しようとは思えません。 また、現状把握できている以外の他のプラグインで問題が起こるのかも不明なため、各々で調査する必要性が出てきます。
0.5という表記に関しては>> 1さんに返信後、そちらの表現をお借りして追記しました。 技術的な仕様が分からないため、詳細な説明を記載できず申し訳ありません。 自分が言うのも何ですが、意図や仕様が不明な内容に関して議論や断定をするのは不毛な気もします。 実際に利用して仕様の関係で諦めるのが無難と感じたため、改善を求めて要望しています。
@wikiwiki 利用するタイミングが適切か分かりませんが、改善可能であるか、改修予定があるかなどお答えいただけると助かります。
返信が遅くなり申し訳ありません。
popular プラグインのランキングは、各ページに記録されている counter の数から算出しています。 そのため、「popular の通算リセット機能」を設けることは、実質的に 管理者が counter をリセットできる機能 と同等の意味合いを持ちます。
また、ページの削除については一時的なものか恒久的なものか判断できないため、自動でランキングから除外することは難しい状況です。
これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わるため、機能追加の是非については 引き続き議論が必要 になると考えています。
運営からのお知らせは、内容や対象となる方に合わせて、掲載する場所を分けています。 たとえば、速報的なお知らせは公式Xに載せ、やり取りが必要な場合はzawazawaを使うことがあります。
事情により配信先を分けている点はご理解いただければと思います。
また、重要なお知らせは、Xタイムラインでの掲載をやめ、今後はトップページに直接載せることも検討しています。
前提として、lazy_foldはfoldの後継ではありません。 運営の説明に記載の"負荷軽減用プラグインは「おまじない」ではありません"という一文からも分かるかと思いますが、活用するのであれば、仕様を把握した上で見定める必要があります。 編集者・閲覧者の間で、負荷軽減と使用感を天秤にかけてどちらを使用するか考えなければならないでしょう。 よく分かっていない編集者については、コメントアウト等目に触れる箇所にfoldを選択した理由を記載するなど、工夫の余地があるかと思います。
ragさんの仰る0.5という挙動が具体性に欠けているようにも思います。 >> 1さんの仰るような仕様だとしても、ragさんの仰る"表示処理？が完全に終了する前に開いても内容を表示する"という要望は叶いません。 要望を聞く限りでは負荷軽減をあきらめた上でfoldを使用すればよろしいでしょう。
すみません、技術的な仕様は知らず都合が悪いかどうかすら分かりませんでした。 デフォルト動作にしてほしいとは思っておらず、オプション化に関しては大賛成です。 例えば、極力使用感を損なわずに負荷を軽減したいMenuBarに利用すれば効果は大きいと思います(必ず表示されるページのため)。 利用しにくい仕様のせいで利用されなければ効果が無いのと同義ではないでしょうか。
ご対応ありがとうございました！
@wikiwikiこちらの件、私もお待ちしております マニュアルがきちんと整備されていればWIKIWIKIへの信頼感と編集意欲が高まり、ゆくゆくはコミュニティ全体の活性化に繋がると思います。
Wikiはブログと異なり、複数人での編集が前提のシステムなので、 投稿内容の事前予約のようなことはできません。 常に誰かが行った最終更新に対して加筆・修正という形になります。
要望していた機能が実装されたため、解決済タグを付けました。
対応ありがとうございました。
上記の不具合を修正しました。 ご迷惑をおかけして申し訳ありません。
zrecent の反映には少し時間差が生じますが、 仕様によるものですので、あらかじめご理解いただければ幸いです。
ご連絡ありがとうございます。 対応しておりますので、今しばらくお待ちください。
Googleアナリティクスから確認可能なので、コントロールパネルに追加する意義はないかと思います。
不具合ではなく、Xの仕様変更によるものなので、 ブラウザでXへのログインを維持すれば、引き続き見れると思います。 （はやし氏のキャッシュの影響という推測はたぶん当たっています）
自分はXを利用していないため、 しばらく前からXのタイムラインは閲覧不可になっています。 （添付された画像と同じ状況。クリックすれば見れますが、 時系列順に並ばずソートもできないため、事実上使えない）
そのためこちらの要望に賛同しているのですが、 メンションが送られているにも拘らず、運営の回答無視が続いていて、 ちょっとイラっと来ているところです。
TwitterTimelineプラグインを使用したタイムラインの埋め込みは、かなり前からそのような動きになっています。 数日前までタイムラインが見えていた、とのことですが、それはキャッシュの影響でそう見えていただけかもしれません。
原因ですがwikiwiki側の障害ではなく、X（旧Twitter）側に問題があるようです。 どこのサイトでも埋め込みタイムラインが表示されなくなっており、X側に障害が起きているか、または意図的にタイムラインの提供が中断されている、と見るべき状況です。 Xの有料アカウントにログインしているユーザーだけ、埋め込みタイムラインを閲覧できる、という説もあるようですが、実態は私には分かりません。
@wikiwikiAVIF形式の画像について、既にメジャーな形式となっており、ほぼ全てのブラウザが対応していることから、AVIF画像への対応が適切だと考えています。 AVIF形式の画像への対応についての検討に関する2025年現在の状況、及び今後の対応への是非について、運営の見解をお聞きしたいです。
それは当然の動作ではないでしょうか？
0か1ではなく0.5（テキストデータだけ先行読込、HTML組立は開いたときにやる）を求めるのであれば、デフォルト動作変更は反対です。負荷軽減が薄れます。 どうしても、というのであればオプション化は反対しませんが、需要があるかは疑問符です。
素晴らしい要望です。 アンカーの名前に仮名や漢字が使えるようになって、さらにアンカーを自分で書かなかったときに自動生成される名前が見出しの名前と同じになったら、すごく便利だと思います。
これまでの意見を簡単にまとめたいと思います：
議論がある程度終わりましたので、運営からのコメントをお願いします。@wikiwiki
運営に動いてほしい という要望ということ？ であればこれ以上議論しようがないのでは？
公式のマニュアルをユーザに編集させるのは非現実的すぎるので、他の方の意見にあるように 引き続きマニュアル整備を要望し続けるか、有志で非公式プラグインマニュアルwikiを立ち上げるのが妥当かと思います。
主は「運営ができなければユーザー側で手伝いたい」とは一言も言っていないのですり替わってはいますね 自分たちでwikiを作って参加するのは>> 9の通り自由なので、ここでは>> 5のように元々あるさんぷるwikiを一般にも編集できるように要望する方がいいかと
何がすりかわったのかよくわかりませんが、マニュアルを整備してほしい→運営でできないのであればユーザが手伝います という話ですよね？
関連性があっても、話題のすり替えはあまり好ましくないです。 （木主の要望は、プラグインマニュアルの再整備・内容の充実です）
そもそも「プラグインのWikiを作る」ことは（18歳以上なら）誰にでもできますので、 運営に要望するようなことではないです。 自由に作ればいいでしょう。
認証コードを送って認証完了のメッセージが出たのに、いざ書き込もうとすると「認証のない書き込みは制限されています」だとよ。何だよこれ
余裕がないからとかでしたら開放して有志での更新もありなのかなと思います
こちらでは、twitter_tweetプラグインが何の問題もなく使えています。 特定のポストを表示させようとしたときや、特定の他のプラグインと組み合わせて使ったときにだけ、起こる問題なのかもしれません。
具体的にどこのwikiのどのページに、どういったソースを書いて問題が起きたのかを示したほうが、対処が早くなる可能性があります。
同じ要望は過去にもありましたが、 https://zawazawa.jp/wikiwiki-request/topic/69 放置されたまま3年半近く経っていますので、 何らかの理由により、やるつもりがないのだと思われます。
csvとしてダウンロードできる機能は便利なのですが、荒らしの対応にあたっては手間が掛かるのは変わらず、ブラウザから確認できた方が親切です。 実際にあった例として、荒らし行為(似たような漢字に置き換える、URLの変更等)が発覚したあと、当日や直近数日のログから確認と復旧を行ったものの、実際は期間を空けて(数週間～)荒らし行為が行われており、復旧に時間がかかりました。このような場合、ブラウザ側で期間指定をして当該ユーザーの編集行為を絞り込めればより早く復旧できた可能性もあります。 こうした理由から、かつてのDiifnaのように一定期間は日付を跨いだ検索を実装頂きたく思います。
既存の機能だけで実現する手段はちょっと思いつきませんが、比較的軽微と思われる機能拡張で実現できる可能性があります。
cssboxプラグインが「overflow: scroll」を使えるようになれば、ツイートに限らず縦に長い様々なものを、小さなスペースに収めることができると思います。
ちなみに、このアイディアはここで既に提案されています。
twitter_timelineを廃止するとのことですが、
今後運営からの告知はhttps://z.wikiwiki.jp/wikiwiki/ が使われるという理解で良いのでしょうか。
できれば https://wikiwiki.jp/ トップ（例えば現在の「お知らせ」や「みんなが評価しているWIKI」の位置など）に、
最新の告知（1～数件分）を表示してもらえると助かります。
そのような趣旨であれば賛同します。
当方そのようなケースに遭遇しなかったため特に気に留めていませんでしたが、簡易的なものとはいえ、残存しないページを一覧に出力する仕組みというのはプラグインとしてあまりにお粗末なものに感じます。
その上で、一般の利用者に対し(具体的なカウント数は不要としても)アクセスランキングという形を提供することは価値があると思います。Googleアナリティクスで十分だという指摘もありますが、あくまで管理者に重きをおいたサービスで、当然、一般の利用者向けにGoogleアナリティクスのデータを手動でWikiに反映するのは不毛な話です。
popularは統計としてどの様に役立つのでしょうか。
ページ構成や閲覧者次第でページ閲覧者ののべ人数など如何様にもなりませんか。
ページを編集する立場として考えた場合でもcounterの値のみが役立つケースはごく稀であり、その様なページ作りをしたければGoogleアナリティクス等のツールを使わない理由は考えられません。
仮に使えない理由が存在したとしてBAN等の限定的な話ではありませんか。
削除されたページにおいてcounterの数は原則増えない事を前提とすれば長期的に運営していくにつれ削除されたページはpopularから消えてゆく事でしょう。
短期的であればtodayオプションが存在しますから必要性に疑問が残ります。
直前の投稿内容を鑑みてもpopularにおいてweeklyやmonthlyの表示を行えれば十分ではありませんか。
私やはやしさんのように他社サービスであるGoogleアナリティクスを扱い、全員が使いこなせるのであれば必要ないと思います。
プラグインは誰でも気軽にその場で即座に使えます。そのようなWiki内サービスは管理者の手助けツールとして役立ちます。今回、私自身が困ったときに他者が管理するWikiでも使えそうと判断して要望を出しています。
今回の件で言えば、①Googleアナリティクスの利用が何らかの事情で使えていない人でも困らないような調整をしてほしい。②管理者でなくても統計を確認できるプラグインは重宝する。例え、管理者が不在となったWikiでも後継者にとって、このプラグインはページ作りに役立つと考えられます。
また、本件の要望よりも別のことを優先してほしいという意見ですが、それは要望トピックを出された方や賛同意見を出した方は皆、そう思われているのではないでしょうか。どんなに便利で使い勝手の良さそうな要望で多くの意見が飛び交っても、採用を見送りされたりしています。開発の進捗フェーズの状況で運営さんにメンションされていても都合上、未回答のままであるトピックもあります。運営側は実装後のコストの見積りや他サービス・プラグインへの影響の有無、セキュリティ面などを全てクリアできると判断してから要望を一つひとつ叶えてくれていると思います。
話の流れで本件よりも他の要望に目を向けてほしいと暗に示していますが、私は気落ちしました。私だけでなく、>> 1さんや同じく必要とする利用者には感じ悪く思います。
おっしゃられている通り、現存しないページが多くてフィルターに負荷がかかるのでどうにか軽減したいこととプラグインが『...loading』状態のまま機能しなくなることを防げるのであれば、リセット機能でなくても手段は問いません。
統計的な情報が必要であればGoogleアナリティクスを参照するので、ここを変えるよりもっと別のことを優先してほしい、というのが自分の意見です。
リクエスト広場のトップページには様々な注意書きがありますが、そのなかに「なぜそれが必要か理由を書く」とあります。
この点が少し欠けているのではないでしょうか。
個人的にはカウンターのリセット機能は不要だと思っています。本題は「削除したページをpopularから除外したい」ということであり、wikiwiki側でどのようなデータ管理となっているかは存じ上げませんが、ページ削除フラグのようなものがあればそれを目印にフィルターすればよいのではないでしょうか。
ご回答ありがとうございます。
管理者が counter をリセットできる機能の実装を希望します。運営側はWiki発足当初からのカウントと利用者側が見れるカウントの2つを用意するなど、運営方針に影響でない形が望ましいです。機能追加していただけるならコントロールパネルにて単一ページを指定してカウントをリセットができたら助かります。システム負荷を考慮の上でテスト/*などのサブディレクトリ対応や複数ページ(hoge1/テスト、hoge2/testなどの指定)を同時にリセットできる機能があれば、さらに嬉しいです。システム的に実際の挙動はタスク同時ではなく、一つひとつ行って遅延処理するなどの対応イメージです。
Wiki利用者(Wiki管理者を含む)は現存しないページや通算カウントを一旦、リセットしたいページがあります。現状は除外しないと現存しないページも表示されて大変、不便です。
運営側も認識している通りで長く続けられているWikiほど、途中で削除されたページや不要のページも多くなるので当Wikiように除外ページの記述内容がどんどん増えていき、システム負荷も増えて使い勝手が悪くなっていきます。最終的にはカウント機能しなくなるほどに文字数も多くなります。実際に当Wikiは何度も限界に達して、その度に記述内容を見直しています。(①hoge/1、hoge/2などのページ→hoge/.
*②二度目の限界後にhoge、hoge/*→hoge(/.*)?)しかし、
https://wikiwiki.jp/WIKIWIKI ID/のようなWIKIWIKI ID直下のページはそれぞれ、指定する必要があるのでこれ以上に増えた場合は現状、回避手段はなく見直しすることはできません。ご検討のほど、よろしくお願いいたします。
運営の意図(試験運用後置き換える予定など)は分かりませんが、個人的にも後継ではないと思っています。
工夫の余地に関しても理解しているつもりですが、問題はそれに関する手間です。
ecache利用時も、それの対応で時間を割くハメになったので他の編集者に利用を推奨しようとは思えません。
また、現状把握できている以外の他のプラグインで問題が起こるのかも不明なため、各々で調査する必要性が出てきます。
0.5という表記に関しては>> 1さんに返信後、そちらの表現をお借りして追記しました。
技術的な仕様が分からないため、詳細な説明を記載できず申し訳ありません。
自分が言うのも何ですが、意図や仕様が不明な内容に関して議論や断定をするのは不毛な気もします。
実際に利用して仕様の関係で諦めるのが無難と感じたため、改善を求めて要望しています。
@wikiwiki
利用するタイミングが適切か分かりませんが、改善可能であるか、改修予定があるかなどお答えいただけると助かります。
返信が遅くなり申し訳ありません。
popular プラグインのランキングは、各ページに記録されている counter の数から算出しています。
そのため、「popular の通算リセット機能」を設けることは、実質的に 管理者が counter をリセットできる機能 と同等の意味合いを持ちます。
また、ページの削除については一時的なものか恒久的なものか判断できないため、自動でランキングから除外することは難しい状況です。
さらに、多数のフィルタをかけた場合は負荷が大きくなり、結果として「対象外とするページが多すぎると、文字数が増えてプラグインが『...loading』状態のまま機能しなくなる」ことがあります。
これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わるため、機能追加の是非については 引き続き議論が必要 になると考えています。
返信が遅くなり申し訳ありません。
運営からのお知らせは、内容や対象となる方に合わせて、掲載する場所を分けています。
たとえば、速報的なお知らせは公式Xに載せ、やり取りが必要な場合はzawazawaを使うことがあります。
事情により配信先を分けている点はご理解いただければと思います。
また、重要なお知らせは、Xタイムラインでの掲載をやめ、今後はトップページに直接載せることも検討しています。
前提として、lazy_foldはfoldの後継ではありません。
運営の説明に記載の"負荷軽減用プラグインは「おまじない」ではありません"という一文からも分かるかと思いますが、活用するのであれば、仕様を把握した上で見定める必要があります。
編集者・閲覧者の間で、負荷軽減と使用感を天秤にかけてどちらを使用するか考えなければならないでしょう。
よく分かっていない編集者については、コメントアウト等目に触れる箇所にfoldを選択した理由を記載するなど、工夫の余地があるかと思います。
ragさんの仰る0.5という挙動が具体性に欠けているようにも思います。
>> 1さんの仰るような仕様だとしても、ragさんの仰る"表示処理？が完全に終了する前に開いても内容を表示する"という要望は叶いません。
要望を聞く限りでは負荷軽減をあきらめた上でfoldを使用すればよろしいでしょう。
すみません、技術的な仕様は知らず都合が悪いかどうかすら分かりませんでした。
デフォルト動作にしてほしいとは思っておらず、オプション化に関しては大賛成です。
例えば、極力使用感を損なわずに負荷を軽減したいMenuBarに利用すれば効果は大きいと思います(必ず表示されるページのため)。
利用しにくい仕様のせいで利用されなければ効果が無いのと同義ではないでしょうか。
ご対応ありがとうございました！
@wikiwikiこちらの件、私もお待ちしております
マニュアルがきちんと整備されていればWIKIWIKIへの信頼感と編集意欲が高まり、ゆくゆくはコミュニティ全体の活性化に繋がると思います。
Wikiはブログと異なり、複数人での編集が前提のシステムなので、
投稿内容の事前予約のようなことはできません。
常に誰かが行った最終更新に対して加筆・修正という形になります。
要望していた機能が実装されたため、解決済タグを付けました。
対応ありがとうございました。
上記の不具合を修正しました。
ご迷惑をおかけして申し訳ありません。
zrecent の反映には少し時間差が生じますが、
仕様によるものですので、あらかじめご理解いただければ幸いです。
ご連絡ありがとうございます。
対応しておりますので、今しばらくお待ちください。
上記の不具合を修正しました。
ご迷惑をおかけして申し訳ありません。
ご連絡ありがとうございます。
対応しておりますので、今しばらくお待ちください。
Googleアナリティクスから確認可能なので、コントロールパネルに追加する意義はないかと思います。
不具合ではなく、Xの仕様変更によるものなので、
ブラウザでXへのログインを維持すれば、引き続き見れると思います。
（はやし氏のキャッシュの影響という推測はたぶん当たっています）
自分はXを利用していないため、
しばらく前からXのタイムラインは閲覧不可になっています。
（添付された画像と同じ状況。クリックすれば見れますが、
時系列順に並ばずソートもできないため、事実上使えない）
そのためこちらの要望に賛同しているのですが、
メンションが送られているにも拘らず、運営の回答無視が続いていて、
ちょっとイラっと来ているところです。
TwitterTimelineプラグインを使用したタイムラインの埋め込みは、かなり前からそのような動きになっています。
数日前までタイムラインが見えていた、とのことですが、それはキャッシュの影響でそう見えていただけかもしれません。
原因ですがwikiwiki側の障害ではなく、X（旧Twitter）側に問題があるようです。
どこのサイトでも埋め込みタイムラインが表示されなくなっており、X側に障害が起きているか、または意図的にタイムラインの提供が中断されている、と見るべき状況です。
Xの有料アカウントにログインしているユーザーだけ、埋め込みタイムラインを閲覧できる、という説もあるようですが、実態は私には分かりません。
@wikiwikiAVIF形式の画像について、既にメジャーな形式となっており、ほぼ全てのブラウザが対応していることから、AVIF画像への対応が適切だと考えています。
AVIF形式の画像への対応についての検討に関する2025年現在の状況、及び今後の対応への是非について、運営の見解をお聞きしたいです。
それは当然の動作ではないでしょうか？
0か1ではなく0.5（テキストデータだけ先行読込、HTML組立は開いたときにやる）を求めるのであれば、デフォルト動作変更は反対です。負荷軽減が薄れます。
どうしても、というのであればオプション化は反対しませんが、需要があるかは疑問符です。
素晴らしい要望です。
アンカーの名前に仮名や漢字が使えるようになって、さらにアンカーを自分で書かなかったときに自動生成される名前が見出しの名前と同じになったら、すごく便利だと思います。
これまでの意見を簡単にまとめたいと思います：
議論がある程度終わりましたので、運営からのコメントをお願いします。@wikiwiki
運営に動いてほしい という要望ということ？
であればこれ以上議論しようがないのでは？
公式のマニュアルをユーザに編集させるのは非現実的すぎるので、他の方の意見にあるように
引き続きマニュアル整備を要望し続けるか、有志で非公式プラグインマニュアルwikiを立ち上げるのが妥当かと思います。
主は「運営ができなければユーザー側で手伝いたい」とは一言も言っていないのですり替わってはいますね
自分たちでwikiを作って参加するのは>> 9の通り自由なので、ここでは>> 5のように元々あるさんぷるwikiを一般にも編集できるように要望する方がいいかと
何がすりかわったのかよくわかりませんが、マニュアルを整備してほしい→運営でできないのであればユーザが手伝います という話ですよね？
関連性があっても、話題のすり替えはあまり好ましくないです。
（木主の要望は、プラグインマニュアルの再整備・内容の充実です）
そもそも「プラグインのWikiを作る」ことは（18歳以上なら）誰にでもできますので、
運営に要望するようなことではないです。
自由に作ればいいでしょう。
認証コードを送って認証完了のメッセージが出たのに、いざ書き込もうとすると「認証のない書き込みは制限されています」だとよ。何だよこれ
余裕がないからとかでしたら開放して有志での更新もありなのかなと思います
こちらでは、twitter_tweetプラグインが何の問題もなく使えています。
特定のポストを表示させようとしたときや、特定の他のプラグインと組み合わせて使ったときにだけ、起こる問題なのかもしれません。
具体的にどこのwikiのどのページに、どういったソースを書いて問題が起きたのかを示したほうが、対処が早くなる可能性があります。
同じ要望は過去にもありましたが、
https://zawazawa.jp/wikiwiki-request/topic/69
放置されたまま3年半近く経っていますので、
何らかの理由により、やるつもりがないのだと思われます。
csvとしてダウンロードできる機能は便利なのですが、荒らしの対応にあたっては手間が掛かるのは変わらず、ブラウザから確認できた方が親切です。
実際にあった例として、荒らし行為(似たような漢字に置き換える、URLの変更等)が発覚したあと、当日や直近数日のログから確認と復旧を行ったものの、実際は期間を空けて(数週間～)荒らし行為が行われており、復旧に時間がかかりました。このような場合、ブラウザ側で期間指定をして当該ユーザーの編集行為を絞り込めればより早く復旧できた可能性もあります。
こうした理由から、かつてのDiifnaのように一定期間は日付を跨いだ検索を実装頂きたく思います。