12.3 Encoding and editor problems

Hi,

after upgrading to 12.3 we encounter two problems. The first is that when pressing (in German) “Bearbeiten” (could be editing in english) a in page editor comes up that enables editing of the page.
The default is set to CK-Editor, but this editor is now only available when selecting WYSIWYG Editor from the Dropdown.
The second Problem is that when the in page editor is used all German umlauts are corrupt during editing . Looks like an encoding problem.

I don’t understand what is the first problem, sorry. As for the second problem, I can’t reproduce. On a clean 12.3 I put this (Ä/ä, Ö/ö, Ü/ü) in the title and content of a page from in-place editing and it is saved properly. Maybe some encoding configuration was lost/reset during the upgrade? In any case, this looks to me more like a configuration issue on your side than a bug. Don’t you have the same issue with umlauts when using the Wiki edit mode or the old WYSIWYG edit mode?

The first problem is that when clicking the Edit button I always get the CK Editor. Inplace editing was never come up.

When using CK Editor everything works fine and all encodings are correct. Do you have a hint where I could look for the configuration issues you mentioned ?

The behavior of the Edit button is explained here https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/PageEditing#HSimpleMode . If the edit mode you get after clicking on the Edit button uses CKEditor then it means your user profile has been configured to prefer the WYSIWYG editor. If you don’t want the CKEditor then configure your user profile to use the Wiki (text) editor.

I don’t understand this part. You started this thread because you have encoding issues with the in-place editor, so the in-place editor must come when you click on Edit.

There shouldn’t be much difference between the in-place edit and the old WYSIWYG edit mode so it’s strange that you have the encoding issue only for the in-place editor. I would check that the encoding is UTF-8 at all levels, starting with the page source HTML. See also https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Configuration/Encoding/ .

To clarify what my problem is I will describe the behaviour before and after the update.

When I pressed Edit button before the update the CK Editor starts and I was able to edit the page. Everything worked fine. This CK Editor runs not in page. It has a separate dialog where I can use the editor and switch to source code.

After the upgrade when I press the Edit button the CK editor runs as inpage editor. The editor toolbar looks like the CK Editor toolbar, but the source code button is missing and the encoding is corrupt.

Please see the screenshots attached - and of course thanks for your patience :slight_smile:

Before upgrade:

After upgrade:

Settings in the user profile:

This is a temporary limitation of the in-place editor. See my comment on https://jira.xwiki.org/browse/XWIKI-17145 for other limitations that we’re planing to address. If the Source button is very important to you then you can configure your user profile to be an advanced user and then edit the page by choosing “WYSIWYG” from the Edit button drop down.

As for the encoding issue, we need your help to be able to fix it. Did you double check that the UTF-8 encoding is set at all levels? And to be sure: the text appears broken after you click on Save & View, right? You could check the HTTP request that is made on Save & View (using the browser’s developer tools) to see if the submitted content is broken or not and to check the HTTP headers (especially the encoding).

FYI here’s the encoding doc: https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Configuration/Encoding/

We use an apache2 as reverse proxy may be there is configuration issue I will check this. Do you have an idea why this only occurs when the CK Editor runs as inpage editor and not when running as WYSIWYG editor ?

I will check this.

A colleague and I have checked the configs. Everything is set to UTF-8 as documented in the link you gave me.

Anything else I could check ?

You didn’t answer to this part.

Sorry, no the encoding changes directly after pressing the Edit button. When canceling the edit no changes are saved and the page is still OK.
After saving the page is corrupt.

When you click on Edit the content to edit is retrieved with an URL like this

http://<server>/xwiki/bin/view/Some/Page/?xpage=rendercontent&outputTitle=true&outputSyntax=annotatedxhtml&language=en

Check the HTTP headers of this request and its response, and see if the response body looks fine or not (i.e. if it has the proper encoding or not). For the record, the code that is executed on the server side is https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/rendercontent.vm .

I tried to retrieve the information:

Is this what you want ?

The response encoding looks fine (UTF-8). What about the response body (HTML), are the characters badly encoded there?

Do you have any proxy on the server side that could modify the HTML response? Also, in order to limit the problem, you could try to disable any browser extension you may have and that may affect the HTML injected into the page.

You can copy the request URL and access it in a separate browser tab. Are the characters broken there?

Yes we use a reverse proxy. I will try to get direct access to the tomcat to exclude the proxy as source of the problem.

Is broken too.

OK the reverse proxy ist set to UTF-8, but when I skip the proxy the encoding problem is gone.
When I got the correct setup for the proxy I will post it here for the records.

Sorry for wasting your time and thank you for your help !!

Just for the records. During the last five years we had this two directives in our apache2 reverse proxy setup:

  • SetOutputFilter proxy-html
  • RequestHeader unset Accept-Encoding

This worked till the upgrade to 12.3. To avoid the encoding error, I removed this settings and everything works as expected.
I know that I have added this to directives to avoid an encoding problem in an old version.

May be this information useful for others.