We have a number of pages, managed with WYSIWYG by untrained editors. We want them to be able to easily divide the page into sections, and for those sections to then be presented and themed specially.
This module lets you do this. It reformats the content in long text areas, adjusting the markup to break it into nested and classed sections, then applies layout techniques over top of that to improve presentation.
Unlike Javascript-only document-rewriters, this tool actually reformats the output markup. This means that anchors, search engines, browser history, accessibility, bookmarks, and other expectations about the web will continue to work! On the other hand, it does mean that there can be confusing differences between the markup entered in a WSYIWYG and the eventual result. Conflicts can exist, so take care.
To make chunking happen, just let the editors use H2, H3 tags to arrange their content, and the chunker system will intelligently use those cues to reformat the page. This can be enabled globally for all pages, or these alternate displays and the settings for them can be managed through D7 "View Modes". Even further, using display_suite.module "view mode per node" an editor can choose between a few options provided by the site design.
The Chunker process will insert in-page anchor IDs to the sections it manages. These will be automatically derived from the nearest heading, so may be slightly volatile to editorial changes. Editors can continue to create in-page anchors by assigning IDs to headings, manually, and these will be retained if detected.
Some of the formatters will expose a 'permalink' next to headings, for easier bookmarking for users.
As a semantic feature, the anchor IDs are applied to the section of content they are identifying. We to not add empty, placeholder anchor tags just for navigation, nor do we target the heading alone, if targeting a full section is more contextually correct.
Though it's not completely prohibited, it is strongly recommended that your content does not use inline H1s. Semantically, there should only ever be one H1 per page (the title) and H1s inside body copy are likely to produce inconsistent results. The algorithms inside chunker assume that h2 is the first exected heading level.
Some of the layout options available just with tools already in Drupal core are:
We also provide a few extra presentations like:
The primary supported methods for applying the Chunker behaviour are through Field Formatter Settings API, so the module works with a dependency on that.
However, similar processes can also be applied using Drupal text filters, which are closely related.
As either or both of these methods can be used, the chunker module does not absolutely require either of them in the [depencencies] list. But nothing will happen unless you do have at least ONE of them.
A quick, visual diagnostic tool can be enabled to help understand what
is happening with your markup rewrites.
Additional CSS styles will be added to the page to illustrate the div and
section nestings.
Set the Drupal variable chunker_debuglevel
to true to enable it.
drush vset chunker_debuglevel 1or
// settings.php $conf['chunker_debuglevel'] = TRUE;Set it to 0/FALSE again later to stop debugging.