Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Write & search content having special characters like german umlauts

Go to End

5 Posts   3936 Views


Community Member, 15 Posts

19 February 2009 at 8:19am

I found a posting of a user who had problems to search umlauts within a silverstripe page. The problem comes from a setting which should be set in the tinymce configuration. Without this configuration directive tinymce will alway replace umlauts lik 'Ãœ' with their aeuivalent 'Ü' The search tool later on expects to read UTF-8 and can not find the content or displays the content double encoded (here: Ü) in the results list.

Attached you can find a patch which solves this problem. After applying the patch you have to to a /db/build?flush=1 and save all pages containing umlauts in the content again.

Best regards,

Index: SilverStripe/cms/javascript/tinymce.template.js
--- SilverStripe/cms/javascript/tinymce.template.js (revision 5774)
+++ SilverStripe/cms/javascript/tinymce.template.js (working copy)
@@ -40,6 +40,7 @@
safari_warning : false,
relative_urls : true,
verify_html : true,
+ entity_encoding : "raw",
valid_elements : "+a[id|rel|rev|dir|tabindex|accesskey|type|name|href|target|title|class],-strong/-b[class],-em/-i[class],-strike[class],-u[class],#p[id|dir|class|align],-ol[class],-ul[class],-li[class],br,img[id|dir|longdesc|usemap|class|src|border|alt=|title|width|height|align],-sub[class],-sup[class],-blockquote[dir|class],-table[border=0|cellspacing|cellpadding|width|height|class|align|summary|dir|id|style],-tr[id|dir|class|rowspan|width|height|align|valign|bgcolor|background|bordercolor|style],tbody[id|class|style],thead[id|class|style],tfoot[id|class|style],-td[id|dir|class|colspan|rowspan|width|height|align|valign|scope|style],-th[id|dir|class|colspan|rowspan|width|height|align|valign|scope|style],caption[id|dir|class],-div[id|dir|class|align],-span[class|align],-pre[class|align],address[class|align],-h1[id|dir|class|align],-h2[id|dir|class|align],-h3[id|dir|class|align],-h4[id|dir|class|align],-h5[id|dir|class|align],-h6[id|dir|class|align],hr[class],dd[id|class|title|dir],dl[id|class|title|dir],dt[id|class|title|dir]",
extended_valid_elements : "img[class|src|alt|title|hspace|vspace|width|height|align|onmouseover|onmouseout|name]"


Community Member, 97 Posts

19 February 2009 at 3:04pm

Wouldn't it make more sense to leave the saved data alone and, instead, convert special characters in the search term into HTML entities before doing the search? Just a thought.


Community Member, 15 Posts

19 February 2009 at 9:50pm

As silverstripe is fully utf-8 enabled, there is no need to encode any characters in a special way. Only for html-output purposes the &, < and > characters in text sections must be html-encoded (otherwise the browsers would try to interpret them as html-elements). That's exactly what the setting does (see ).

Storing ans searching works nicely with the patch, and users should be able to handle content in all charactersets without any workarounds.



Community Member, 3 Posts

30 June 2009 at 2:49am


thank you for the tipp. As Silverstripe uses its own configuration, you can set such config vars in the "HtmlEditorConfig"-Class (sapphire/forms/HtmlEditorConfig.php). All settings are defined in the protected property "$settings". They will be packed and sent to the browser.

Note and Question: Its not good style to edit lib-files, because you will get some trouble to upgrade to newer Versions. Is there a chance not to edit a lib file, and create a project related configuration?


Community Member, 15 Posts

30 June 2009 at 3:02am

you are right, but it's the only way I have found to handle that issue; I have opened a ticket suggesting to set that as default for future releases...