Users can add as many custom data as they wish. However, Troglio reserved some common ones for the harmony of the relation between devs and writers.
Remind that all of those properties can be set either using TOML like type = recipe or using the Custom Fields Power-Up.
The best way to actually understand all these properties, is to deploy a test and see the result, but for the sake of proper centralized docs, here are all reserved properties with special meaning in Troglio:
is the card archived ? true or false
default: false (true when card is archived in Trello)
array of all attachments of a card
default: [] (empty array) filled when attachments are added in Trello
body of the card, edited in the description of the card AFTER the +++ section if any.
default: "" (empty string)
Note that although we promote usage of Markdown and HTML in the body, Troglio doesn't actually pre-processes it for developers. We are attached to freedom and flexibility while keeping some high expectations. For this reason, we kindly ask all developers to pre-process this body property through a proper markdown parser accepting HTML. We believe this is a promise that all user would like to see, at least in the Trello context. So we count on you to respect that :)
Why didn't we chose one parser for you ? Because Markdown parsers are not made equal and some can have complex strategies like allowing JSX, allowing Latex notations etc... Forcing one parser could penalize simpler users for no obvious reasons. Another thing is the approach using shortcodes. As already said, some parser allow JSX syntax into markdown which allow for use of shortcodes for users like <Twitter id="dgdiGIKGgf2" />. We believe these shortcodes strategy, if any, should stay into writers and developers hands, not Troglio.
For those who don't want to bother with this pre-processing part, please just take a look at our examples, you should not find any difficulties to implement that.
special field to ease work with react-static.
default: src/components/all.js
card's cover infos filled when an attachment is set as cover of a card in Trello.
default: {} (empty object)
date setup by user or card's due date
day of the due date in the form of 01, 02, ... 30, 31
kind of page, can be either home, list, single or settings.
this property is automatic and can't be changed
The rule is as follow:
single by default__home or __index it will receive the kind of list__home or __index in the a list named __root it will receive the kind of home__config or __settings it will receive the kind of settingsThis property is really interesting to help discriminate correct template. As a matter of fact, we advise developers to use these same names (single, list, home) as default templates for their apps/website and rely on this kind property if the template property fails or is not provided. (i.e: if user types template = existent and is not available, we can rely on kind to be either home, list, single or settings to provide a fallback template instead of a deceptive blank page...)
Trello labels (colored tags) attached to the card
default: [] (empty array)
name of desired layout
default: default
The layout represents the shell of an app/website. Usually, it is where we find elements shared across the whole site like headers, menus, footers, sidebar...
Inside the layout goes the template.
is the list of this card archived ?
default: false
members attached to the card
default: [] (empty array)
month of the due date in the form of 01, 02, ... 11, 12
relative path of the card, already slugified
default: /title-of-the-card
pattern to determine path
default: /:title
is the card considered "published" ?
default: false
position of the card relative to the board.
default: 0 (number)
name of desired template
default: default
The template represents a view of a page content with placeholders to be filled. Usually we find the body of the page in it. Combined with the layout, they represent the design of the website.
template lies inside the layout.
We highly recommend using kind as a backup for template. For instance, define at least 3 templates named list, single and home corresponding to the possible kind values (settings are never published so they don't need visual representation). When building the logic to select the correct template, we then something like:
// our templates objects in an array
var Templates = [
"default": ...,
"single": ...,
"list": ...,
"home": ...
];
// define template
var FinalTemplate = Templates[troglio.template] || Templates[troglio.kind];doing so, we explicitly define a variable FinalTemplate that will either be one of our existing templates, but if something goes wrong (e.g: user defines template = whatever which clearly does not exists) we stay safe by providing a fallback using the kind property which is locked and will always be either single, list or home.
title of the page
default: title of the card
type of content
default: post
Slugified title
default: title-of-the-card
year of the due date in the form of 2017, 2018...