[MGNLETK-25] Rich text gone from dialog after upgrade Created: 29/Apr/10  Updated: 06/May/10  Resolved: 06/May/10

Status: Closed
Project: Extended Templating Kit (closed)
Component/s: None
Affects Version/s: 1.3.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ernst Bunders Assignee: Jan Haderka
Resolution: Not an issue Votes: 0
Labels: vpro
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

firefox 3.5.9, chrome 5.0


Attachments: XML File config.modules.extended-templating-kit.config.sites.pip.xml     XML File website.tegenlicht.nieuws.2009.december.kyoto-protocol-1997-2012.xml    
Issue Links:
relation
is related to MGNLETK-26 Make i18n authoring suport configurab... Closed
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

We're running Magnolia EE 4.2.3 in production. Our development build is
currently on EE 4.3.1 since we want to make use of the new enterprise
multi-site support and we use ETK 1.3.1-SNAPSHOT because that fixes some
multi-site bugs in ETK 1.3.

We are currently testing, but our testers
noticed that when clicking edit on a paragraph that contains rich text,
the rich text editor in the dialog is empty. When you just change a
title, don't pay any attention to the rich text and click save, you lose
the rich text!

I'm attaching the xml dump of a page that has this particular problem. There is a textimage paragraph in the main area.



 Comments   
Comment by Jan Haderka [ 03/May/10 ]

The problem seems to be caused by the fact there is a mixture of localized and non localized content in the page. For example /main/01 paragraph contains only non localized text in the property text while the /main/0 paragraph contains only the localized text in the text_nl property but is completely missing the default text property.
Could you please provide the export of site configuration for site into which this content belongs?
Could you also please describe what language is set in the main bar on the page when editing the content and when the text disappears after the saving?
And last, could you also provide the url from the browser when having page open for editing?

If you are not comfortable sharing any of the requested info in public, feel free to move this issue to support to make it private.

Comment by Nils Breunese [ 04/May/10 ]

1. I attached the site definition.
2. I don't see a language setting in the main bar.
3. The URL of the edit dialog is http://localhost:8085/cluster/.magnolia/dialogs/vtkEpisodeIntro.html?mgnlPath=/tegenlicht/afleveringen&mgnlNode=de-ijsland-ervaring&mgnlParagraph=vtkEpisodeIntro&mgnlRepository=website&mgnlLocale=nl&mgnlRichE=true&mgnlRichEPaste=textarea&mgnlCK=1272979490160

I guess the problem could indeed be a localization problem. We actually don't intend to use more than one language on this site, but the site wasn't working with Magnolia 4.3.1 after the upgrade, so we modified the i18n node in the site definition. Maybe that was configured wrong?

It currently looks like this in our dev setup (as you can see in the attached site definition XML export):


i18n/
locales/
nl/
country: -
enabled: true
language: nl
class: info.magnolia.cms.i18n.DefaultI18nContentSupport
defaultLocale: nl
enabled: true
fallbackLocale: nl


The old i18n settings (currently in production on Magnolia 4.2.3) are:


i18n/
locale: nl


What should we change our dev setup to keep it compatible with the old settings? Again, we don't intend to use multiple languages on this site, it that makes things easier.

P.S. Maybe this issue should be moved to the support area?

Comment by Jan Haderka [ 04/May/10 ]

yes, feel free to move it to support (and fill in all relevant info when doing so).

And yes again, I think the configuration is the issue. As far as I can see your content is mixture of localized and non localized content (props with _nl suffix and without).
Since NL is your default language as well, what Magnolia will do is that it will map this lang to the default values (i.e. those without _nl) and will save those after editing (even with empty values).
While the rendering part will look for default language, find there is no default property (one w/o suffix) and will try to locate fallback language property (one with the _nl suffix) and when found it will render the content. After editing the paragraph, it will of course find those default properties, but they will be empty if not filled in explicitly and so the empty values will be rendered, causing seeming value disappearance.

The solution in this case should be to disable authoring i18n support.

Comment by Nils Breunese [ 04/May/10 ]

I'm not entirely up to speed on i18n support. What is the simplest thing I can do to make things work under 4.3.1 just like they currently work on our current production setup on 4.2.3? We don't need support for multiple locales on this website.

Comment by Jan Haderka [ 05/May/10 ]

The only thing you should need to do is to go to config:/server/i18n/authoring and set value of enabled to false.

Comment by Nils Breunese [ 05/May/10 ]

Ok, thanks. I'll try that tomorrow. I guess that disables i18n authoring globally. What if we only wanted to disable i18n authoring for this particular website and keep the option of using i18n for other sites open? I guess that involves modifying the i18n node in the site definition to use another class or something?

Comment by Jan Haderka [ 05/May/10 ]

Yes, the change will disable the i18n authoring support globally.
Currently there is no code to make this site aware, although I have something to that effect locally. I'll try to commit this code soon so you can test it.

Comment by Nils Breunese [ 06/May/10 ]

Setting enabled to false under config:/server/i18n/authoring indeed does the trick. Thanks.

Comment by Jan Haderka [ 06/May/10 ]

Glad to hear that. I'm closing this one as it is not really an issue, but a matter of configuration.
I'll also open an enhancement request for making authoring support configurable per site and link it to this issue.

Generated at Mon Feb 12 01:47:46 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.