When you write in html in the editor something like that: <p class="classname"> , when you edit again, after save it, the text you get is something like that:
<p class="\"classname\"">
And every time you edit this text, two \" are added this way:
<p class="\"\"\"\"\"classname\"\"\"\"\"">
Upshot: mind your view, top left in ckeditor, toggle Source properly. Not a bug in any version of OC itself. Not a bug but an irritation in ckeditor.
I haven't seen it in 1.5.5.1 or prior. However, I just noticed something. Are you are editing the html in the html view or in the Source view? You need to toggle the Source button. If you're editing html in the html view, then it will automatically double-up, because it is seeing the html as text along with everything that is not html. If you're editing html in the Source view, then it will automatically honor the html (with some changes of its own, see below) and show the result of the html when you take it out of Source view.
Consider this set (it's a triplet, third member has its own 3 lines):
<P><B>X<BR>Y<BR>Z</B></P>
<p><P><B>X<BR>Y<BR>Z</B></P></p>
X1
Y1
Z1
If in html view you do html such as
<P><B>X<BR>Y<BR>Z</B></P>
then in Source view you will see
<p><P><B>X<BR>Y<BR>Z</B></P></p>
and if you edit the letters to X1, Y1, Z1,
then the pattern will remain the same as above as you toggle back and forth between Source view and html view.
If INSTEAD IN SOURCE VIEW you do
[b]<P><B>X<BR>Y<BR>Z</B></P>[/b]
then in the html view you will see SINGLE-SPACED
X1
Y1
Z1
and upon resuming Source view you will see that your handiwork was automatically changed to
<p><strong>X1<br />
Y1<br />
Z1</strong></p>
If in Source view you do
<p><P><B>X<BR>Y<BR>Z</B></P></p>
then in html view you will see SINGLE-SPACED
X1
Y1
Z1
and upon resuming Source view you will see that your handiwork was unchanged from
<p><P><B>X<BR>Y<BR>Z</B></P></p>
If in html view you enter three rows as
X1
Y1
Z1
and then boldface that triplet,
then in Source view you will probably see INSTEAD DOUBLE-SPACED
<p><strong>X2</strong></p>
<p><strong>Y2</strong></p>
<p><strong>Z2</strong></p>
which if you edit on the spot in Source view down to single-spaced
<p><strong>X2</strong></p>
<p><strong>Y2</strong></p>
<p><strong>Z2</strong></p
will then in html view will still appear as the double-spaced mess above.
At that juncture you are left to begin wondering which bloody button fixes double-spacing, and you discover that Source mode forces the damned thing to single-space IF you put in <BR> where you want it, etc..
As I already I know what I am doing and I haven't an iota of tolerance for ckeditor or anything alike it pretending to interefere (one way or another wysiwyg usually means autotrashing), I actually defeat the damned thing outright and use an ordinary plain box, for exactly as much or as little, exactly worded html as I alone desire and command, both for Descriptions, and for mail out (in 1.5.0 through 1.5.5.1, alike). That provides for fairly absolute control of Descriptions. It also serves to keep ALL html OUT of mail rather than to make a pretty mess of mail that thousands of people, me included, will block (or strip to text) precisely because it contains any html at all. That is for security (notwithstanding the complete messes that mail makes of formats). I expect html in the browser, and flat plain text in the mail (where format is screwy in any event). A plain box allows me to enforce that -- the boxes come in pairs, the mates are the corresponding field-row intersects in the database.
I haven't seen it in 1.5.5.1 or prior. However, I just noticed something. Are you are editing the html in the html view or in the Source view? You need to toggle the Source button. If you're editing html in the html view, then it will automatically double-up, because it is seeing the html as text along with everything that is not html. If you're editing html in the Source view, then it will automatically honor the html (with some changes of its own, see below) and show the result of the html when you take it out of Source view.
Consider this set (it's a triplet, third member has its own 3 lines):
<P><B>X<BR>Y<BR>Z</B></P>
<p><P><B>X<BR>Y<BR>Z</B></P></p>
X1
Y1
Z1
If in html view you do html such as
<P><B>X<BR>Y<BR>Z</B></P>
then in Source view you will see
<p><P><B>X<BR>Y<BR>Z</B></P></p>
and if you edit the letters to X1, Y1, Z1,
then the pattern will remain the same as above as you toggle back and forth between Source view and html view.
If INSTEAD IN SOURCE VIEW you do
[b]<P><B>X<BR>Y<BR>Z</B></P>[/b]
then in the html view you will see SINGLE-SPACED
X1
Y1
Z1
and upon resuming Source view you will see that your handiwork was automatically changed to
<p><strong>X1<br />
Y1<br />
Z1</strong></p>
If in Source view you do
<p><P><B>X<BR>Y<BR>Z</B></P></p>
then in html view you will see SINGLE-SPACED
X1
Y1
Z1
and upon resuming Source view you will see that your handiwork was unchanged from
<p><P><B>X<BR>Y<BR>Z</B></P></p>
If in html view you enter three rows as
X1
Y1
Z1
and then boldface that triplet,
then in Source view you will probably see INSTEAD DOUBLE-SPACED
<p><strong>X2</strong></p>
<p><strong>Y2</strong></p>
<p><strong>Z2</strong></p>
which if you edit on the spot in Source view down to single-spaced
<p><strong>X2</strong></p>
<p><strong>Y2</strong></p>
<p><strong>Z2</strong></p
will then in html view will still appear as the double-spaced mess above.
At that juncture you are left to begin wondering which bloody button fixes double-spacing, and you discover that Source mode forces the damned thing to single-space IF you put in <BR> where you want it, etc..
As I already I know what I am doing and I haven't an iota of tolerance for ckeditor or anything alike it pretending to interefere (one way or another wysiwyg usually means autotrashing), I actually defeat the damned thing outright and use an ordinary plain box, for exactly as much or as little, exactly worded html as I alone desire and command, both for Descriptions, and for mail out (in 1.5.0 through 1.5.5.1, alike). That provides for fairly absolute control of Descriptions. It also serves to keep ALL html OUT of mail rather than to make a pretty mess of mail that thousands of people, me included, will block (or strip to text) precisely because it contains any html at all. That is for security (notwithstanding the complete messes that mail makes of formats). I expect html in the browser, and flat plain text in the mail (where format is screwy in any event). A plain box allows me to enforce that -- the boxes come in pairs, the mates are the corresponding field-row intersects in the database.
Thank you for your post, but all is a little confused. My issue is that I can not use class="xx" in source html because new "e"e"e"e"e"e characters are added every time I edit this text.
If you use " in text mode (not in source html) it will be changed by \\\\\\\\\\\".
In summary:
- In html source: " is changed by "e "e... many times as you edit
- In text mode: " is changed by \\\\\\" ... many times as you edit
How can work with double quote " without problems with CKEditor
If you use " in text mode (not in source html) it will be changed by \\\\\\\\\\\".
In summary:
- In html source: " is changed by "e "e... many times as you edit
- In text mode: " is changed by \\\\\\" ... many times as you edit
How can work with double quote " without problems with CKEditor
Okay, then where we ordinary use a comment-mark (single ' or double " in pairs) or escape each instance of those with a backslash (\, such as \' or \"), every "\\\\" is a string of escapes, and every ""e"e"e"e" is a string of comment-marks that do not necessarily need to be escaped. Something is therefore basically screwy -- it appears to be commenting and escaping itself out of control, and stuttering. (Probably an all-new problem! That's a winner, have we got a cupie-doll for you!)
Go to ckeditor.com/download/ for the most recent full package, download it, put it into place in /admin/view/javascript/ckeditor/, and presumably the problem will go away that simply. (You can back up the existing ckeditor by renaming its directory to ckeditor_OFF/ and inserting a new ckeditor/ directory before you plant the replacement new version.) The ckeditor with 1.5.5.1 doesn't work, must be replaced outright same way. Welcome to 1.5.6.0, too, perhaps.
If that does not work, then the problem is not the ckeditor package but something talking with it that might even be a (shudder) bug. Mispackaged ckeditor is a significant booboo but is not a bug of the same stripe as a primary bug in OC code.
Go to ckeditor.com/download/ for the most recent full package, download it, put it into place in /admin/view/javascript/ckeditor/, and presumably the problem will go away that simply. (You can back up the existing ckeditor by renaming its directory to ckeditor_OFF/ and inserting a new ckeditor/ directory before you plant the replacement new version.) The ckeditor with 1.5.5.1 doesn't work, must be replaced outright same way. Welcome to 1.5.6.0, too, perhaps.
If that does not work, then the problem is not the ckeditor package but something talking with it that might even be a (shudder) bug. Mispackaged ckeditor is a significant booboo but is not a bug of the same stripe as a primary bug in OC code.
Who is online
Users browsing this forum: No registered users and 24 guests