| v3 | v4 |
|---|---|
| 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:
| v3 | v4 |
|---|---|
| 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 applies to all content types. We support three generic metadata schemes:
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 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);