You are not logged in.
Hi folks,
I have recognized, that xinha doesn't change special chars like the german umlauts into their HTML-Equivalent.
Is there a config-flag to switch on this very basic feature?
Especially because all Editors produce HTML-Tags into the Editors-field there is no possibility to clean this with a general cleaning function in the CMS like htmlentities() in PHP. Otherwise all HTML-Tags are masked also.
Because of this it is really neccessary that special chars are already switched in the editor.
Does anybody know, how to realize it?
Greetings
Kpt|Kip
P.S.
There is also a problem with writing code into the Editor, if you want to show something like this
"This is an Anker-tag: <a href="sdfsdf">erfgergt.</a>"
it is impossible
Last edited by kptkip (2005-08-13 10:18:04)
Offline
Ticket 127 probably shows how you can add this ability to Xinha.
Offline
There's a problem with this topic.
First: my script didn't work at all after this implementation, like you can read there with other guys also.
Second: I dont believe that a Character-Type-Changing is helping in this topic.
To solve this Problem you need to convert ä to "ä" not to something like this "/ä/g".
I think that is not the right way to solve this - unfortunately.
By the way I dont understand, that not everybody has Problems with this. Because even writing code into the Editor doesn't work, not only the crazy german umlauts.
Ok so long!
Kpt|Kip
Offline
Hi folks,
I have recognized, that xinha doesn't change special chars like the german umlauts into their HTML-Equivalent.
xinha_config.sevenBitClean = true;
will approximatly do what you require, presuming you are using utf-8 encoding for Xinha (infact even if you're not it will probably do what you need).
There is also a problem with writing code into the Editor, if you want to show something like this
"This is an Anker-tag: <a href="sdfsdf">erfgergt.</a>"
it is impossible
I have not seen this behaviour, can anybody confirm?
James Sleeman
Offline
I have solved the problems with the Umlauts on my own - I extended the htmlEncode-function for them.
But there is also now the Problem with Code-Tags.
An Example:
I write the following text into the Editor:
lkjfböjäsfbüsfgbä
fkgbäß
<span style="background-color:#ff6d33">dfgfghjdfgjäkj</span>
sfgbägä
If i switch to the HTML-View there is the following code:
<p>
<span style="text-decoration: underline;"></span></p><p>lkjfböjäsfbüsfgbä</p><p>fkgbäß</p><p>
<span style="background-color:#ff6d33">dfgfghjdfgjäkj</span>
</p><p>sfgbägä<br />
</p>So it seems everything is ok. After saving the content to the DB the output from the CMS is correct. So the masked characters are saved in the DB and the Output is wonderful!
But after re-reading the Data into the Editor you can see the follwing code in the HTML-View:
<p>
<span style="text-decoration: underline;"></span></p><p>lkjfböjäsfbüsfgbä</p><p>fkgbäß</p><p>
<span style="background-color: rgb(255, 109, 51);">dfgfghjdfgjäkj</span>
</p><p>sfgbägä<br /></p>Offline
Sounds like you are not entizing the data you put between the <textarea> tags. As per the HTML standards, <textarea> content is #PCDATA. That means you must not put "raw html" in it, you must run it through an entizer, such as in php, htmlspecialchars()
<textarea><?php echo htmlspecialchars($myhtmltoedit) ?></textarea>James Sleeman
Offline
Hm that seems to be strange.
When the content is read out of the DB there is the conent entitized: there is ">" and not ">".
If i entitize them again you'll get > is this correct?
Greetings
Kpt|Kip
Offline
How did you preserve the German HTML entities, if you didn't add str = str.replace(/ä/g, "ä"); to htmlEncode to convert the lowercase ä to ä?
Offline
If you want the Xinha area to display (in HTML mode)
<hello & world>
then your textarea would look like
<textarea><hello & world></textarea>
This is the correct format as per HTML specifications - <textarea> has no valid tags that may appear in it and the content is defined as #PCDATA
James Sleeman
Offline
Hi gogo!
I have found the Problem.
I did it like you mentioned:
<textarea><? echo htmlspecialchars($MyString); ?></textarea>And now it works ;-) thnx for your help!
Now there is another problem :-):
Like in an parallel thread I mentioned I have problems with ImageManager and the Linker. They produce links and src's like:
http://www.myserver.net/test.html
or
/test.html
After saving and reloading the complete beginning until the first "/" has gone. Afterwards it looks like:
test.html
How can I solve this?
Greetings
Kpt|Kip
Offline
Try playing with these settings
// specify a base href for relative links
this.baseHref = null;
// we can strip the base href out of relative links to leave them relative, reason for this
// especially if you don't specify a baseHref is that mozilla at least (& IE ?) will prefix
// the baseHref to any relative links to make them absolute, which isn't what you want most the time.
this.stripBaseHref = true;
// and we can strip the url of the editor page from named links (eg <a href="#top">...</a>)
// reason for this is that mozilla at least (and IE ?) prefixes location.href to any
// that don't have a url prefixing them
this.stripSelfNamedAnchors = true;(eg xinha_config.stripBaseHref = false; )
James Sleeman
Offline
Hi gogo!
I have tried this:
xinha_config.stripBaseHref = false;
xinha_config.baseHref = null;
xinha_config.stripSelfNamedAnchors = false;But it doesnt work at all. Even wired combinations of baseURL+stripBaseHref and Anchors
I have seen the same thing in the htmlarea.js. even if I switch it of ("false") at this point - no reaction.
is there another way to stop this?
Greetings Alex
Offline