[xwiki-devs] [Proposal][Urgent] Change of behavior for xproperties editor for backward compat reasons
Hi devs, Marius has recently introduced the honoring of text editor for xproperty editing for textarea types. This is great but it’s causing a lot of backward compatibility issues. We’ve fixed several xclass to use “puretext” for code but there are plenty out there still. I’ve just found another one with XWiki.WatchListMessage. The issue is that this is a blocker. I was trying to make a change there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example: https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc). I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want WYSIWYG in xproperties should say so. This is actually more logical to me because the object editor is a technical editor. In any case we need a solution that doesn’t break backward compatiblity. Since this change of behavior (honoring the editor for xproperties in the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users. WDYT? Thanks -Vincent
On 25 Aug 2016, at 18:36, Vincent Massol <[email protected]> wrote:
Hi devs,
Marius has recently introduced the honoring of text editor for xproperty editing for textarea types.
This is great but it’s causing a lot of backward compatibility issues. We’ve fixed several xclass to use “puretext” for code but there are plenty out there still.
I’ve just found another one with XWiki.WatchListMessage.
The issue is that this is a blocker. I was trying to make a change there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example: https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I
The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc).
I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want WYSIWYG in xproperties should say so.
This is actually more logical to me because the object editor is a technical editor.
In any case we need a solution that doesn’t break backward compatiblity.
Since this change of behavior (honoring the editor for xproperties in the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users.
I forgot to mention that initially I was even using the GWT editor as my WYSIWYG editor and in that case I can’t even view the source since that doesn’t exist for GWT and thus those using GWT are even more stuck… Thanks -Vincent
WDYT?
Thanks -Vincent
On 25 Aug 2016, at 18:36, Vincent Massol <[email protected]> wrote:
Hi devs,
Marius has recently introduced the honoring of text editor for xproperty editing for textarea types.
This is great but it’s causing a lot of backward compatibility issues. We’ve fixed several xclass to use “puretext” for code but there are plenty out there still.
I’ve just found another one with XWiki.WatchListMessage.
The issue is that this is a blocker. I was trying to make a change there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example: https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I
The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc).
This is not true; I can go to the XWiki.Mail page and edit the xclass and change the editor to use. That’s still complex and requires knowledge. Thanks -Vincent
I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want WYSIWYG in xproperties should say so.
This is actually more logical to me because the object editor is a technical editor.
In any case we need a solution that doesn’t break backward compatiblity.
Since this change of behavior (honoring the editor for xproperties in the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users.
WDYT?
Thanks -Vincent
On Thu, Aug 25, 2016 at 7:52 PM, Vincent Massol <[email protected]> wrote:
On 25 Aug 2016, at 18:36, Vincent Massol <[email protected]> wrote:
Hi devs,
Marius has recently introduced the honoring of text editor for xproperty editing for textarea types.
This is great but it’s causing a lot of backward compatibility issues. We’ve fixed several xclass to use “puretext” for code but there are plenty out there still.
I’ve just found another one with XWiki.WatchListMessage.
The issue is that this is a blocker. I was trying to make a change there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example: https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I
The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc).
This is not true; I can go to the XWiki.Mail page and edit the xclass and change the editor to use. That’s still complex and requires knowledge.
Or you can change your preferred editor from "WYSIWYG" to "Text". Either from the user profile, "Default editor to use", or from the Administration
Edit Mode Settings, "Default Editor". If you're accessing the Object or Class edit modes then you are an advanced user (as specified by the user preferences) and most probably you prefer a plain text editor rather than a visual editor. The default Admin user should probably be configured to use the Text editor and not WYSIWYG.
That doesn't mean we shouldn't fix the value of the Editor meta property for the existing xproperties by setting the right editor (not by leaving it empty), but it's not as critical as you suggest. Using PureText when the editor is not set for an xproperty is possible ( https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-8.3-milestone-1/... ) but it means there is no fallback on the user preferences and the administration, which some users might complain about. Thanks, Marius
Thanks -Vincent
I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want
WYSIWYG in xproperties should say so.
This is actually more logical to me because the object editor is a
technical editor.
In any case we need a solution that doesn’t break backward compatiblity.
Since this change of behavior (honoring the editor for xproperties in
the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Marius, Thanks for the reply, see below.
On 26 Aug 2016, at 07:04, Marius Dumitru Florea <[email protected]> wrote:
On Thu, Aug 25, 2016 at 7:52 PM, Vincent Massol <[email protected]> wrote:
On 25 Aug 2016, at 18:36, Vincent Massol <[email protected]> wrote:
Hi devs,
Marius has recently introduced the honoring of text editor for xproperty editing for textarea types.
This is great but it’s causing a lot of backward compatibility issues. We’ve fixed several xclass to use “puretext” for code but there are plenty out there still.
I’ve just found another one with XWiki.WatchListMessage.
The issue is that this is a blocker. I was trying to make a change there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example: https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I
The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc).
This is not true; I can go to the XWiki.Mail page and edit the xclass and change the editor to use. That’s still complex and requires knowledge.
Or you can change your preferred editor from "WYSIWYG" to "Text”.
My editor is not set (that’s the default and that’s what users are using by default). Also, as a user, I don’t want that. I want WYSIWYG for most content. And having to go back and forth is not just a pain, you need to know about it.
Either from the user profile, "Default editor to use", or from the Administration
Edit Mode Settings, "Default Editor". If you're accessing the Object or Class edit modes then you are an advanced user (as specified by the user preferences) and most probably you prefer a plain text editor rather than a visual editor. The default Admin user should probably be configured to use the Text editor and not WYSIWYG.
An admin is not a developer. They’re simple users. Most users download xwiki and install it and the user they create is an admin user because the DW ask them for that. It doesn’t mean they’re experienced users knowing XWiki in and out.
That doesn't mean we shouldn't fix the value of the Editor meta property for the existing xproperties by setting the right editor (not by leaving it empty),
I agree with this.
but it's not as critical as you suggest.
We’ve found issues about unusable XWiki several times already (for various textarea xproperties and after XWiki 8.2 was released) and I’m sure there are a lot more (including in extensions). As I’ve shown, not only are you blocked as a user (unless you’re an expert in XWiki), it’s also dangerous because making a change in source mode of a texarea using CK has a high chance of breaking some script without you realizing that.
Using PureText when the editor is not set for an xproperty is possible ( https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-8.3-milestone-1/... ) but it means there is no fallback on the user preferences and the administration, which some users might complain about.
It’s all about backward compat for me. In the Object editor we were never showing WYSIWYG before so I don’t think that using puretext when no editor is set when editing in object editor is going to be an issue at all. At worse it’s the same as before. And since we’ll set WYSIWYG for some xproperties, users will still be able to see WYSIWYG for some properties. So we’ve progressed. I’m not even talking about inline mode here. It’s possible we also need to do something similar for it but I think the minimum to do is to make sure the object editor is always usable. Let’s see what others think. Thanks -Vincent
Thanks, Marius
Thanks -Vincent
I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want
WYSIWYG in xproperties should say so.
This is actually more logical to me because the object editor is a
technical editor.
In any case we need a solution that doesn’t break backward compatiblity.
Since this change of behavior (honoring the editor for xproperties in
the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users.
WDYT?
Thanks -Vincent
On Fri, Aug 26, 2016 at 9:39 AM, Vincent Massol <[email protected]> wrote:
Hi Marius,
Thanks for the reply, see below.
On 26 Aug 2016, at 07:04, Marius Dumitru Florea < [email protected]> wrote:
On Thu, Aug 25, 2016 at 7:52 PM, Vincent Massol <[email protected]> wrote:
On 25 Aug 2016, at 18:36, Vincent Massol <[email protected]> wrote:
Hi devs,
Marius has recently introduced the honoring of text editor for
xproperty
editing for textarea types.
This is great but it’s causing a lot of backward compatibility issues.
We’ve fixed several xclass to use “puretext” for code but there are plenty out there still.
I’ve just found another one with XWiki.WatchListMessage.
The issue is that this is a blocker. I was trying to make a change
there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example:
https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I
The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc).
This is not true; I can go to the XWiki.Mail page and edit the xclass and change the editor to use. That’s still complex and requires knowledge.
Or you can change your preferred editor from "WYSIWYG" to "Text”.
My editor is not set (that’s the default and that’s what users are using by default).
Also, as a user, I don’t want that. I want WYSIWYG for most content. And having to go back and forth is not just a pain, you need to know about it.
Either from the user profile, "Default editor to use", or from the Administration
Edit Mode Settings, "Default Editor". If you're accessing the Object or Class edit modes then you are an advanced user (as specified by the user preferences) and most probably you prefer a plain text editor rather than a visual editor. The default Admin user should probably be configured to use the Text editor and not WYSIWYG.
An admin is not a developer. They’re simple users. Most users download xwiki and install it and the user they create is an admin user because the DW ask them for that. It doesn’t mean they’re experienced users knowing XWiki in and out.
FTR, the use case that was broken is "Customizing the WatchList email template" http://extensions.xwiki.org/xwiki/bin/view/Extension/Watchlist+Application#H... which is not exposed in the UI. The user (after reading the documentation) has to edit a hidden / technical page using the object editor. The documentation says "When customizing a watchlist message template, you will be writing Velocity code". It's a regression nevertheless.
That doesn't mean we shouldn't fix the value of the Editor meta property for the existing xproperties by setting the right editor (not by leaving it empty),
I agree with this.
but it's not as critical as you suggest.
We’ve found issues about unusable XWiki several times already (for various textarea xproperties and after XWiki 8.2 was released) and I’m sure there are a lot more (including in extensions).
As I’ve shown, not only are you blocked as a user (unless you’re an expert in XWiki), it’s also dangerous because making a change in source mode of a texarea using CK has a high chance of breaking some script without you realizing that.
Using PureText when the editor is not set for an xproperty is possible ( https://github.com/xwiki/xwiki-platform/blob/xwiki- platform-8.3-milestone-1/xwiki-platform-core/xwiki- platform-oldcore/src/main/java/com/xpn/xwiki/objects/ classes/TextAreaClass.java#L159 ) but it means there is no fallback on the user preferences and the administration, which some users might complain about.
It’s all about backward compat for me.
In the Object editor we were never showing WYSIWYG before so I don’t think that using puretext when no editor is set when editing in object editor is going to be an issue at all. At worse it’s the same as before. And since we’ll set WYSIWYG for some xproperties, users will still be able to see WYSIWYG for some properties. So we’ve progressed.
I’m not even talking about inline mode here. It’s possible we also need to do something similar for it but I think the minimum to do is to make sure the object editor is always usable.
Let’s see what others think.
Thanks -Vincent
Thanks, Marius
Thanks -Vincent
I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want
WYSIWYG in xproperties should say so.
This is actually more logical to me because the object editor is a
technical editor.
In any case we need a solution that doesn’t break backward
compatiblity.
Since this change of behavior (honoring the editor for xproperties in
the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Example of bug introduced in an extension since this change: http://jira.xwiki.org/browse/TOUR-47 2016-08-26 14:53 GMT+02:00 Marius Dumitru Florea < [email protected]>:
On Fri, Aug 26, 2016 at 9:39 AM, Vincent Massol <[email protected]> wrote:
Hi Marius,
Thanks for the reply, see below.
On 26 Aug 2016, at 07:04, Marius Dumitru Florea < [email protected]> wrote:
On Thu, Aug 25, 2016 at 7:52 PM, Vincent Massol <[email protected]> wrote:
On 25 Aug 2016, at 18:36, Vincent Massol <[email protected]> wrote:
Hi devs,
Marius has recently introduced the honoring of text editor for
xproperty
editing for textarea types.
This is great but it’s causing a lot of backward compatibility
issues. We’ve fixed several xclass to use “puretext” for code but there are plenty out there still.
I’ve just found another one with XWiki.WatchListMessage.
The issue is that this is a blocker. I was trying to make a change
there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example:
https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I
The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc).
This is not true; I can go to the XWiki.Mail page and edit the xclass and change the editor to use. That’s still complex and requires knowledge.
Or you can change your preferred editor from "WYSIWYG" to "Text”.
My editor is not set (that’s the default and that’s what users are using by default).
Also, as a user, I don’t want that. I want WYSIWYG for most content. And having to go back and forth is not just a pain, you need to know about it.
Either from the user profile, "Default editor to use", or from the Administration
Edit Mode Settings, "Default Editor". If you're accessing the Object or Class edit modes then you are an advanced user (as specified by the user preferences) and most probably you prefer a plain text editor rather than a visual editor. The default Admin user should probably be configured to use the Text editor and not WYSIWYG.
An admin is not a developer. They’re simple users. Most users download xwiki and install it and the user they create is an admin user because the DW ask them for that. It doesn’t mean they’re experienced users knowing XWiki in and out.
FTR, the use case that was broken is "Customizing the WatchList email template" http://extensions.xwiki.org/xwiki/bin/view/Extension/ Watchlist+Application#HAdministrators:CustomizingtheWatchListemailtemplate which is not exposed in the UI. The user (after reading the documentation) has to edit a hidden / technical page using the object editor. The documentation says "When customizing a watchlist message template, you will be writing Velocity code".
It's a regression nevertheless.
That doesn't mean we shouldn't fix the value of the Editor meta
property
for the existing xproperties by setting the right editor (not by leaving it empty),
I agree with this.
but it's not as critical as you suggest.
We’ve found issues about unusable XWiki several times already (for various textarea xproperties and after XWiki 8.2 was released) and I’m sure there are a lot more (including in extensions).
As I’ve shown, not only are you blocked as a user (unless you’re an expert in XWiki), it’s also dangerous because making a change in source mode of a texarea using CK has a high chance of breaking some script without you realizing that.
Using PureText when the editor is not set for an xproperty is possible ( https://github.com/xwiki/xwiki-platform/blob/xwiki- platform-8.3-milestone-1/xwiki-platform-core/xwiki- platform-oldcore/src/main/java/com/xpn/xwiki/objects/ classes/TextAreaClass.java#L159 ) but it means there is no fallback on the user preferences and the administration, which some users might complain about.
It’s all about backward compat for me.
In the Object editor we were never showing WYSIWYG before so I don’t think that using puretext when no editor is set when editing in object editor is going to be an issue at all. At worse it’s the same as before. And since we’ll set WYSIWYG for some xproperties, users will still be able to see WYSIWYG for some properties. So we’ve progressed.
I’m not even talking about inline mode here. It’s possible we also need to do something similar for it but I think the minimum to do is to make sure the object editor is always usable.
Let’s see what others think.
Thanks -Vincent
Thanks, Marius
Thanks -Vincent
I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want
WYSIWYG in xproperties should say so.
This is actually more logical to me because the object editor is a
technical editor.
In any case we need a solution that doesn’t break backward
compatiblity.
Since this change of behavior (honoring the editor for xproperties in
the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
On Mon, Aug 29, 2016 at 11:41 AM, Guillaume Delhumeau < [email protected]> wrote:
Example of bug introduced in an extension since this change: http://jira.xwiki.org/browse/TOUR-47
No, that's a different issue. I commented on the issue.
2016-08-26 14:53 GMT+02:00 Marius Dumitru Florea < [email protected]>:
On Fri, Aug 26, 2016 at 9:39 AM, Vincent Massol <[email protected]> wrote:
Hi Marius,
Thanks for the reply, see below.
On 26 Aug 2016, at 07:04, Marius Dumitru Florea < [email protected]> wrote:
On Thu, Aug 25, 2016 at 7:52 PM, Vincent Massol <[email protected]> wrote:
On 25 Aug 2016, at 18:36, Vincent Massol <[email protected]>
wrote:
Hi devs,
Marius has recently introduced the honoring of text editor for
xproperty editing for textarea types.
This is great but it’s causing a lot of backward compatibility
issues. We’ve fixed several xclass to use “puretext” for code but there are plenty out there still.
I’ve just found another one with XWiki.WatchListMessage.
The issue is that this is a blocker. I was trying to make a change
there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example:
https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I
The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc).
This is not true; I can go to the XWiki.Mail page and edit the xclass and change the editor to use. That’s still complex and requires knowledge.
Or you can change your preferred editor from "WYSIWYG" to "Text”.
My editor is not set (that’s the default and that’s what users are using by default).
Also, as a user, I don’t want that. I want WYSIWYG for most content. And having to go back and forth is not just a pain, you need to know about it.
Either from the user profile, "Default editor to use", or from the Administration
Edit Mode Settings, "Default Editor". If you're accessing the Object or Class edit modes then you are an advanced user (as specified by the user preferences) and most probably you prefer a plain text editor rather than a visual editor. The default Admin user should probably be configured to use the Text editor and not WYSIWYG.
An admin is not a developer. They’re simple users. Most users download xwiki and install it and the user they create is an admin user because the DW ask them for that. It doesn’t mean they’re experienced users knowing XWiki in and out.
FTR, the use case that was broken is "Customizing the WatchList email template" http://extensions.xwiki.org/xwiki/bin/view/Extension/ Watchlist+Application#HAdministrators:CustomizingtheWatchListemailte mplate which is not exposed in the UI. The user (after reading the documentation) has to edit a hidden / technical page using the object editor. The documentation says "When customizing a watchlist message template, you will be writing Velocity code".
It's a regression nevertheless.
That doesn't mean we shouldn't fix the value of the Editor meta
property
for the existing xproperties by setting the right editor (not by leaving it empty),
I agree with this.
but it's not as critical as you suggest.
We’ve found issues about unusable XWiki several times already (for various textarea xproperties and after XWiki 8.2 was released) and I’m sure there are a lot more (including in extensions).
As I’ve shown, not only are you blocked as a user (unless you’re an expert in XWiki), it’s also dangerous because making a change in source mode of a texarea using CK has a high chance of breaking some script without you realizing that.
Using PureText when the editor is not set for an xproperty is possible ( https://github.com/xwiki/xwiki-platform/blob/xwiki- platform-8.3-milestone-1/xwiki-platform-core/xwiki- platform-oldcore/src/main/java/com/xpn/xwiki/objects/ classes/TextAreaClass.java#L159 ) but it means there is no fallback on the user preferences and the administration, which some users might complain about.
It’s all about backward compat for me.
In the Object editor we were never showing WYSIWYG before so I don’t think that using puretext when no editor is set when editing in object editor is going to be an issue at all. At worse it’s the same as before. And since we’ll set WYSIWYG for some xproperties, users will still be able to see WYSIWYG for some properties. So we’ve progressed.
I’m not even talking about inline mode here. It’s possible we also need to do something similar for it but I think the minimum to do is to make sure the object editor is always usable.
Let’s see what others think.
Thanks -Vincent
Thanks, Marius
Thanks -Vincent
I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want
WYSIWYG in xproperties should say so.
This is actually more logical to me because the object editor is a
technical editor.
In any case we need a solution that doesn’t break backward
compatiblity.
Since this change of behavior (honoring the editor for xproperties
in the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Aug 26, 2016 at 7:04 AM, Marius Dumitru Florea <[email protected]> wrote:
On Thu, Aug 25, 2016 at 7:52 PM, Vincent Massol <[email protected]> wrote:
On 25 Aug 2016, at 18:36, Vincent Massol <[email protected]> wrote:
Hi devs,
Marius has recently introduced the honoring of text editor for xproperty editing for textarea types.
This is great but it’s causing a lot of backward compatibility issues. We’ve fixed several xclass to use “puretext” for code but there are plenty out there still.
I’ve just found another one with XWiki.WatchListMessage.
The issue is that this is a blocker. I was trying to make a change there so I was editing using the “source” mode of CKEditor. The problem is that when I saved there were a lot of changes made to the content automatically, breaking the code, see for example: https://www.evernote.com/l/AHf4KpfVtfBOK5zqcyf_up1Rty923fZOm-I
The main issue is that I’m stuck. There’s nothing I can do in my wiki (without resorting to scripting, using REST, etc).
This is not true; I can go to the XWiki.Mail page and edit the xclass and change the editor to use. That’s still complex and requires knowledge.
Or you can change your preferred editor from "WYSIWYG" to "Text". Either from the user profile, "Default editor to use", or from the Administration
Edit Mode Settings, "Default Editor". If you're accessing the Object or Class edit modes then you are an advanced user (as specified by the user preferences) and most probably you prefer a plain text editor rather than a visual editor. The default Admin user should probably be configured to use the Text editor and not WYSIWYG.
That doesn't mean we shouldn't fix the value of the Editor meta property for the existing xproperties by setting the right editor (not by leaving it empty), but it's not as critical as you suggest.
Using PureText when the editor is not set for an xproperty is possible ( https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-8.3-milestone-1/... ) but it means there is no fallback on the user preferences and the administration, which some users might complain about.
This is actually very wrong. Be careful with "PureText", it does not only indicate the editor but also the type of the content. If you set "PureText" then it means the content is not wiki syntax and will not be converted, not be parsed by the displayer, etc. If you want wiki syntax but not WYSIWYG then you should use "Text". Right now the default in TextAreaClass when this is not set is to see the content as wiki content so either "Text" or "Wysiwyg".
Thanks, Marius
Thanks -Vincent
I’m proposing that we do the opposite: * When no editor is specified, use the wiki editor. Apps that want
WYSIWYG in xproperties should say so.
This is actually more logical to me because the object editor is a
technical editor.
In any case we need a solution that doesn’t break backward compatiblity.
Since this change of behavior (honoring the editor for xproperties in
the object editor) was introduced in XWiki 8.2 we need to act fast before it becomes a problem for our users.
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (4)
-
Guillaume Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol