Maximize (and resize) plugin and shared spaces incompatibility

[Wiktor Walc]

It looks like the maximize plugin correctly turned off itself when inline mode is detected in init() callback:

// Maximize plugin isn't available in inline mode yet.
if ( editor.elementMode == CKEDITOR.ELEMENT_MODE_INLINE )
	return;

Similarly, Maximize button is disabled on iOS:

// Disabled on iOS (#8307).
modes: { wysiwyg: !CKEDITOR.env.iOS, source: !CKEDITOR.env.iOS },

We know that maximize plugin is useless when shared spaces are used, but instead of switching it off automatically just like with two previous cases, we rely on users knowledge:

removePlugins : 'maximize'

Perhaps we could do this automatically for maximize and resize plugins?

[Jakub Ś]

Perhaps this should be considered bug and not feature request?

[Piotrek Koszuliński]

Yes, this is more a bug than a feature.

[Artur Delura]

Changes in ​branch:t/12163 but here add new responsibility to plugin. It have to manage disabling self when some condition is met. Maybe we could handle it somewhere else, perhaps here: ​https://github.com/ckeditor/ckeditor-dev/blob/master/core/editor.js#L490-L493

And other issue is that we didn't removed sharedspace plugin but instead just prevent initialize it. Just see at editor instancce plugins field - maximize plugin is present.

[Piotrek Koszuliński]

You should check whether sharedspaces is enabled in the specific editor instance, not whether it's available globally in CKEDITOR. Use editor.plugins.sharedspace.

[Artur Delura]

Right. I amended changes to ​branch:t/12163.

[Piotrek Koszuliński]

Fixed on master with ​git:665e3b9.

[Piotrek Koszuliński]

I reverted this change in ​git:df1293de.

I realised that it doesn't make sense, because enabling the sharedspace plugin will disable maximize and resize even though it may not be configured (config.sharedSpaces). That may break websites which included the sharedspace but don't use it in some cases.

Additionally, I was reluctant to make this change from the beginning and now I'm strongly against it. One plugin cannot disable itself based on another's plugin configuration and existence. This will make too strong relations between our plugins and may be a cause of bugs in the future. Additionally, there are more incompatible plugins, like the bbcode, but we don't check in dozen of other plugins whether it's enabled. Instead, we properly configure the list of plugins which are enabled. This is the right way to resolve conflicts.

Of course I understand that we'll force developers to think about it, but the fact is that we are not able to do this right on our side. Not with all possible plugins, including 3rd party ones.

[Wiktor Walc]

Altough I'm a fan of smart applications that solve known and common issues for you, I agree with Reinmar that we should solve this case in a different way.

The most important place to deal with this is the documentation: ​https://github.com/ckeditor/ckeditor-docs/issues/32

[Jakub Ś]

I actually like to say a little bit of extra work hasn't killed anyone. I agree with @Reinmar as well.

[Jakub Ś]

This will make too strong relations between our plugins and may be a cause of bugs in the future. Additionally, there are more incompatible plugins, like the bbcode, but we don't check in dozen of other plugins whether it's enabled. Instead, we properly configure the list of plugins which are enabled. This is the right way to resolve conflicts.

The most important place to deal with this is the documentation: ​​https://github.com/ckeditor/ckeditor-docs/issues/32

Taking two above comments into account I'm closing this ticket as invalid.

[Anna Tomanek]

This is also now properly documented as suggested in the ​GitHub issue.