On Mar 23, 2010, at 16:21, Jan Haderka wrote:
> I know there is not a reason to disable it on public. But I'm sure there will > be people who enable it on author and _forget_ to enable it on public, > specially if having multiple dev/test/prod environments. The same will also accidentally use the same database, or a different PM, different sets of modules, whatever else. Not sure why this particular setting should be any different from others. > I wanted to see if we are able to detect it or not. > Correct me if I'm wrong, but if that flag is not enabled the normalization > filter will not attempt to normalize the name so it might not be rendered > properly for/from all the clients, right? The rendering is not impacted by normalization; the "only" thing normalization is needed for is because some clients (safari, webdav, ...) take the liberty to change the normalization form for names (form fields, paths), and when that happens, it doesn't match the server anymore (path not found, ...) -g > Jan > > From: Luca Boati [mailto:[email protected]] > To: Magnolia Dev-List [mailto:[email protected]] > Sent: Tue, 23 Mar 2010 16:11:07 +0100 > Subject: Re: [magnolia-dev] UTF-8 support & activation & public instances > > Hi Jan > Everything is fine and a should not platform specific issue. > When UTF-8 support is enabled on an instance, if you create a node all utf-8 > chars will be accepted by Path.getValidatedLabel(..). > When a node is rendered, SimpleUrlPattern is used, and since 4.3.1 the new > regexp in SimpleUrlPattern is "." (all chars), so even if UTF-8 support is > not enabled, magnolia is able to render those nodes. > > Btw when UTF-8 support will be considered stable, the property > magnolia.utf8.enabled will be removed, and utf8 will be the default charset. > > If I enable utf-8 on author instance, there is no reason to disable it on > public instance.. > > Luca > > 2010/3/23 Jan Haderka <[email protected]> > While playing with the new UTF-8 support I tried the following: > - enable support on the author but not on the public. > - create a page that contains weird char in the name and activate it. > > The result: > - activation went fine > - the page name is correct in the public site > - The url is rendered properly and page is accessible. > > So as far as I can tell everything is fine, but I suspect that is just > platform specific. We have that flag for a reason so I would be more > comfortable to get a warning in the log when such page is accessed rather > then letting it slip completely silently and having to hunt for it later. > Opinions? > > Jan > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > > > > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
