Version 4 > Developer Guides > Content Model > Content Types

Content Types

Content Object Types

v3v4
native section content/section with no url
standalone section content/section with an url defined
page content/page
template content/template
library content/library
alternate content/page with a language and master defined
content content/content
blog content/blog
article content/article
comment content/comment
attachment content/content
catalog_category content/catalog
catalog_product content/product
event, evt content/calendar, content/event

Every content object has a type, which provides the properties of the content. Every type includes a Perl class to manage the type; all of these classes ultimately inherit from the base Content class. However, you can override and customize any of the core behaviours.

Among the recognized types are: section, page, library, template, content, blog, article, calendar, event, catalog, product, comment. These replace the similar objects in ExSite 3, and have comparable behaviours.

Types are extensible using the following procedure:

  1. add a new type to the content_type table, defining some of the basic rules:
    1. Class: the perl module that overloads Content.pm in managing content of this type (model/view)
    2. Plugin: the perl module that provides a specialized UI for managing content of this type (controller)
    3. Role: the default role of content of this type. This defines where the content comes from, and who is allowed to manage it. Editorial content is the regular website content; design is the templates and styles of the website; user is content that is contributed by website visitors.
    4. Publish As: file (eg. /foo.html), directory (eg. /foo/), or never (do not publish this content type). If publishing as a directory, the content may nevertheless be written to a file, index.html.
    5. Publish Method: static, dynamic, hourly, daily, weekly, or never. This is used as a default publish_rule if the content does not otherwise specify a rule.
    6. Publish Descendants: when publishing this content, select which sub-content items should also be published at the same time
    7. Navigation Type: page (treat these content objects as primary navigation destinations, like pages in the site map), item (treat these as secondary navigation destinations, like items in a list), none (this content is not a navigation destination)
    8. Display Type: raw (the content should be displayed in its bare form), formatted (the content should be built using a format, and inserted into a template), template (the content defines a complete HTML document, with CMS tags/codes for inserting other content), none (the content is not displayed)
  2. define the allowed relations with other types in the content_rel table
  3. install a Perl module that controls the behaviours of the new type; it can inherit from the closest existing type

Metadata

v3v4
page.title content.title
page.description metadata/description
page.keywords metadata/keywords
article.author metadata/author

Content objects have their own attributes class called Metadata, which can track arbitrary metadata for every content object. Each content type can define the metadata properties that are relevant to that type, using configuration settings like:

content.metadata.article.author.datatype = string 

Replace article with the content type, author with the property name, and datatype with any other dbmap parameter you want to set on the metadata property. Standard metadata properties are set up in $config{content}{metadata}, so you only need to define exceptions to those.

There are some metadata functions, which will return useful values even if the metadata has not been explicitly defined. These include: title(), author(), description(), and imeta() (see below).

The method editmeta() (and do_editmeta) automatically includes all type-specific metadata (and flags, below) when making and processing a form to edit a content object.

You can manually insert metadata values into your markup using <!--$meta_property_name-->, for example:

<meta name="author" content="<!--$author-->">

or

<p>Written by <!--$author--></p>

You can also auto-include metadata using simply, <!--$metadata-->. This will include <meta> tags for any metadata that you have set to be shown using a setting like this:

content.metadata.article.author.show =1

Auto-included meta tags will be shown if they have either an explicit or implicit value.

Generic Metadata

Generic metadata applies to all content types. We support three generic metadata schemes:

  • Dublin Core
  • OpenGraph (Facebook)
  • Twitter Cards

Explicit and Implicit Metadata

Metadata can explicitly set on a piece of content, or it can be implicitly inferred from other content settings.

There is some overlap between the properties of the generic metadata schemes, and with ExSite metadata. For example, all of them include a variation on description (including DC.Description, og:description, and twitter:description).  If one of these has been defined, but you request an undefined one, imeta() will pick a defined value and give that to you instead of undef.

Many of the generic metadata properties map roughly to properties that ExSite tracks in the CMS. These include things like authors, publication dates, images, URLs, MIME-types, dimensions, and others. If you request a generic metadata property that has not been explicitly set, but which has an implicit value, the implicit metadata function imeta() will return the implicit value.

The Modules::Content::metadata() method provides an interface to metadata management, which shows the implicit value as input placeholders if there is no explicit value defined.

If you set a metadata property to be shown automatically, the implicit value will be used if no explicit one is defined. That makes it easy to include standard meta tags such as twitter cards and have them auto-populate with no special effort.

Flags

Flags are boolean metadata. They can simply be checked off to activate them. Allowed flags are defined in $config{content}{flags}.

To test a flag setting, use:

if ($c->flag($flag_name)) {

To fetch all flag settings, use:

my %flag = $c->flags();

To set and remove flags, use:

$c->set_flag($name);
$c->unset_flag($name);