Hide

Caveats Regarding Use of the Drupal Editor

hide
Hide

          Help and Guidance 2021: Original page as at time of Drupal conversion

Check for Change to ckEditor version 5 

Hide

Introduction

This page reflects some issues about the way the ckEditor works and interacts with other features. It was written during the transition to Drupal.

Notes

 

Part of the rationale of the move to the Drupal CMS was to reduce the maintenance load on the maintainers, and allow them to focus on the page content rather than its structure, by eliminating the need to be skilled in html editing, i.e. to move toward rich-text (WYSIWYG) page creation and editing.

There will at times be a need for gsr, the search for and replacement of a specific text string in multiple places within (conceptually) selected counties, parishes, files and/or file extensions, but in reality within selected Drupal nodes.

Nevertheless, there is still benefit in having some basic understanding of HTML, as it is on the underlying HTML that editors actually do their work.

The web page as seen by the end user is the result of an HTML file being delivered  (upon request) to the user client device by the GENUKI server, and then being rendered on the device by the user's browser.

The HTML file is simply a text string, a sequence of characters, the content of the page, starting with <html> and ending with </html>. This string is interspersed where appropriate with other character groupings (HTML TAGS, etc), which instruct the browser how to treat the content and produce the required display.

A GENUKI page that has just been converted is such a string, a single line of text that if opened in e.g. Windows Notepad without word wrap will show as a single line across and beyond the full width of the screen. This is the "page source". All the line breaks have been removed.

When opened in the Drupal editor, relevant sections of this content are displayed in the edit windows of the various sections of the Drupal page, with the options to edit in HTML or in rich-text variously set according to the page type defaults and the user's default editing options. However it is edited, when saved, the edited source becomes the new "page source", whilst the original source becomes the first revision (i.e. the previous version of the page).

If the editing is done in HTML (rich-text disabled), the saved text is saved as edited. However if the editing is done in WYSIWYG (rich-text enabled), the edits are saved using the HTML code decided on by the WYSIWYG editor, which may be different that the maintainer may have chosen in HTML mode. (Typically, inserting a new line using WYSIWYG could result in the inclusion of <p>&nbsp;</p> when using the Enter key, or <br> when using shift+Enter.) In fact the WYSIWYG editor rearranges (in effect "standardises") a page's HTML when first used on that page, e.g. regarding the use of new lines to format the HTML code. This does not effect the page's visual appearance, but can cause searches of the HTML, such as are performed by Bulk Operations Search and Replace, that are based on the original - perhaps rather idiosyncratic - HTML format to fail mysteriously.)

Other issues that may be encountered include centred text. When imported to Drupal, some sections of centred text bring with them the <center> and </center> tags. This text displays as centred in the WYSIWYG editor, but will typically just show as indented in the final page. The solution is to remove these tags in HTML mode, then switch to WYSIWYG, select the text and click the "Centre" button. This also happens when text is included using cut and paste using WYSIWYG.

A similar issue may arise (again with centred text), with the problem being <blockquote> and </blockquote> tags. Again the solution is to remove the tags in html mode and centre the text in WYSIWYG as above.

Selection of nodes for Search and Replace is done within "Bulk Operations".