manut
(Manuel Tancoigne)
1
こんにちは！
私たちは post-event-builder プラグインのアウトレットを再定義するプラグインを作成しました。私たちのインスタンスでイベントを作成する際は、カスタムフィールドの入力が必須であり、フォームは提案された値に外部ソースからのデータを補完して入力します。
Discourse は ESR バージョンのみを使用しているため、2026.1.x では問題なく動作していましたが、現在 2026.7.x へのアップグレードを進めており、新しいフォームと「詳細」フォームを発見したところです。
ユーザーがすべてのカスタムフィールドを入力する必要があるため、コンパクト版ではなく「詳細」フォームを使用したいと考えています。フォームの切り替えオプションは不要です。
当初は、デフォルトで詳細フォームを使用し、コンパクト版への切り替えを無効にするためのサイト設定を1つ追加する（あるいはデフォルトで詳細フォームを使用し、フォームの切り替えを防ぐという2つの設定を追加する）ことを考えていました。コンパクトフォームを置き換えるプラグインアウトレットがあれば理想的ですが、詳細フォームへの切り替え機能を含むものであれば、それを削除できるようにするため、それでも構いません。
この新しい挙動がアップグレードプロセスを大きく妨げており、メンテナンスされていない古い 2026.1.x に留まることはできません。
最適なアプローチは何でしょうか？どのようにお手伝いできますか？
「いいね！」 1
manut
(Manuel Tancoigne)
2
こんにちは、また！
新しいプラグインアウトレットを含むPRを作成した場合、それが承認されて次の2026.7.xにバックポートされる可能性はありますか？それとも、このブロック問題を修正するために別の方法を見つけるべきでしょうか？
「いいね！」 1
chapoi
3
hey, PRのリンクをここに貼ってもらえますか？
「いいね！」 1
chapoi
5
あ、ごめん。前の投稿の「if」に気づいてなかったよ、はは！僕のミスだった。
manut
(Manuel Tancoigne)
6
「コンパクト」形式をオーバーライドするために新しいプラグインアウトレットを追加しましたが、この変更には満足していません。
「詳細」形式へのアクセスボタンはアウトレットでオーバーライドできず、エディタ内の「編集可能なプレビュー」も依然として「コンパクトモード」を使用しているため、オーバーライドされた形式と整合しない可能性があります（少なくとも当社の場合はそうでした）。
もっときれいな解決策として、プラグイン管理オプションにフォームの挙動を選択する機能を実装することを考え始めています。少なくとも次の2つのオプションが考えられます。
- default_editor：「コンパクト」（デフォルト）または「詳細」を選択
- allow_editor_switch：エディタを切り替えるボタンを非表示にする
まだ影響について調査中ですが、全体的なアイデアについてフィードバックをいただければ幸いです 
「いいね！」 2
martin
(Martin Brennan)
7
つまり、イベント作成時に常に「詳細モード」を開いた状態に強制するということですね？
ユーザーがそこから抜け出せないようにするということですか？
もしそうであれば、PostEventBuilderコンポーネントでinitialScreen用の値変換器（value transformer）を作成し、this.args.model.initialScreenを読むゲッターとして実装した後、値変換器で上書きできるようにします。これで値変換器を通じて常にinitialScreenをadvancedに設定できます。
コアに対するPRがあれば喜んでレビューします。すでにフックできるカスタムテーマをお持ちだと思います。
「いいね！」 2
manut
(Manuel Tancoigne)
8
スクリーンショットを添付できないため、現在の動作と実現したい内容を文章で説明させてください
Markdownエディターを使用する場合:
- プレビューが有効な場合、イベントフォームはプレビュー内に表示されます（
post-event-builderで囲まれておらず）、プレビューの右上に「高度なモード」へ切り替えるためのボタンがあります
- プレビューが無効な場合、イベントフォームはモーダルウィンドウに表示され、
post-event-builderで囲まれています（あなたが言及したユースケース）、モーダルのフッターに「高度なモード」へ切り替えるためのボタンがあります
リッチテキストエディターを使用する場合、イベントフォームは_投稿_フォームに埋め込まれます。これはプレビューで使用されるものと同じブロックのように見えます。
私が必要なのは、エディターは1つだけで、それは私たちのもの（独自のエディター）であることです。
このプラグインはコアにバンドルされているため、変更はプラグインを使用しているすべての人に影響を与えることは承知しています。したがって、変更は最小限にする必要があります。
EmberJSの仕組み全体がどう連携しているのかを理解するには、まだ十分な習熟度がなく、変更には時間がかかります。結果として得られたものが、もしかすると別の、よりクリーンな実装方法があるかもしれないと気づくこともよくあります。
おそらく、最新のアプローチである新しい管理パラメータの導入は過剰であり、すべての変更を一元化できるような、適切な™コンポーネントを単に見つけられていないだけなのかもしれません…
「いいね！」 1
chapoi
9
あなたの信頼レベルでは可能のはずですが、アップロードしようとした際にどうなりますか？
manut
(Manuel Tancoigne)
10
おっしゃる通り、これは権限関連の問題ではありませんでした。リファラーをブロックする拡張機能をインストールしており、AWSと相性が悪かったようです 
Markdownエディタ＋プレビュー：イベントフォームがプレビュー内に埋め込まれています（歯車アイコンをクリックすると、「高度な」イベントエディターが表示されるモーダルが現れます）
Markdownエディタ、プレビューなし：イベントフォームはモーダル内に表示され、エディターを切り替えるボタンはモーダルのフッターにあります
リッチテキストエディタ：イベントフォームがエディター内に埋め込まれています（歯車アイコンをクリックすると、「高度な」イベントエディターが表示されるモーダルが現れます）
「いいね！」 1
