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.
The toolbar above the content entry box for [bold] [italic] etc is missing for the text format 'Restricted HTML' but present for 'Basic HTML' and 'Full HTML'. See three illustrations.
This seems to be because CKEditor is not defined as the text editor for this format on the text formats and editors page. See final illustration. I can't see any reason why this should be desired, so I report it as a bug!
Tested on a completely fresh, default installation of D8 beta 15 on OpenSuse 13.2
Comment | File | Size | Author |
---|---|---|---|
basic HTML.png | 15.38 KB | AFowle | |
restricted HTML.png | 17.5 KB | AFowle | |
full HTML.png | 17.12 KB | AFowle | |
text formats and editors.png | 23.66 KB | AFowle |
Comments
Comment #2
AFowleComment #3
Wim LeersThis is intentional :)
Restricted HTML is the text format to be used for anonymous users, for comments. For simple comments, a Text Editor is A) overkill, B) bad for front-end performance. Sites can choose to enable it if they prefer.
Comment #4
Wim LeersI hope that adequately answered your question!
In any case, thank you for reporting your concern so clearly! Keep the feedback coming :)
Comment #5
AFowleWim
Thank you for your courteous response. I'm not quite done yet though! If you don't want a toolbar and are aiming this at anonymous users, you don't need to have a list of html tags in the instructions under the entry box (see my original illustratilon). If you allow tags, they should be entered through nice buttons.
If you don't want tags, don't allow them and don't list them.
I have marked this as active again, but left it flagged as "support request" because we surely don't need to fight over that.
Adrian
Comment #6
Wim LeersBut why not allow tags? Most blogs allow for example emphasis tags but fail to list which tags are allowed. It looks cleaner, but the user is left wondering and guessing.
This is nothing new. Drupal has always done this.
Comment #7
AFowle"We have always ..." is not an excuse for not fixing it now. The other formats have buttons but not help text - and thereby look much neater. This one format is the only that has an untidy looking help text (for the uninitiated) instead of buttons. It looks like a programming error rather than a feature to me.
Comment #8
Wim LeersI see your point.
But "those buttons" are powered by a WYSIWYG editor, and that's inherently large to download. Several hundred kilobytes. So it requires further discussion, for which we don't have time just before RC1. Recategorizing as a feature request for the next minor release.
Comment #9
AFowleI can live with the idea of shunting this down to 8.1. I would not like to be the guy who holds up 8.0 RC1 either!
I had not considered the size of the editor I confess. Just out of interest, would it be possible for the server to check the presence of the editor and the download speed? It could then download either the several hundred Kb of editorif a fast connection or only the list of allowed tags on a slow connection. Out of scope of the current issue, I know, but another kind of "responsive".
Comment #10
Wim Leers#9: no, reliably determining the network connection quality is an unsolved problem in 2015.
Comment #11
thpoul CreditAttribution: thpoul as a volunteer commentedIMHO Restricted HTML is a text format which should not need to have an editor to go with as the tags allowed are completely optional. Also it is mostly used in comments as #3 states or in forms made for user input (ex. a CV submission form).
Authors usually have access to the Basic HTML format (sometimes even the Full HTML format). I personally don't see the need to have CKEditor load for anything less than Basic HTML. Especially on the front end because of the unnecessary performance loss.
Basic HTML and Full HTML should only get the CKEditor, Restricted HTML and Plain text should only get a textarea. It's a fair split.
Comment #12
Wim LeersPer #11, I'm going to go ahead and mark this as , because:
Thanks for raising the concern though! It's much appreciated. Please keep the feedback coming. This issue will remain useful for future readers, to document this rationale explicitly.