Discourse Calendar обновлён для использования fullcalendar 6

Календарь Discourse получил значительное обновление сегодня :rocket:. Основой обновления является миграция с fullcalendar 4 на fullcalendar 6, что принесёт нам обновлённый интерфейс:

Мы также воспользовались этой возможностью, чтобы внести следующие изменения:

  • Чистые URL-адреса для страницы предстоящих событий, например: /upcoming-events/day/2025/8/2

  • Предварительный просмотр события в посте при клике на событие

  • Производительность значительно улучшена, и теперь возможно наличие большого количества событий.

  • Теперь мы полагаемся на CSS-переменные, предоставляемые fullcalendar, что должно обеспечить работу календаря с вашей темой из коробки.

30 лайков

Браво, отличная работа, большое спасибо :heart_eyes:

2 лайка

Небольшой вопрос: можно ли по умолчанию установить список (year) для мобильной версии?
В любом случае, ещё раз — супер!!

Спасибо за вашу работу! Поддерживаются ли в этих URL-адресах оба формата дат (США/ЕС)? И что произойдет, если в один день запланировано несколько событий?

Извините, но пока мы поддерживаем только один формат URL.

Это не мешает вам просматривать все события за этот день/месяц/год. Если вы хотите создать прямую ссылку на конкретное событие, используйте ссылку на пост события.

2 лайка

Действительно, прямую ссылку на событие можно поделиться, а предоставление нескольких форматов URL — непростая задача. Мы уже благодарны вам за то, что вы предоставляете нам это обновление для FullCalendar 6 с новыми функциями!

1 лайк

После обновления я наблюдаю случаи расхождения в 1 час между временем публикации темы (верное) и временем, отображаемым в календаре (на час раньше), по некоторым событиям, но не по всем.

Это либо исправляется после перехода нашего часового пояса на летнее время, либо, наоборот, вызывает сбой в отображении других событий после начала перехода на летнее время. Однако не все события затрагиваются. Это известная проблема? Есть ли в разработке исправление?

bug

Это блестяще! Это действительно выводит календарь на новый уровень.

Я заметил, что текст заголовков событий не переносится в (стандартном) виде «Месяц». Это сделано намеренно?

Календарь для настольных компьютеров

Было бы здорово видеть полные заголовки в виде «Месяц» на настольных компьютерах (возможно, при наведении), так как они часто содержат полезную информацию. Конечно, это означало бы, что события могли бы стать более «жадными» и занимать больше места.

Календарь для мобильных устройств

Кроме того, на мобильных устройствах редко видно что-то кроме времени. Думаю, это не так важно, так как легко нажать на событие, чтобы увидеть подробности.

Вид «Повестка дня»?

Наконец, было бы очень полезно иметь вид «Повестка дня», который является распространенным способом отображения событий. Возможно ли это реализовать через календарь?

Я знаю, что это можно сделать с помощью 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, то есть ГГГГ/ММ/ДД (две цифры для месяца и дня)?

3 лайка

В основном я слежу за тем, что делает Google:

Screenshot 2025-08-28 at 15.47.18

Ах, зачем им следовать стандартам, если можно их нарушить и наработать другим? :person_facepalming:

2 лайка

Не могу понять, почему /day/2025/09/01 намного лучше, чем /day/2025/9/1.

Я бы сказал, что добавление нулей только ухудшает ситуацию, так как это занимает больше места в адресной строке.

Это не лучше. Просто более стандартизировано и согласуется с тем, как даты кодируются в других частях Discourse.

С другой стороны, текущая реализация согласуется с URL-адресами Discourse (которые требуют нумерации без ограничений).

Таким образом, это философское решение: внутренняя согласованность с URL-адресами или внутренняя/внешняя согласованность с датами. У каждого варианта есть свои плюсы и минусы. Я предпочитаю текущую реализацию.

Если бы я начал писать эту дату, формат был бы мм/дд. Это стандарт практически повсюду — за исключением случаев, когда соединение из США, где они опускают ведущие нули и начинают слова с заглавных букв :smirking_face:. Или когда речь идет о программистах, считающих пробелы, ведь даже американцы умеют читать и использовать формат мм/дд.

Так что это вопрос мышечной памяти и факта, что большинство людей привыкли к формату ISO, и трудно запомнить, какое программное обеспечение и платформа используют какой формат. Это один из тех вопросов, где всегда кто-то проигрывает — вопрос лишь в том, какая группа больше.

2 лайка

Ха! Извините, я не хотел вдаваться в детали. Чистые числа сортируются по числовому значению, а ведущие нули обеспечивают правильный порядок отображения месяцев и дней.

3 лайка

Я всё ещё наблюдаю некорректное поведение повторяющихся событий до и после перехода на летнее время. Мы находимся на хостинг-плане, так что это просто вопрос ожидания, пока исправление будет внедрено?