Content Types

• Content Types
  • Configuration
  • Using Content Types in your templates

Content Types

Content Types are used by Tapestry to segment source files into Collections. The LoadContentTypes uses the site configuration to identify and load Content Types for the current workspace.

By default Tapestry ships with two Content Types baked in: default and blog. You can make changes to the blog Content Type via overwriting its configuration within your sites configuration file. The default Content Type is used when a source file doesn't fit into any other configured Content Type.

Configuration

'content_types' => [
    'blog' => [
        'path'       => '_blog',
        'template'   => 'blog',
        'permalink'  => 'blog/{year}/{slug}.html',
        'enabled'    => true,
        'taxonomies' => [
            'tags',
            'categories',
        ],
    ],
],

Name: You can see from the above that the key for the Content Type configuration is the name of the content type, in the case of the above this is "blog".

Path: The path is where Tapestry should look to collect files for this Content Type. We use a path beginning with an underscore so that it's ignored for regular parsing, that way the file only gets added to this Content Type.

Files within path can be any that are supported by Tapestries Content Renderers.

Template: This is the file name of the template that Tapestry should use for each content found in path. This file is looked for within the source/_views folder. In the example above Tapestry will parse each file found within source/_blog and for each file inject its rendered content into source/_views/blog.phtml. To give an analogy to WordPress, the Template is the same as single.php in the template hierarchy.

The template property can be over-written on a per file basis, if for example you want to use a certain view to wrap some posts but not others.

Permalink: This is the permalink that gets injected into every File within a Content Type. As per the template this property can also be over-written on a per file basis.

Enabled: When set to false Tapestry will ignore the Content Type and not parse any files that would be segmented into its Collection.

Taxonomies: This array contains a list of the taxonomies that you are using within this content type. Tapestry looks for these keys within the Front Matter of each file in the Content Types path and adds them to the taxonomy collection if found.

Using Content Types in your templates

Looking at the Tapestry Blog Theme example repository you will see that within the source folder there is a folder named blog:

webroot/
└── source/
    └── blog/
        ├── categories/
        |   └── category.phtml
        ├── categories.phtml
        ├── tags.phtml
        └──  index.phtml

index.phtml: This demonstrates a blog archive page that is available via the url example.com/blog. You can see that it uses the main collection from the blog Content Type. This means that the variable $blog_items containing an array of all the blog collection items will be injected into the template.

tags.phtml & categories.phtml: These files demonstrate index pages that list all the tags and categories within the blog Content Type. Each using blog_tags & blog_categories respectively they have the variables $blog_categories_items and $blog_tags_items injected into their templates.

The main difference between using the main Collection of a Content Type as opposed to one of its taxonomy collections is that the later does not inject a plain array containing instances of the ViewFile class. Instead it contains a multi-dimensional array with the outer array keys being of all the classifications used for that Taxonomy.

For example:

[
    'fish' => [ ... ],
    'mammals' => [ ... ],
    'birds' => [ ... ],
    'insects' => [ ... ],
]

categories/category.phtml: This template demonstrates using the blog categories taxonomy collection and passing it to the TaxonomyArchiveGenerator and PaginationGenerator Generators to generate a paginated archive of blog items organised by category.

In this example the original category.phtml never gets directly parsed to an output file and is instead used as a template by the TaxonomyArchiveGenerator to generate a set of pages one for each classification. Without the PaginationGenerator this would result in an output similar to the following:

build_local/
└── blog/
    ├── fish/
    |   └── index.html
    ├── mammals/
    |   └── index.html
    ├── birds/
    |   └── index.html
    └── insects/
        └── index.html

For each category a page will be generated with the $blog_categories variable injected containing an array of ViewFiles for each File within that taxonomy classification. When paired with the PaginationGenerator then each classification will be paginated resulting in output similar to the following:

build_local/
└── blog/
    ├── fish/
    |   ├── 3.html
    |   ├── 2.html
    |   └── index.html
    ├── mammals/
    |   └── index.html
    ├── birds/
    |   ├── 2.html
    |   └── index.html
    └── insects/
        ├── 4.html
        ├── 3.html
        ├── 2.html
        └── index.html

Now instead of accessing items via $blog_categories you do so via the injected Pagination class via the $pagination variable. For more information on how to set up and use the pagination functionality, click here.