J’ai cloné ce TC dans mon dépôt GitHub à l’adresse GitHub - denvergeeks/DiscourseComposerButtonBonanza et j’y ai appliqué des correctifs pour ces erreurs [car l’accès au service Codeberg.org ne semblait pas fonctionner pour le forking.]
Voici le journal des commits de mes modifications :
committed 09:18PM - 27 Nov 25 UTC
This change refactors the ComposerButtonBonanza theme component initializer to c… omply with the discourse.static-viewport-initialization deprecation warning, while preserving the existing behavior of custom composer buttons.
Previously, the theme accessed site.desktopView (and implicitly site.mobileView) during static initialization when parsing the layout setting. Discourse now considers this access pattern unsafe because viewport state can change after initialization (for example, due to window resize or device rotation). Accessing viewport-dependent properties at that time can lead to inconsistent behavior and triggers the deprecation warning.
This commit addresses the issue by making layout parsing view-agnostic and deferring all mobile/desktop decisions to a runtime callback that executes during composer toolbar creation.
Key changes:
Stop accessing site.desktopView during initialization:
Removed the lookup of the site service and any mobile/desktop checks from the layout parsing path.
parseLayout no longer inspects viewport state and does not depend on site.mobileView or site.desktopView.
Refactor parseLayout to return an abstract, view-agnostic structure:
parseLayoutEntry remains responsible for interpreting each layout entry and determining allowDesktop / allowMobile flags based on the X/M/D prefix.
parseLayout now:
Validates that each referenced button exists in BUTTONS.
Populates TOGGLE_GROUPS based on the optional toggle-group name.
Stores toolbar entries as objects of the form:
{ section, buttonSpec, allowDesktop, allowMobile }
Stores gear-menu entries as:
{ buttonSpec, allowDesktop, allowMobile }
No viewport-dependent filtering is performed inside parseLayout; it only builds an abstract representation of the desired layout.
Defer viewport-dependent filtering to api.onToolbarCreate:
The initializer still:
Builds the BUTTONS lookup map from settings.buttons.
Locates any translation overrides for the current locale from settings.translations.
Initializes TOGGLE_GROUPS and calls parseLayout once at initialization time.
Sets up the i18nProperties container under I18n.translations[...]js.composer[CBBKEY].
A single api.onToolbarCreate callback is now responsible for:
Looking up the site service at render time.
Computing isDesktop from site.desktopView in a context that is safe and supported by core.
Iterating over layout.toolbar and adding only those toolbar buttons whose allowDesktop / allowMobile flags match the current view.
Iterating over layout.gearmenu and registering gear-menu popup options under the same view-dependent rules.
Maintain toggle-group and i18n behavior:
The logic for constructing toggle groups (TOGGLE_GROUPS) remains in parseLayout, so groups are still configured once based on the parsed layout.
The i18n plumbing via i18nProperties, setI18nProperty, and applyTranslation is unchanged; button titles, labels, example text, and hover text still use the same translation keys and override mechanism.
Impact and rationale:
The deprecation warning is resolved because site.desktopView / site.mobileView are now read only inside api.onToolbarCreate, which is invoked as part of composer toolbar rendering rather than at static initialization time.
Layout semantics for mobile vs. desktop remain the same:
X, M, and D prefixes in the layout string still control whether each button can appear on desktop, mobile, both, or never.
The only difference is when the filtering occurs (during toolbar creation instead of during layout parsing).
Gear-menu and toolbar buttons are still defined from the same layout configuration, and their actions, icons, and toggle behavior are preserved.
In summary, this commit cleans up the viewport access pattern in api-initializer.js to align with modern Discourse expectations, while keeping the functional behavior of ComposerButtonBonanza’s custom buttons consistent across desktop and mobile views.
Si vous avez rencontré des erreurs avec DCBB et/ou avez même des correctifs pour ces erreurs, ce serait formidable si vous pouviez ouvrir un problème en amont pour signaler tout cela, afin que je puisse les corriger — au lieu de simplement cloner le dépôt ailleurs et de dire aux gens d’utiliser votre clone. (Si vous ne pouvez pas forker le dépôt sur Codeberg pour une raison quelconque, ce serait également bien d’en être informé directement, au lieu de le savoir incidemment via un sujet de discussion sur lequel je ne reçois pas toujours les mises à jour par e-mail.)
Oh, tiens… juste au moment où je m’apprête à appuyer sur Répondre , une PR est apparue ! Merci !
Cette PR aborde-t-elle certains des problèmes survenant avec <div> par rapport à <span> sous le Compositeur WYSIWYG (ce qui a tourmenté @shauny ) — ou aborde-t-elle une autre erreur/dysfonctionnement, ou aborde-t-elle uniquement les avertissements de dépréciation (c’est-à-dire les choses qui casseront d’un jour à l’autre, mais qui ne sont pas encore cassées) ?
J’aimerais comprendre ce qui a changé en coulisses. Tout pointeur vers des sujets ou la documentation de Discourse serait très apprécié.