manut raised a blocking issue regarding the upgrade to Discourse 2026.7.x, specifically concerning the post-event-builder plugin. The user requires the “advanced” event form to be the default and only option, preventing users from switching to the “compact” form, as their custom fields must be filled for all events. manut suggested potential solutions like site settings for the default editor or a plugin outlet to replace the compact form entirely.
After attempting a plugin outlet approach, manut found it incomplete because it couldn’t override the switch button or the editable preview mode. Consequently, they proposed a cleaner solution involving admin options: default_editor (compact or advanced) and allow_editor_switch (boolean). martin confirmed the goal is to force Advanced mode and suggested implementing a value transformer for initialScreen in the PostEventBuilder component to always set it to advanced. martin offered to review a core PR for this transformer.
manut detailed the current inconsistent behavior of the event form across different editors (Markdown with/without preview, Rich Text) and expressed hesitation about the complexity of admin parameters versus finding the correct component for a plugin outlet. chapoi asked for clarification on screenshot attachment issues, which manut attributed to a browser extension blocking AWS referrers, subsequently providing screenshots illustrating the different form states.
We created a plugin redefining the post-event-builder plugin outlet: every event created on our instance needs their custom fields filled, and our form completes the proposed values with data from an external source.
We only use ESR versions of Discourse, so everything was fine on 2026.1.x, and I’m now in the process of upgrading to 2026.7.x, so I’m discovering the new form and the advanced one now.
As our users must fill all the custom fields, we’d like to use the “advanced” form instead of the compact one, with no option to switch forms.
I initially thought about one site setting to use the advanced form by default (and disabling the possibility to switch to the compact one, as everything is in the advanced form anyway), or two settings (use the advanced form by default, prevent switching forms). A plugin outlet to replace the compact form could be good too, as long as it includes the switch to advanced form so we can get rid of it.
The new behavior is really blocking us in the upgrade process, and we can’t stay on the old, unmaintained 2026.1.x.
If I create a PR with a new plugin outlet, is there any chance for it to be accepted and backported to the next 2026.7.x or should we find another way to fix this blocking issue ?
I added a new plugin outlet to override the default “compact” form, but i’m not really happy with the change.
The button to access the “advanced” form cannot be overridden with the outlet, and the “editable preview” in the editor is still using the “compact mode”, which may not fit with the overridden form (at least, not in our case).
I’m starting to think that the cleaner solution would be to add an option in the plugin admin, to chose the form behavior. I see at least 2 options:
default_editor: chose “compact” (default) or “advanced”
allow_editor_switch: will hide the buttons to switch the editor
I’m still digging in the implications, but feedback on the general idea is appreciated
If so then in the PostEventBuilder component, I’d make a value transformer for initialScreen,a getter that reads this.args.model.initialScreen then is able to override it with the value transformer. So you’d always set initialScreen to advanced via the value transformer.
Happy to review a PR for core from you for the value transformer, I assume you have a custom theme you can hook this to already.
I cannot attach screenshots, so i’ll try to describe the current behavior and what I want to achieve
When using the Markdown editor:
if preview is enabled, the event form shows in the preview (not wrapped in post-event-builder), with a button on the top-right of the preview to switch to advanced mode
if preview is disabled, the event form shows up in a modal, wrapped in post-event-builder (the use case you mentioned) with a button in the modal footer to switch to advanced mode
When using the rich text editor, the event form is embedded in the post form; this seems to be the same block as the one used in preview.
What I need is to have only one editor, ours.
As the plugin is bundled in the core, I’m aware that any change will impact everyone using the plugin, so the changes should be minimal
I’m still not comfortable enough with EmberJS to understand how everything is wired together, so any change takes time and I often get a result only to see that there might be another, cleaner way to do the things.
Maybe the last approach consisting of new admin parameters is overkill and I just don’t have found The™ component in which to add a plugin outlet so everything is changed…
