CKEditor is hiding text formatted with <code> tags. This only happens in edit view - it does not remove the tags, they are still there in plain text or source code view, and it renders properly when the content is viewed.

To replicate:

  1. Create a new node or edit an existing one
  2. Enter some text and format it as Computer Code using the formatting drop-down. (Everything should look fine at this point)
  3. Switch to plain text view
  4. Switch back to rich text view. The text that was formatted as computer code disappears.

The text will also not be visible if you save the node and edit again. It does not remove the actual code, it just hides it in edit view. I am attaching screenshots showing the edit view before and after switching to plain text view and back again and one showing source code view (So you can see the <code> tags are still there).

I am currently running CKEditor 3.6.4.

This does NOT happen with CKEditor when used with WYSIWYG module or in the CKEditor demo. This stack overflow question documents the same problem.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mkesicki’s picture

Status: Active » Closed (works as designed)

CKEditor module for durpal use this code in ckeditor.config.js file (close to line 26)
config.protectedSource.push(/<code>[\s\S]*?<\/code>/gi);
This use feature from CKEditor library: http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.config.html#.protectedSource.
Using this prevent code inserted into code tag from editing. Now CKEditor hide code/text from protectedSource in wysiwyg mode.
Here is ticket from CKEditor library https://dev.ckeditor.com/ticket/7822 which request 'better' solution for this.
Before change in CKEditor library, we can't do anything with this.

If you wish you can comment mentioned line in ckeditor.config.js file.
But remember that after this, code into code tags will be not protected against editing.

megan_m’s picture

I'm sorry, I'm not sure I undestand. The protectedSource lines were added to the ckeditor.config.js in this module? This isn't a standard configuration for CKEditor, corrrect? Is the intent to hide code (such as PHP, etc.) that are supposed to be executed by the browser?

So why are <code> tags being treated this way? The <code> tag is not meant to delineate actual code to be executed (as within <?php> or

) - it's a semantic tag to indicate that the enclosed text is computer code and should be rendered differently (not that the browser should try to execute it; it's an inline structural mark-up tag just like em, strong, etc.). I don't understand why you would want to protect it from editing.
mkesicki’s picture

Yes, this is not standard setting with code tag. The code in this tag will be not executed this is just to protect to change it. If this bother you, you can delete/comment this line.

bvanmeurs’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Closed (works as designed) » Active

The explanation for the configuration directive, from CKEditor documentation: "List of regular expressions to be executed on input HTML, indicating HTML source code that when matched, must not be available in the WYSIWYG mode for editing."
About the code tag, this is a phrase tag: http://www.w3schools.com/tags/tag_phrase_elements.asp
It is purely and solely used to indicate that the phrase should be marked up as computer code. It is never executed as computer code and has a very different meaning than the php tags (which are correctly configured).

In short, it is the same sort of tag as a kbr, tt, small, big, etc. tag. And there is no reason at all to protect against editing it. In fact, if this element is not supposed to be editable, why is it defined as a style in ckeditor.styles.js in the module?

mkesicki:
"If this bother you, you can delete/comment this line."

Thanks but please reconsider. This is a real bug imho, as there is a style available in the styles screen which simply does not work. If I would update ckeditor next time the ckeditor.config.js would be overwritten so I don't want to touch it.

Kind regards,
Bas

jcisio’s picture

While I agree with bvanmeurs, change that line might break current websites. So we could only change it if we are able to keep current websites from breaking. Besides, it's ok with your example, but I see people spanning the <code> text into multiple lines, and Drupal input filters do special processing on the <code> tags can lead to unexpected behavior, too.

bvanmeurs’s picture

The code tag actually doesn't work right now so how can we break something that already doesn't work? All we do is enabling users to edit the tag where there was no ability to do that previously. Nothing changes in current sites besides that users can now edit the contents of the tag within the CKEditor. Please specify where problems could occur in your opinion.

What kind of special things do Drupal filters do with the code tags? As far as I know the code tag has no special meaning besides styling so the code tag requires no extra filtering. The code in the tag is not dangerous as it won't get executed (it's not a script tag!).

jcisio’s picture

Ok "code" is an inline element (I confused it with the "pre" tag). So this change should be safe. Patch anyone? ;)

wwalc’s picture

Okay... the change will be as simple as removing this line from ckeditor.config.js:

config.protectedSource.push(/<code>[\s\S]*?<\/code>/gi); // Code tags

but... we have #1080270: [D6] Not formatting text between code tags and http://drupal.org/project/codefilter

In the meantime some could have started using http://drupal.org/project/geshifilter and <code> tags as well (I guess not only for inline content).

So by just removing it, we'd break the backwards compatibility. On the other side, I guess people should read changelogs and release notes... Opinions?

jcisio’s picture

That's what I said in #5. CODE was an inline element, however it is sometimes used as a block element, and it is a valid usage in HTML5.

I think it is not necessary to "protect" the code element, those filter modules should work without protection (please submit patches to those modules). However, breaking BC now is a problem.

hussainweb’s picture

The rationale in hiding <? ?> style code seems to be to avoid making changes to the code that is meant to be executed (when a PHP filter is enabled). It is not equivalent to the issue in #1080270: [D6] Not formatting text between code tags. However, I can see how it might break existing sites when ckeditor tries to 'clean up' code around the < code > tag, especially when it spans multiple lines. I am not sure if ckeditor has improved its handling of tags since the days of that issue.

At the same time, this is causing an issue as the code is not seen in the editor at all, creating confusion with the clients. If ckeditor has fixed the formatting problems (unless it was a Drupal issue, #1080270: [D6] Not formatting text between code tags was not very clear on this), then I think this is good for removal now. Otherwise, it seems at least a candidate for configuration.

I didn't understand the comment in #9 to "submit patches to those modules". Maybe I can look there and see if there is a potential problem in removing the line. Please elaborate.

jcisio’s picture

#10 I don't use any of those "problematic" modules, but I guess: when you use

<code>
line1
line2
< /code>

CKEditor turns it (which is normal) into:

<code>
<p>line1<br />
line2</p>
< /code>

However, when CKEditor format the markup, it might become:

<code>
<p>
  line1<br />
line2
</p>
< /code>

and those filter can't handle them. So I suggested to submit patches to eventually remove those extra spaces in those filters. Not quite easy.

Or can we just disable the markup custom formatting feature in CKEditor, disable the protectedSource for CODE and see if it works?

There is a blog post on that http://ckeditor.com/blog/Did-You-Know-CKEditor-Is-Web-Standards-Compliant, but I personally disable that custom formatting options in every site I build.

pauldawg’s picture

I echo the notion that this is not something that should be "protected". And the idea that it would break existing sites to fix this problem does not seem to be well founded. As for the workaround, I just cannot get it to work at all. No matter what I do the behavior does not change. Someone in another thread had suggested that copying the ckeditor.config.js into the theme folder and pointing to the copy and editing it might be part of the solution... haven't tried that. But others seem to be getting the workaround to work without it. Can anyone shed light on why the workaround works for some and not for others?

velvetpixel’s picture

removing:
config.protectedSource.push(/[\s\S]*?<\/code>/gi); // Code tags

from sites/all/modules/ckeditor/ckeditor.config.js is having no effect.

code tags with content entered in source render content correctly on actual page display but are not viewable in the wysiwyg when editing the page.

Also when adding code tags in the wysiwyg they are printed to the page for the saved page and not rendered as code tags by the browser.

We enter lots of code examples and I would like them to render correctly in the wysiwyg for our staff.

tahiticlic’s picture

Same need here, solution is given in last comments here : http://ckeditor.com/forums/Support/Content-inside-code-tags-not-shown-in...

  • Commit 0849a5b on 7.x-1.x by wwalc:
    Issue #1762328 by wwalc: IMPORTANT: <code> tags are no longer protected...
wwalc’s picture

Status: Active » Fixed

Backwards compatibility is important, but reasonable default configuration for new users as well.

With <code> as protected source it is impossible to use the new codesnippet plugin for CKEditor, so, considering that people already had issues with protecting <code>, it makes even more sense to change that decision.

Important: starting from 7.x-1.14 <code> is no longer protected, to protect it edit ckeditor.config.js and change:

// config.protectedSource.push(/<code>[\s\S]*?<\/code>/gi);

into

config.protectedSource.push(/<code>[\s\S]*?<\/code>/gi);

(remember to clear browser cache to see changes),

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.