Tags automatically appended even though default state is disabled

I too have this issue, did some research and figured out that it's because this new feature ( found in Notes for 1.3 ):

#1050118: Added better support for Line break converter. CKEditor is now able to load properly content where new line characters were used
Added better support for Line break converter. CKEditor is now able to load properly content where new line characters were used to create new lines

Following piece of code responsible for that ( ckeditor/includes/ckeditor.utils.js )

/**
 * Converts \n to <br />
 * It in no way tries to compete with Line break converter filter
 */
Drupal.ckeditorEnterModeConvert = function(enterMode){
  if (enterMode == 1)
    return {startTag: '<p>', endTag: '</p>'};
  if (enterMode == 2)
    return {startTag: '', endTag: '<br/>'};
  if (enterMode == 3)
    return {startTag: '<div>', endTag: '</div>'};
  return {startTag: '', endTag: ''}
}

I didn't find where to disable this feature ( is there such possibility?.. ), but this is definetly a bug. As temporal solution you can try to remove from ckeditor/includes/ckeditor.utils.js mentioned above code and wait for fix. Looks like you can't just remove this piece of code, it breaks Switch to Rich Text editor link. On my site I'll try to use ckeditor.utils.js from 1.2, but I don't know yet if there will be any side effects from this...

It looks like the problem is with block of code from line 355 in ckeditor.utils.js. This enables CKEditor for all text-areas for which CKEditor is enabled and for other text areas it binds ckeditorLinebreakConvert to all text areas of their parent form submit handler.

  $("textarea.ckeditor-mod:not(.ckeditor-processed)").each(function () {
    var ta_id=$(this).attr("id");
    if ((typeof(Drupal.settings.ckeditor.autostart) != 'undefined') && (typeof(Drupal.settings.ckeditor.autostart[ta_id]) != 'undefined')) {
      Drupal.ckeditorOn(ta_id);
    }
    else {
      $(this).parents('form').bind('submit', function() {
        $(this).find('textarea').each(function() {
          $(this).val(Drupal.ckeditorLinebreakConvert($(this).val()));
        });
      });
    }
  });

I am not sure if it makes sense to bind the ckeditorLinebreakConvert code to convert all textareas inside forms that contain at least one textarea with class ckeditor-mod. Also $(this).parents('form').bind would bind the function multiple times to the same form if it has multiple text areas that are supposed to have ckeditor.

A fix to the problem of converting line breaks in text areas not supposed to be converted could be to change

$(this).find('textarea').each(function() {

with

$(this).find('textarea.ckeditor-processed').each(function() {

This still does not solve the problem of binding the function multiple times to the same form.

I have also attached the patch for this fix.

The related issue is #1050118: Added better support for Line break converter. CKEditor is now able to load properly content where new line characters were used.

CKEditor is not disabled in your case, it is just in the plain text mode. I don't know what is the problem with P and BR automatically inserted as said in #0?

If this happens for textarea with CKEditor disabled, it's another history.

If you never want to use CKEditor for those textareas, disable them. If not, you imply that tags are allowed. I'd say that is the correct settings.

You missed the point. CKEditor is never disabled in your case. It just works in "plain text mode".

1.2 worked in a misconfigured scenario and didn't work in other correctly configured scenarii (that you are possibly not aware of). That's why I suggested this change. Read the linked issue for more information.

I have the same problem at the block edit screen, for the first field CKeditor is active, for the second field
it is explicity excluded. Even so I get my <front> in the second field converted to
<p>front</p> or on another site, to <front><br/>.
See also http://drupal.org/node/1102518

#1102518: Editing Blocks, the second field is modified. is a separate problem, even I'm not sure if it is a problem.

When CKEditor is attached to a textarea, it is implied that you will get HTML tags. The state (disabled/enabled) is not important, the property (plain or rich text) is important, and this property does not change.

The only case where it matters is when the property can change (between, e.g. Full HTML and Markdown). CKEditor for D7 and CKEditor 2.x for D6 support it. When the property changes, the editor is detached from the textarea, not just disabled. It's completely different.

The purpose of adding tags here is to provide a extremely light editor that is compatible with the full CKEditor, so that CKEditor can be disabled (save 200 KB data transfer) but the basic behavior is kept, as explained in #1050118: Added better support for Line break converter. CKEditor is now able to load properly content where new line characters were used. This problem is way bigger than just simply adding one more line in the settings page (that you didn't want to do).

Should I add the textarea for e.g. the meta description of nodewords to the exclusion path to avoid the loading of ckeditor.util.js (btw, *.edit-nodewords-description appears to be in the excluded paths for 1.2...)? Same for the body of any custom block I add?

Is ckeditor in essence truly disabled if the textarea is explicitly excluded (assuming we use exclusion, not inclusion logic)?

Yes, yes and yes for these 3 questions.

If you don't expect to have HTML tags in a textarea, exclude it from CKEditor, not just disable CKEditor by default (and users are allowed to enable it).

However, in a deeper thought, you can choose your strategy: blacklist (exclude textareas that you don't want) or whitelist (only include textareas that you want). CKEditor currently supports both of them. And wildcards are your friends, too.

I hope that it's clearer now.

I think @jcisio says everything in this topic, so i closed it - again really thx for support and help.

Greetings

Thing is, the mini linebreak converter will append tags even to code that's already html markup, such as list items (li). But I assume one must submit with the UI enabled to avoid that?

That's the way I want, so I submitted the patch with that behavior. It converts line breaks to HTML tags if there is no BR or P tags. Why? Someone wants to format his/her content, without having to enable the full editor. Before there are two extremes: one must enable the editor, or he/she must enter the whole tags (look at the P tags) like:

<p>I <em>like</em> this one!</p>
<p>That one, too.</p>

If not, all text becomes a mess. Now, it's simpler:

I <em>like</em> this one!

That one, too.

In one phrase: if user is expected to enter rich text and there is no BR or P tags, add them!

A little more info: I use this patch in my site for a few months (1 million monthly visitors, thousands of comments submitted since there), with CKEditor disabled by default in the comment textarea, and there has not a single problem.

Yes, it works as designed. You never have your content in the rich text editor, because it always wraps your content with P or DIV. So, that textarea should be excluded from CKEditor.

I have the same problems as #19, disabling is not always a solution - sometimes you need both raw and CK editor on a text field.
I would be nice to have something like the fix from #2 as a configurable option - of course I can patch the code, but its better to have "standard" versions.

I closed this issue, because @Morn problem was fixed here #1102518: Editing Blocks, the second field is modified.

Greetings

I had a need similar to @marktheshark. A site had previously used CKEditor exclusively, but they are now moving to the markdown filter. I set the text area to not start CKEditor on page load, so content managers can use markdown with the option to user CKEditor for older content. This worked except that CKEditor added line break markup which prevented markdown from rendering correctly.

I can see other use cases for wanting to edit in plain text mode and keeping CKEditor as an option for more complex editing or editing by less experience content editors.

I created a sandbox for a module, ckeditor_plaintext at http://drupal.org/sandbox/shrop/1537206. This module gives a setting in each CKEditor profile, "Add line break HTML markup when switching from plain text editor to rich text editor" with options (Yes or No). The default is "Yes" so that CKEditor works as currently designed out of the box. See attached file below for a screenshot of the setting.

I would love to see this added to the CKEditor project, but if not, it is available for those who need the functionality. Also, let me know if there is anything I can do to improve the module. Thanks!