Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Currently, the "enable/disable by default" option is sitewide. However, sometimes it should be customizable per textarea level. For example, I want the comment text area is CKEditor-disable by default, but the node edit textarea enable by default.
I can already do this with the following code at the page bottom:
<script type="text/javascript">
if (typeof(Drupal.settings.ckeditor.autostart) != 'undefined' && typeof(Drupal.settings.ckeditor.autostart['edit-comment']) != 'undefined') {
delete Drupal.settings.ckeditor.autostart['edit-comment'];
}
</script>
However, the "Switch to richtext/plaintext mode" is hard coded in the module and is side wide, so I can't change it when I override the disable/enable status of an textarea. I'd love to see an option to choose which element is enable/disable by default, like with the current simplified toolbar feature.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | ckeditor-1063986-enable-default-9.patch | 3.72 KB | jcisio |
Comments
Comment #1
dczepierga CreditAttribution: dczepierga commentedU want to remove editor from this textarea, or u want only disable it but can enable by pressing "Switch to rich text editor" ?
Greetings
Comment #2
jcisio CreditAttribution: jcisio commentedI want to disable it, and user can enable by pressing "Switch to rich text editor". Something like the Default state in the CKEditor settings (the first element of "Editor appearance"), but this option will be more granular, per textarea instead of per profile.
Thinking about it more, I see that in Force simplified toolbar on the following fields (in Visibility settings), we should have more control. The hierarchy will be:
- Global profile
- - Profile 1: for role 1a, role 1b...
- - - Default settings (what we currently have)
- - - Textarea 1.1: exception for element id 1.1a, 1.1b... (a list)
- - - * those textareas have a few more settings that override the default settings, such as: simplified toolbar, default state, rich text editor toggle, toolbar expanded (generally, settings in the "visibility" section).
- - - Textarea 1.2: exception for element id 1.2a,...
- - Profile 2: for role 2a
What we add here is the 1.1, 1.2... settings.
Comment #3
dczepierga CreditAttribution: dczepierga commentedOk i mark it as work to do... i try to do this with version 2.x of CKEditor module where I want to add support for input formats...
Greetings
Comment #4
jcisio CreditAttribution: jcisio commentedThis feature should be profile-dependant, not format-dependant. In 2.x can a format have two or more profiles? This issue is about to have many profiles in a format. Differently saying, multiple textareas with the same format, can have different CKEditor settings, which is currently available, even fairly minimal (full toolbar and "force simple toolbar").
Comment #5
DudleyDooRight CreditAttribution: DudleyDooRight commentedHas this been addressed as of yet? We'd like to allow users to toggle between either but currently, base content contributors cannot enable Full HTML (to edit table data for instance), if they are limited to Filtered. I would like their default to be filtered but if necessary to be able to select Full.
Comment #6
bkosborneI'm interested in this behavior, being able to change the default state on a field-by-field basis. My use case is that I'm using the faq field module which allows an arbitrary amount of textareas be added with multi value field. If there are more than ~10 fields populated and I go to edit the node, the page loads very slowly because 10 CKEditors have to start up. I'd rather make the user click the button to enable the editor.
Comment #7
bkosborneEh, here's a workaround I found that I'm OK with: https://drupal.org/comment/5601364#comment-5601364.
Comment #8
jcisio CreditAttribution: jcisio commentedReopen because I don't think there will be 6.x-2.x or 7.x-2.x. New features will still be added in the 1.x branches.
Comment #9
jcisio CreditAttribution: jcisio commentedAlmost 4 years pass and I happen to need it again. Here is a patch for the 6.x branch.
Comment #10
jcisio CreditAttribution: jcisio commentedCommitted #9 on 6.x-1.x.
Comment #12
jcisio CreditAttribution: jcisio commentedIn D7 it would be per text format. I don't know to add a per-element or per-field setting without messing everything up. So it won't get into 7.x branch.
Maybe we can add an attribute to the element to override the settings (similar to '#wysiwyg'), but I have no plan now.