Ethsim2 requested an admin setting to configure the default view for the /upcoming-events page, noting that many communities prefer a weekly view for timetables and shift patterns. The current default is the Month view, which requires users to switch views repeatedly. While a Theme Component could force a redirect, it is considered hacky and lacks granular control.
Ethsim2 initially submitted a pull request (#35861) to hardcode the default to Week. Ethsim2 clarified that this should be a proper site setting rather than an app.yml variable, as Ember requires declared settings. manuel suggested using generic URLs for sidebar links, but Ethsim2 argued for a centralized admin setting to manage user preferences globally.
Following a request from j.jaffeux, yuriy implemented the feature in pull request #36014. The new setting, Calendar upcoming events default view, allows admins to set the default to Month, Week, or Year.
Ethsim2 suggested a follow-up enhancement: allowing users to override the site default with a personal preference, establishing a precedence of explicit URL > user preference > site default. lindsey closed the topic as the original request is complete but offered to move the follow-up suggestion to a new feature topic if desired.
For sites that rely heavily on the Upcoming Events page, many community members prefer a weekly view by default. Currently, /upcoming-events always loads the Month view first, even if a user prefers Week (or Day, Year).
Feature request
Add a simple admin site setting to configure which view /upcoming-events loads by default:
this is to hard code the default to Week, rather than Month. It’s simple, but not yet a site-setting - it lays the foundation for the more acceptable improvement
Ember code doesn’t read arbitrary env vars. Discourse only exposes declared site settings (config/settings.yml, client: true) to the client. That’s why you either:
add the setting in core (then set via app.yml), or
avoid settings and use a theme component redirect.
i’m “used to” upcoming events button that can’t be configured on the sidebar.
Furthermore, an admin setting could set the default of a user preference. Rather than all users being forced to set-up their own sidebar button/section, or accept a global section.
I hope i have changed the correct code in my PR, that we simply need to toggle what i changed based on a setting?…
Thanks again for getting this landed - the admin default view setting is a big UX win
Now that this exists, it might be worth considering a small follow-up enhancement: allowing users to optionally override the site default with a personal preference, while keeping the admin setting as the fallback.
That would give sites a strong default identity (Week vs Month), but still let individuals choose what works best for them - similar to how most calendar apps behave. A simple precedence like
explicit URL → user preference → site default
would keep behaviour predictable and backwards-compatible.
Not suggesting this replaces the current setting - just a possible next step if you think it fits the broader UX direction.