Discourse Calendarをfullcalendar 6を使用するように更新

Discourse カレンダーは本日、大幅なアップデート を受けました :rocket:。アップデートの核となるのは、fullcalendar 4 から fullcalendar 6 への移行であり、UI が更新されます。

また、この機会に以下の変更も行いました。

  • イベント予定ページにクリーンな URL を導入しました。例: /upcoming-events/day/2025/8/2

  • イベントをクリックすると、イベントのプレビューが表示されるようになりました。

  • パフォーマンスが大幅に向上し、多数のイベントを扱えるようになりました。

  • fullcalendar が提供する CSS 変数に依存するようになったため、カレンダーはテーマに合わせてすぐに動作するはずです。

「いいね!」 29

素晴らしい、素晴らしい仕事、どうもありがとう :heart_eyes:

「いいね!」 2

モバイルの部分で(年)をデフォルトのリストにすることは可能ですか?
もしそうでなければ、またしても素晴らしいです!!

作業ありがとうございます!これらのURLは米国/欧州の両方の年月日形式に対応していますか?また、同じ日に複数のイベントがある場合はどうなりますか?

申し訳ありませんが、現時点ではURL形式は1つのみサポートします。

これにより、この日/月/年のすべてのイベントを確認できなくなるわけではありません。イベントに直接リンクしたい場合は、イベント投稿にリンクしてください。

「いいね!」 2

確かに、イベントへの直接リンクを共有でき、複数のURL形式を提供するのは簡単なことではありません。フルカレンダー6の新しい機能へのアップデートを提供していただいていることに、すでに感謝しています!

「いいね!」 1

アップグレード以降、トピックの投稿時間(正しい)とカレンダー表示時間(1時間早い)の間に1時間のずれが一部のイベントで発生していますが、すべてではありません。

これは、ローカルタイムゾーンが夏時間に切り替わった後に解決されるか、夏時間開始後に他のイベント(逆方向)を狂わせます。ただし、すべてのイベントが影響を受けるわけではありません。これは既知の問題ですか?修正は予定されていますか?

#バグ

素晴らしいですね!カレンダーが次のレベルに引き上げられます。

(デフォルトの)月表示では、イベントタイトルのテキストが折り返されないことに気づきました。これは意図したものでしょうか?

デスクトップカレンダー

月表示では、しばしば役立つ情報が満載されているこれらのタイトル全体をデスクトップで(おそらくホバー時に)見ることができれば、素晴らしいと思います。もちろん、そうなるとイベントが欲張りになって、より多くのスペースを占めることになるかもしれません。

モバイルカレンダー

また、モバイルでは、時間以外が表示されることはまれです。タップすれば詳細が見やすいので、それほど問題ではないと思います。

アジェンダ表示?

最後に、イベントを表現する一般的な方法であるアジェンダ表示があれば、非常に役立つでしょう。カレンダーでそれが可能でしょうか?

Right Sidebar Blocks を使用すれば可能であることは知っていますが、それは別の文脈です。

「いいね!」 2

はい、本日中に修正いたします。確定的な再現手順をお待ちしております。ありがとうございます。

「いいね!」 3

修正されるべき: FIX: removes support for include_expired param (#34582) · discourse/discourse@249ae00 · GitHub

「いいね!」 1

ちょっとした提案があります :sweat_smile:
今日の日付に移動する代わりに、次のイベントの日付に直接移動する方が良いのではないでしょうか?
ただのアイデアです! :innocent:

本日オープンする予定です。ユーザーを特定の日付にリンクする必要がある場合は、希望するリンクを次のように作成できます。/upcoming-events/day/2025/9/2

ありがとうございます!

ISO日付形式(MMとDDは2桁)で、YYYY/MM/DDのようにすることは可能でしょうか?

「いいね!」 3

Google の動向を主に追っています。

Screenshot 2025-08-28 at 15.47.18

ああ、なぜ彼らは基準に従うのだろうか、それが破られて他の人にさらに多くの仕事を生み出すことができるのに。:person_facepalming:

「いいね!」 2

/day/2025/09/01/day/2025/9/1 よりもはるかに優れている理由を理解するのに苦労しています。

ゼロを追加するとバーのスペースを占有するため、悪いとさえ言えると思います。

それはより良いというわけではありません。単に、Discourseの他の部分で日付がエンコードされている方法と、より標準化され、一貫性があるだけです。

逆に、現在実装されている方法はDiscourseのURLと一貫性があります(URLはオープンエンドの番号付けが必要です)。

したがって、これは哲学的な決定です。URLとの内部的な一貫性か、日付との内部的/外部的な一貫性か。それぞれに長所と短所があります。私は現在の実装を好みます。

もし私がその日付を書き始めたら、形式はmm/ddになります。なぜなら、それはほとんどどこでも標準だからです—アメリカ合衆国からの接続の場合を除き、彼らは先頭のゼロを削除し、単語を大文字で始めるでしょう😏。あるいは、スペースを数えるコーダーから—アメリカ人でさえmm/ddを読み、使用することができます。

したがって、それは筋力記憶の問題であり、世界のほとんどがISO形式を使用することに慣れており、どのソフトウェアやプラットフォームがどの形式を使用するかを覚えておくのが難しいという事実からです。それは常に誰かが失う質問の1つです—質問は、どのグループが最大かということです。

「いいね!」 2

ハッ!すみません、些細なことにこだわりたくありませんでした。純粋な数字は数値順に並べられ、先頭のゼロは月を正しい順序で表示します。

「いいね!」 3

現地時間の夏時間への変更前後に、繰り返しイベントの異常な動作が引き続き見られます。ホストプランを利用していますが、修正がプッシュされるのを待つだけでしょうか?