This weird behaviour on the class editor is very probably related to https://github.com/xwiki/xwiki-platform/blob/102124c214f107bf0bfd2b709969482625f1af53/xwiki-platform-core/xwiki-platform-appwithinminutes/xwiki-platform-appwithinminutes-ui/src/main/resources/AppWithinMinutes/Content.xml#L46-L47
bq. ## Don't load the WYSIWYG editor when editing the class, because it's too heavy. bq. #set ($useWysiwygEditor = false)
This condition was added with XWIKI-8734 .
From Marius comment, except if we rework the wiki editor tool, option 2. is not doable because we cannot use this tool for LongTexts. The only solution left is to have both fields follow the user/wiki preferences. Note that it's already the case for the entry editor in 16.9.0-SNAPSHOT. I'll propose in a PR an implementation to respect the user prefered editor for the Content field.
There's still the option of fixing the toolbar for longTexts, but I'd rather focus on the XWiki standard default editor, which is WYSIWYG.
Charpentier Lucas on 24/Oct/24 15:20
This weird behaviour on the class editor is very probably related to https://github.com/xwiki/xwiki-platform/blob/102124c214f107bf0bfd2b709969482625f1af53/xwiki-platform-core/xwiki-platform-appwithinminutes/xwiki-platform-appwithinminutes-ui/src/main/resources/AppWithinMinutes/Content.xml#L46-L47
bq. ## Don't load the WYSIWYG editor when editing the class, because it's too heavy. bq. #set ($useWysiwygEditor = false)
This condition was added with XWIKI-8734 .
From Marius comment, except if we rework the wiki editor tool, option 2. is not doable because we cannot use this tool for LongTexts. The only solution left is to have both fields follow the user/wiki preferences. Note that it's already the case for the entry editor in 16.9.0-SNAPSHOT. I'll propose in a PR an implementation to respect the user prefered editor for the Content field.
There's still the option of fixing the toolbar for longTexts, but I'd rather focus on the XWiki standard default editor, which is WYSIWYG.
____ The reason for the change we want to revert for XWIKI-8734 was that the CKEditor was too heavy to get in the UI. However, it seems like nowadays we have it in other places in the UI and it does not pose any issue. I'll try reverting this change (removing the logic that looks like a bug/inconsistency for a new user) and test changes to make sure it's not an issue nowadays.
Charpentier Lucas on 24/Oct/24 15:21
This weird behaviour on the class editor is very probably related to https://github.com/xwiki/xwiki-platform/blob/102124c214f107bf0bfd2b709969482625f1af53/xwiki-platform-core/xwiki-platform-appwithinminutes/xwiki-platform-appwithinminutes-ui/src/main/resources/AppWithinMinutes/Content.xml#L46-L47
bq. ## Don't load the WYSIWYG editor when editing the class, because it's too heavy. bq. #set ($useWysiwygEditor = false)
This condition was added with XWIKI-8734 https://github .com/xwiki/xwiki-platform/commit/e6b6769e0b582ff79a1cf6c3e0d4ad25a37b34eb .
From Marius comment, except if we rework the wiki editor tool, option 2. is not doable because we cannot use this tool for LongTexts. The only solution left is to have both fields follow the user/wiki preferences. Note that it's already the case for the entry editor in 16.9.0-SNAPSHOT. I'll propose in a PR an implementation to respect the user prefered editor for the Content field.
There's still the option of fixing the toolbar for longTexts, but I'd rather focus on the XWiki standard default editor, which is WYSIWYG.
____ The reason for the change we want to revert for XWIKI-8734 was that the CKEditor was too heavy to get in the UI. However, it seems like nowadays we have it in other places in the UI and it does not pose any issue. I'll try reverting this change (removing the logic that looks like a bug/inconsistency for a new user) and test changes to make sure it's not an issue nowadays.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
