もう少しデバッグした後、私はこれを不可能と判断しました。
外部として登録された「サブプラグイン」をロードすることを実現しました。プラグインの名前を登録した後でCKEDITOR.plugins.load
と呼ぶだけでした。これはエディタから呼び出されるのと同じメソッドですが、エディタは言語ファイルのロードや重要なコールバック(beforeInit
、init
、およびafterInit
)を含む多くの追加ステップを追っています。すべてのアクションが発生する場所
editor.js
loadPlugins
機能がありますが、エディタの設定をロードするプラグインを決定するために使用されているため、それだけで、ロードするプラグインのリストなしEditor
引数を受け入れます。リストが決定されると、それらはすべて並列にロードされます。サブプラグインが最初からこの配列にない場合、後で手動でマスタープラグインをロードしても、エディタで完全に初期化されることはありません。
私が思いついた唯一の回避策は、CKEditorソース(理想的にはマスタープラグインと一緒に配布されたスクリプト)を読み込んだ後で、1つの余分なスクリプトを読み込むことです。スクリプトは外部サブプラグイン定義(実際には "master_plugin/plugins"という名前のローカルサブフォルダにあります)を設定し、instanceCreated
コールバックを登録します。これは基本的に新しいエディタの設定を見て、サブプラグインが必要かどうかを判断しますエディタが初期化される前にリストに追加されます。このうちのいずれかがプラグイン内から発生した場合、余分なスクリプトと比べて遅すぎると失敗します。
UPDATE
instanceCreated
が発生した場合、ユーザーの設定がまだエディタにロードされていないので、実際にinstanceCreated
コールバック内configLoaded
リスナーを登録する必要がありました。 customConfigLoaded
イベントもユーザーの設定を受信するには時期尚早であるため、plugins
またはextendedPlugins
の変更は失われます。驚いたことに、configLoaded
イベントはの後にの後にいくつかの設定オプション(readOnly、enterMode、shiftEnterMode、tabIndex、skin、多分他のもの)を利用しますが、plugins
はまだ触れていません。
configLoaded
イベントは、ページ提供の設定を編集するための唯一のフックポイントです。 config.customConfig
オプションを使用すると、editorConfigファンクション内でcustomConfigLoaded
をリッスンし、完全な設定を取得することができます。これは、CKEditorが自分のcustomConfigLoaded
リスナ内のページ設定のみをマージするためです。
多くのプラグインを1つのプラグイン(アドオンパッケージ)で読み込むという本来的な目標に戻って、プラグインシステムの設計では、明らかに何も意図していません。