I have just looked into yet another site plagued by wildly non-conformant area names. Perhaps the original theme developer justified this on the basis that it was a single site theme, so didn't need to follow best practices for area names. But in doing so they unknowingly laid the groundwork for future headaches that ripple across themes, page types, and diagnostics.

I have touched on this before, specifically Do Everything in Packages and Get Code Ready for the Marketplace. Let’s dig deeper into why standard area naming is essential.

Recap - what happens

Between page types

Within a site, an administrator needs to change a page type, such as from a 2 column layout to a right sidebar layout. If the area names are inconsistent, blocks in the now unused area names disappear.

Between themes

If two themes don't use consistent area names, when the site theme is switched, area names that don't exist in the new theme disappear with their blocks. However, rather than just one page changing type, this could leave hundreds or thousands of pages affected.

Why change theme?

Sites often go for a theme refresh after a few years. If the themes and page types are not consistent on the use of area names, some or all of their content disappears into zombie land. In practice, for large sites the opposite occurs. Any new theme has to be modified to adopt the previous theme's area names.

Its not just older sites updating. Self-build sites often begin from a first install with a default theme such as Atomik or Elemental. Having started with a bit of content they then look for a theme from the marketplace. If the theme does not conform to standard area names, some or all of their existing content disappears when they load the new theme.

For any site, when there is a problem, does it originate in the theme or elsewhere? A simple test is to briefly flip into a core theme and see if the problem still exists. We instantly halve where we need to look for the problem. But if substantial parts of the page disappear into zombie land, the swapping theme diagnostic complicates analysis rather than simplifying it.

Where do these blocks go?

When an area name is no longer used, the area still exists in the database. The blocks in the area haven't disappeared completely, they remain associated with these unused area names and linger as unseen orphans. 

If the page type or theme are changed back again, the area name reappears, the blocks are resurrected and nothing is lost. But unless the theme swap was a temporary diagnostic, we may really want to keep the new theme or page type.

In the block add panel, when a page contains orphan blocks an extra option is made available alongside Blocks, Stacks, Clipboard, Containers. The new option Orphans is shown with a list of the orphan blocks. Hence blocks lost with areas can usually be recovered or removed permanently from the Add panel, but many don't realize they can do this. Meta blocks such as containers and layouts cannot be recovered, so linger as zombies in the database forever.

Its not an easy problem to solve. Concrete CMS edit mode can only work out which blocks and areas are not displayed after the page is displayed in edit mode, when the actually rendered blocks can be checked off against everything shown with a page and those left are the orphan . Orphan blocks cannot be found with a simple database query.

How big is the problem?

Back when Concrete CMS was version 5.6, I did an investigation of area names and page type names used by marketplace themes. I found the variation to be absolutely insane. Page type and area name insanity. From the 115 themes I examined, there were:

• 422 area names
• 102 different page types

Since Concrete v7+ the PRB has tried to toughen up on this for marketplace themes, so the problem is nowhere as big as it used to be, but it is still there. Remember, this is the curated Concrete CMS marketplace. Out in the wild where bespoke themes are developed for single site use and are not subject to PRB review, divergence form convention is unconstrained.

What should areas be called?

The areas below are compatible with the core Atomik theme

The global area Navigation needs some explanation. This is usually a full width area used for the Top Navigation block. When themes that don't use the Top Navigation block, the convention is 3 areas: Header Site Title, Header Navigation, Header Search.

Global areas don't matter so much because the blocks in them can be edited globally and old global areas continue to be listed in the dashboard. They don't accumulate go zombie and accumulate orphaned blocks in the same way as regular areas do. The critical names to be consistent with are the regular areas used when editing pages.

Some common scenarios 

A two column page type

Suppose a page type has 2 equal columns. It would be easy to call them some variation of Left and Right. But should the page type later be swapped to a sidebar, or the theme be swapped to one that doesn't have a similarly named two column page type, both these columns become zombies.

Hence it is better to continue to call the equal width areas Main and Sidebar. It doesn't matter which way round they are, as long as those names are used. The content of these areas now translates to other themes and page types.

Left or right sidebar

A similar consideration needs to be made for page types with left or right sidebars. Keep these as a simple Sidebar and Main, or Main and Sidebar. That way a change of page type doesn't loose anything and the Sidebar just flips to the other side.

Three columns

Entire pages with 3 editable columns are not so prevalent on modern web sites because it soon looses any correlation between columns when collapsed to a mobile view. Nevertheless, it can be useful. For example, an article page type with a short byline left, the article in the center, and some supplementary information to the right.

Following on from the above, we already have names Main and Sidebar for two of the columns in a 3 column layout. These are best used for the columns that are expected to have most content. A name for the third column can then be semantic, though personally I would call it something that doesn't imply content or position in case of future rearrangement. So Sidebar2 or Supplemental can be good. However, if the page type doesn't already have a Page Header area, calling the second sidebar Page Header can be useful and works with the byline usage of such a third column.