Annoying Special Character Flaw

dad7732 · Posted: Wed Dec 31, 2008 11:45 am

There appears to not be a simple workaround for this.

We use a lot of backslashes when writing FAQS using the editor, such as:

Quote:

C:\Documents and Settings\[User Name]\Application Data\Thunderbird\Profiles on Windows XP/2000

The special character function in the editor does now allow for a backslash \ because the character menu additon is \' which only displays the single quote ' in the finished FAQ.

The workaround is to manually type in C:\ which is the ascii representation for the backslash. That said and done, IF you save it and then come back to edit the FAQ in the editor you lose the \ and have to manually enter the &#92: for each backslash once again.

This seems to a problem in Windows and not necessarily the FCKEditor because it's the same annoyance in other Nuke versions as well that do not use FCK.

Suggestions ??

Cheers

kguske · Site Admin Joined: Jun 04, 2004 Posts: 5997

Is it just in the FAQ module?

dad7732 · Posted: Wed Dec 31, 2008 2:54 pm

Actually I renamed Content to FAQ in the Main Menu but it seems the problem exists anywhere that text can be entered and not just using the Advanced Editor. It does the same thing regardless if the Advanced Editor is enabled or not. I disabled it in rnconfig and then entered a path with backslashes in the footer and it stuck but when returning to preferences / footer the backslashes were removed. Must be something inherent in Nuke and not the editor or simply treated as an illegal character. Using \ will be permanent but just a nuisance.

I thought I remember seeing somewhere in nuke where you could enter acceptable characters in some preference/whatever.

Cheers

dad7732 · Posted: Wed Dec 31, 2008 3:05 pm

I just consulted my son the MySQL / UNIX guru and he mentioned that it has something to do with addslashes/stripslashes and SQL injection hacks, etc. where the \ has to be escaped ... or something like that ... he was too busy to make a reasonable explanation. But that little tidbit does ring a bell. But he did emphasize that it is NOT the editor that is a culprit.

Cheers

evaders99 · Posted: Wed Dec 31, 2008 4:31 pm

Correct, phpNuke has been badly implementing addslashes (rather its pretty consistent use of stripslashes for no reason) rather than checking whether magic_quotes is running or not.

dad7732 · Posted: Wed Dec 31, 2008 6:16 pm

I can turn magic_quotes on/off and it makes no difference either way.

Cheers

montego · Posted: Tue Jan 06, 2009 5:30 am

dad7732, need to know if this is Content or Content Plus (based upon your other threads). This can be fixed as I have fixed it in other modules, but it takes re-working of code. Sad

dad7732 · Posted: Tue Jan 06, 2009 8:18 am

It's everywhere that text can be entered, not exclusive to any module. However, yes I am using the Content Plus module to answer your question. I use that module to author my FAQS and most annoying when typing in paths with backslashes.

The only exclusion is posting in the forums.

spasticdonkey · Posted: Sat Jul 17, 2010 1:07 pm

I ran into a similar "Annoying Special Character Flaw" with the use of the special characters
¼
½
¾

which the preview feature (or posting the content) of the editor converts to
&frac14;
&frac12;
&frac34;

if I use
& # 188;
& # 189;
& # 190;
(forums where converting these so i added spaces)

¼
½
¾

it works as long as I don't preview it in the editor, but if I have to edit the document, the preview changes it back to
¼
½
¾

which ends up producing Sad

&frac14;
&frac12;
&frac34;

any ideas? btw, I'm using Content Plus for this...

Palbin · Posted: Sat Jul 17, 2010 5:33 pm

All I can suggest is to add an html_enitiy_decode() before the htmlentites() functions that are causing the problem. We can look into it more for RN 3.0 as we are moving to UTF-8 and redoing the filtering. Hopefully also the editor.

montego · Posted: Wed Jul 21, 2010 8:20 pm

Yup, definitely the passing of the data in the hidden fields within the Preview function. I have experienced that in various modules over the years. For the HTML Newsletter, in order to retain XHTML compliance, I had to encode at least the special characters that are in the hidden fields and then decode them on the way back "out" after the preview was done. Otherwise, if one leaves the special characters in the data, it breaks compliance. So, I believe even UTF-8 and the new filtering is not going to fix this IF you wish to remain XHTML compliant. Wink

spasticdonkey · Posted: Thu Jul 22, 2010 10:59 am

Well I've been scratching my head on this one...

this issue seems two fold... the FCKeditor can't handle (coverts it)
HTML Entity (decimal) & #189;

and the filtering that happens in Content Plus can't handle
HTML Entity (named) & frac12;

I tried editing the fckeditor to use
& #189;
with only partial success, and the fck javascript is pretty complicated so I don't think I can see that thru. Sad

I don't see any use of htmlentities() functions in content plus, but I did see use of

$text = real_escape_content($_POST['text']);

Code:

Is there some kses integration that I am missing? If so is there some reason these regex patterns would not match my fraction problem?

Code:

I need some way to represent fractions in my content pages for my current project, or it's going to turn into a real PITA.... as many pages will need to be edited several times... Sad