-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PluginCollection doesn't keep the order of plugins which were passed to it #2905
Comments
Well the order is OK:
Every constructor has been called in the proper order:
The problem with this is that this function does all the things in the constructor - it does not have the
So we cannot extend non-existing schema item in This unveils a problem with features implementations to be sure. The Most of the plugins have similar schema of defining things:
The non-conventional are: Gathering it all together I think that the we should:
Ad. 2.: In most of the cases developers would expect that other features are loaded and fully setup. So maybe they should be called not in the Other way is to define the ClassicEditor
.create( document.querySelector( '#editor' ), {
plugins: [ ArticlePluginSet, function( editor ) {
this.init = () => {
editor.model.schema.extend( 'tableCell', {
allowAttributes: 'style'
} );
};
} ], |
Wouldn't the following help ClassicEditor
.create( document.querySelector( '#editor' ), {
plugins: [
ArticlePluginSet,
function( editor ) {
this.init = () => {
editor.model.schema.extend( 'tableCell', {
allowAttributes: 'style'
} );
}
editor.conversion.attributeToAttribute( {
model: {
name: 'tableCell',
key: 'style'
},
view: 'style'
} );
}
], ? AFAIR all plugins, even plain functions are instantialized. |
@oleq yes - that's one of the proposed solutions in my lengthy post :D If we agree that the Right now this might be counter-intuitive and might be changed so the |
Docs: Added a note to the `PluginInterface` about the limitations of plugins defined as plain functions. Closes #175.
I think that this should work because all
ArticlePluginSet
deps should be initialized before the next plugin from the list is being processed. It fails now because it seems that all the deps are pushed to the end of the queue, soextend()
throws that there's notableCell
.The current behaviour works fine in normal cases, but it's a bit irritating in ones like above.
The text was updated successfully, but these errors were encountered: