Disappearing content in <code> tags

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.

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.

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

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.

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!).

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

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?

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.

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.

#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.

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?

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.

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

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