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,
Johannes

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]"
   });

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 http://wiki.moxiecode.com/index.php/TinyMCE:Configuration/entity_encoding ).

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

Johannes

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

Johannes