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.
To immediately try it out, a number of working examples are provided at /admin/help/chunker/examples
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 "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.
Unlike widget-based editing paradigms like Paragraphs or Bricks modules
(where page content is constructed as a set of sub-components or individual elements),
This module supports treating large sections of content primarily as native text or markup,
(possibly with rich content elements embedded inside it)
and adds visual structure automatically, after the user has done their editing.
The intent of this approach is:
Opinion:
While HTML-in-database may not be the perfect paradigm for long-term storage of your valuable content,
it is superior to many-elements-in-many-database-fields-strung-together-with-unique-&-elaborate-relationships-determined-ad-hoc-by-the-visual-design.
CMSs have come and gone, and will continue to come and go.
Depending on the circumstances, it is likely that your clients content will one day have to be migrated out of
the system you are putting it in to.
It may need to be displayed in a device or format that is not the 3-column brick layout that the page layout
elements currently provide.
Consider the process that will have to happen if your website was valuable enough to still be running 10 years in the future.
Chances are, the tools to be used to do that job in the future may not be the 2015 version of Drupals field layout API - but by some
chump with a totally different language who can just reach far enough back into the past to use an SQL data extraction tool.
If that legacy migration task can extract well-structured data from the body field in one query, your future migration path has the potential to be robust. If the data model they have to re-create from the DB, or even from the API is significantly complicated (to the point where it requires so much outdated domain-specific knowledge as to be virtually proprietary) ... the only reasonable migration path will be raw screen-scraping, and all the crud that will come with that.
For this reason - because I don't hate the future "me"s (or the future robots) that will need to make sense of things - I believe that text-first is the more responsible long-term storage method for content that is primarily prose.
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 (however, still less volatile than auto-generated numeric ids). Editors can continue to create in-page anchors by assigning IDs to headings, manually, and these will be retained and used by preference, if detected.
Some of the formatters will expose a 'permalink' next to headings (eg a subtle '#' symbol on hover), 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 tags just for navigation, (<A>norexic </A>nchors) nor do we target the heading alone if the content is what we intend to refer to. 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.
Real-world content comes in all flavours of "tag soup", and this module tries to make sense of that as intuatively as it can. Things work a lot better if your source content nests headings correctly, with H3 below H2, and H4 consistently being used only below H3, etc. However, Even if you do jump from H2 to H4, that should still be allowed without panic.
Text content found before the first heading is generally expected to be intro text. In most formatting modes, that means it is not enwrapped in any section style, though a dedicated div may be added if needed. The option for that can be found in 'advanced' settings.
Some of the layout options available just with tools already in Drupal core are: (Each of these links should produce a working demo in action)
We also provide a few extra presentations like:
The primary supported methods for applying the Chunker behaviour are through the Field UI, so the module works with 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 [dependencies] 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 config-set chunker.settings chunker_debuglevel 1
or
// settings.php
$config['chunker.settings']['chunker_debuglevel'] = 1;
Set it to 0/FALSE again later to stop debugging. As this is developer-only, there is no UI for this.