English, Nederlands
Doneer met PayPal

Handleiding

Blogartikelen

Op deze pagina

Over

Sinds: Nocterra 0.99.1

Terminologie: Technische Nocterra-termen blijven in deze Nederlandse handleiding onvertaald, zodat ze één-op-één terug te vinden zijn in de API, configuratie en article headers.

Nocterra is een CMS dat voornamelijk pages aanbiedt. Blog articles zijn een optionele mogelijkheid waarmee gedateerde inhoud kan worden gepubliceerd, automatisch indexes kunnen worden gegenereerd (bijvoorbeeld per jaar of categorie) en functies kunnen worden gebruikt zoals Definitions per article en automatische TOCs.

Handleidingpagina's in deze sectie

Dit deel van de handleiding beschrijft specifieke functies en hulpmiddelen voor het schrijven van blog articles. De meeste lezers zullen direct naar één van deze pagina's willen gaan:

Wat zijn blog articles in Nocterra?

Een blog article in Nocterra is een op bestanden gebaseerd inhoudsitem met metadata (auteur, publicatiedatum, categorie, tags, titel, beschrijving en optionele functie-instellingen) en één of meer taalspecifieke bodies. In tegenstelling tot systemen die primair als blog zijn opgezet, behandelt Nocterra articles als één inhoudstype naast pagina's. Daardoor kunnen articles zowel voor een traditioneel blog als voor een gestructureerde inhoudscatalogus binnen diepere sitepaden worden gebruikt.

In een gebruikelijke configuratie:

Article sources en detectie

articles worden gevonden door één of meer geconfigureerde bronmappen te doorzoeken. Dit gebeurt recursief: articles kunnen direct in de geconfigureerde map staan of in een willekeurige structuur van submappen, bijvoorbeeld gegroepeerd per auteur, onderwerp, jaar of project.

Geavanceerde configuraties kunnen:

Placeholders en case prefixes

Article text en geconfigureerde article templates kunnen placeholders bevatten in de vorm %naam%. Veelgebruikte voorbeelden zijn %title%, %author%, %category%, %tags% en date placeholders zoals %published%.

Tekstuele placeholders ondersteunen direct na het openingsprocentteken een optioneel case prefix:

PrefixEffect
_maak alleen het eerste teken een kleine letter (lcfirst)
$maak alleen het eerste teken een hoofdletter (ucfirst)
-zet de volledige waarde om naar kleine letters (strtolower)
+zet de volledige waarde om naar hoofdletters (strtoupper)

Zo gebruikt %title% de opgeslagen waarde ongewijzigd, zet %_title% alleen het eerste teken om naar een kleine letter, zet %$title% alleen het eerste teken om naar een hoofdletter, zet %-title% de volledige waarde om naar kleine letters en zet %+title% de volledige waarde om naar hoofdletters.

Voor achterwaartse compatibiliteit wordt een placeholder name die zonder expliciet prefix met hoofdletters is geschreven behandeld als de $-vorm; %Title% gedraagt zich bijvoorbeeld als %$title%. Het prefix verandert de weergegeven waarde en niet het article field dat wordt geselecteerd. Bij placeholders waarvan de uitvoer geen hoofdlettergevoelige tekst is, zoals %toc% en opgemaakte date placeholders, heeft een case prefix geen zinvol effect.

Routering, base en URL schemes

Nocterra behandelt de Blog-module niet als één URL namespace. Articles en gegenereerde indexes kunnen onder verschillende paden van het hoogste niveau voorkomen en verschillende categories of authors kunnen verschillende URL-indelingen voor articles gebruiken.

base is een dispatch-filter, geen prefix voor article URL's

base bepaalt voor welke eerste URL-path segments Nocterra de Blog-module moet proberen nadat de normale page lookup geen resultaat heeft opgeleverd. Het is in de eerste plaats een optimalisatie: requests naar niet-gerelateerde delen van de site hoeven daardoor niet door de article routing en de lookup van gegenereerde indexes.

Een waarde in base betekent dus niet “de URL waar het blog staat” en wordt niet automatisch voor urlScheme, toc_link of item-specifieke link gezet. Als articles of gegenereerde indexes onder meerdere paden op het hoogste niveau kunnen voorkomen, moeten al die eerste path segments in base staan.

$blog = array(
		...
		'base' => array(
			'nl' => array('/projecten', '/bijdragen', '/vrijwilligerswerk'),
		),
		...
	);

Met deze configuratie kan een request dat begint met /projecten, /bijdragen of /vrijwilligerswerk aan de Blog-module worden aangeboden wanneer het niet als normale page is opgelost. Een request dat met een ander pad begint niet. De werkelijke article- en index-URL's worden onafhankelijk daarvan bepaald door urlScheme, toc_link en item-specifieke link-instellingen.

Omdat de dispatch naar het eerste path segment kijkt, horen in base deze paden op het hoogste niveau te staan en niet een dieper pad alsof base een URL-prefix is.

Welk urlScheme wordt voor een article gebruikt?

De algemene article-configuratie kan één of meer urlScheme-patronen bevatten. Daarnaast kan een individuele author of category een eigen urlScheme hebben. Een tag kan geen article urlScheme hebben, omdat een article meerdere tags kan bevatten en er daardoor geen enkele tagwaarde is waarmee de article route eenduidig kan worden gekozen.

Nocterra kiest voor ieder article één set urlSchemes in deze volgorde:

  1. het volgens urlScheme_prioritize geprefereerde per-category of per-author scheme,
  2. de andere van category of author wanneer de geprefereerde geen urlScheme heeft,
  3. het algemene article urlScheme als fallback.

De standaardwaarde van urlScheme_prioritize is category. Een article kan die voorkeur in de article header overschrijven. Daardoor kan bijvoorbeeld het merendeel van de articles volgens category worden gerouteerd, terwijl een specifiek article voorrang geeft aan een author-specifieke route.

Een gekozen urlScheme kan zelf meerdere patronen bevatten. De eerste gegenereerde URL is de canonical article URL; de overige gegenereerde URL's zijn alternate article URL's die door de cache/routinglaag worden afgehandeld. De alternatieve patronen horen bij dezelfde gekozen set: Nocterra voegt de arrays van category, author en de algemene article-configuratie niet samen voor één article.

URL scheme keys

urlScheme-patronen gebruiken URL scheme keys tussen accolades. Dit zijn geen placeholders: ze worden specifiek voor het opbouwen van URL's resolved. Ondersteunde URL scheme keys zijn year, week, week0, month, month0, month_name, date, date0, date_ord, day, isodate, seq, title, category en author.

Een URL scheme key kan bewust naar een andere waarde resolven dan een placeholder met dezelfde naam. Zo geeft %author% in gegenereerde text de display name van de author weer en kan daarbij een link genereren, terwijl {author} in een urlScheme resolved naar de ingestelde urlname van de author, of naar een voor URL-gebruik genormaliseerde vorm van de author key wanneer geen author definition beschikbaar is. Op dezelfde manier resolved {category} naar de ingestelde urlname van de category of een genormaliseerde category key, en wordt {title} na toepassing van de title prefix en postfix omgezet naar een URL-waarde. URL scheme keys genereren geen display markup zoals links of tooltips.

URL scheme keys ondersteunen dezelfde optionele case-prefixsyntax als placeholders, maar blijven een afzonderlijk mechanisme met een eigen lookup en value generation:

PrefixEffect
_maak alleen het eerste teken een kleine letter (lcfirst)
$maak alleen het eerste teken een hoofdletter (ucfirst)
-zet de volledige waarde om naar kleine letters (strtolower)
+zet de volledige waarde om naar hoofdletters (strtoupper)

Het prefix staat direct na de openingsaccolade, bijvoorbeeld {_title}, {$title}, {-title} of {+title}. Een URL scheme key die zonder expliciet prefix met hoofdletters is geschreven wordt behandeld als de $-vorm; {Title} gedraagt zich bijvoorbeeld als {$title}.

urlMap

urlMap staat los van article URL schemes. Het koppelt een exact binnenkomend pad aan een ander target en wordt vóór de article routing gecontroleerd. Het is geschikt voor expliciete legacy redirects of andere bekende aliases die niet als algemeen patroon voor article routes moeten worden uitgedrukt.

Volgorde van routering

De volgorde is belangrijk wanneer URL's elkaar overlappen:

  1. Nocterra probeert eerst normale pages.
  2. Wanneer geen page is gevonden en het eerste path segment in base staat, wordt de Blog-module geprobeerd.
  3. Binnen de Blog-module wordt eerst urlMap gecontroleerd.
  4. Daarna worden article-routes uit urlScheme gecontroleerd.
  5. Daarna worden gegenereerde indexes gecontroleerd in de volgorde year, author, category en tag.

Een normale page kan daardoor bewust een pad onder een geconfigureerde base gebruiken. Binnen de Blog-module wordt een article route juist vóór de gegenereerde index pages getest. Vermijd onbedoelde URL-collisions en maak bewuste overlaps expliciet in het ontwerp van de site.

Voorbeelden van routering

Voorbeeld 1: een fotografieblog met één base en één urlScheme

Een conventioneel fotografieblog kan één dispatch-pad en één route voor articles gebruiken:

$blog = array(
		...
		'base' => array(
			'nl' => '/fotografie',
		),
		...
		'article' => array(
			'nl' => array(
				'urlScheme' => '/fotografie/{year}/{month0}/{title}',
			),
		),
		...
	);

Een article dat in september 2026 is gepubliceerd met de titel “Nachtfotografie in Haarlem” kan dan bijvoorbeeld resolven naar /fotografie/2026/09/nachtfotografie-in-haarlem. base zorgt hier alleen dat unresolved requests die met /fotografie beginnen aan de Blog-module worden aangeboden; de volledige article URL komt uit urlScheme.

Het blog kan onafhankelijk daarvan gegenereerde indexes onder hetzelfde pad aanbieden, bijvoorbeeld:

$blog = array(
		...
		'category' => array(
			'nl' => array(
				'toc_link'  => '/fotografie/categorieen',
				'toc_title' => '%category%',
				'toc_item'  => '%title%',
			),
		),
		...
		'tag' => array(
			'nl' => array(
				'toc_link'  => '/fotografie/onderwerpen',
				'toc_title' => '%tag%',
				'toc_item'  => '%title%',
			),
		),
		...
	);
Voorbeeld 2: een knowledge base met category-specifieke routing

Een knowledge base hoeft niet één model voor article URL's te gebruiken. Stabiele FAQ- en reference-content kan permanente title-based URL's gebruiken, terwijl tijdgebonden updates hun publicatiedatum in de URL kunnen opnemen. Alle drie kunnen onderdeel zijn van dezelfde collection van Blog articles.

$blog = array(
		...
		'base' => array(
			'nl' => '/kennis',
		),
		...
		'article' => array(
			'nl' => array(
				// Fallback wanneer category en author geen eigen scheme hebben.
				'urlScheme' => '/kennis/article/{title}',
				'rdfa'      => TRUE,
				'type'      => 'Article',
			),
		),
		...
		'category' => array(
			'nl' => array(
				'toc_link'   => '/kennis',
				'toc_title'  => '%category%',
				'toc_item'   => '%title%',
				'list_title' => 'Knowledge base',
			),
		),
		...
		'categories' = array(
			'FAQ' => array(
				'nl' => array(
					'name'          => 'Veelgestelde vragen',
					'urlname'       => 'faq',
					'link'          => '/kennis/faq',
					'urlScheme'     => '/kennis/{category}/{title}',
					'type'          => 'WebPage',
					'article_title' => '%title%',
					'toc_title'     => 'Veelgestelde vragen',
					'toc_item'      => '%title%',
				),
			),
			'Reference' => array(
				'nl' => array(
					'name'          => 'Naslag',
					'urlname'       => 'naslag',
					'link'          => '/kennis/naslag',
					'urlScheme'     => '/kennis/{category}/{title}',
					'type'          => 'WebPage',
					'article_title' => '%title%',
					'toc_title'     => 'Naslag',
					'toc_item'      => '%title%',
				),
			),
			'Updates' => array(
				'nl' => array(
					'name'          => 'Updates',
					'urlname'       => 'updates',
					'link'          => '/kennis/updates',
					'urlScheme'     => '/kennis/{category}/{year}/{month0}/{title}',
					'type'          => 'NewsArticle',
					'article_title' => '%title%',
					'toc_title'     => 'Updates',
					'toc_item'      => '%published% — %title%',
				),
			),
		),
	);

In deze configuratie resolved {category} via de urlname van iedere category. De twee stabiele categories produceren daardoor paden onder /kennis/faq/ en /kennis/naslag/, hoewel hun geconfigureerde scheme-template hetzelfde is. Bij Updates resolved {category} naar updates en worden year en month toegevoegd. Het algemene scheme /kennis/article/{title} blijft als fallback beschikbaar voor categories of authors zonder eigen scheme.

Een author kan hetzelfde mechanisme gebruiken. Zo kunnen articles van een documentatieteam een author-specifieke route krijgen wanneer author routing wordt geprefereerd:

$blog = array(
		...
		'authors' = array(
			'Documentation Team' => array(
				'nl' => array(
					'name'      => 'Documentatieteam',
					'urlname'   => 'docs',
					'link'      => '/kennis/auteurs/docs',
					'urlScheme' => '/kennis/{author}/{title}',
					'type'      => 'Organization',
				),
			),
		),
	);

Of het author- of category-scheme wint wanneer beide bestaan wordt bepaald door urlScheme_prioritize. Tags doen bewust niet mee aan deze selectie van article routes.

Volledige Blog-configuratie en articlevoorbeeld

Onderstaand voorbeeld is één complete, samenhangende Blog-configuratie voor een tweetalige fotografiesite. Het is geen uitputtende opsomming van iedere optionele Blog-setting; het laat zien hoe de belangrijkste configuratieniveaus in één praktische configuratie samenhangen. Er wordt vanuit gegaan dat en en ja al als languages zijn geconfigureerd.

Het voorbeeld gebruikt bewust twee base-paden per language. Portfolio-articles staan onder het ene pad en gedateerde journal-articles onder het andere. Daarnaast worden de algemene article-defaults, gegenereerde indexes, twee categories, vijf tags en één author geconfigureerd.

$blog = array(
		'source'						=> '/data-articles/',
		'base' => array(
			'en'						=> array('/photography', '/journal'),
			'ja'						=> array('/shashin', '/nikki'),
		),
		'addTOCToMenu'					=> FALSE,
		'urlScheme_prioritize'			=> 'category',
		'year' => array(
			'en' => array(
				'toc_link'				=> '/journal/archive',
				'toc_name'				=> 'Archive',
				'toc_title'				=> 'Photography in %year%',
				'toc_item'				=> '%published% - %title%',
			),
			'ja' => array(
				'toc_link'				=> '/nikki/archive',
				'toc_name'				=> 'アーカイブ',
				'toc_title'				=> '%year%年の写真',
				'toc_item'				=> '%published% - %title%',
			),
		),
		'author' => array(
			'en' => array(
				'toc_link'				=> '/photography/authors',
				'toc_name'				=> 'Photographers',
				'toc_title'				=> 'Photography by %author%',
				'toc_item'				=> '%published% - %category% - %title%',
			),
			'ja' => array(
				'toc_link'				=> '/shashin/authors',
				'toc_name'				=> '撮影者',
				'toc_title'				=> '%author%の写真',
				'toc_item'				=> '%published% - %category% - %title%',
			),
		),
		'category' => array(
			'en' => array(
				'toc_link'				=> '/photography/categories',
				'toc_name'				=> 'Categories',
				'toc_title'				=> '%category%',
				'toc_item'				=> '%published% - %title%',
			),
			'ja' => array(
				'toc_link'				=> '/shashin/categories',
				'toc_name'				=> 'カテゴリー',
				'toc_title'				=> '%category%',
				'toc_item'				=> '%published% - %title%',
			),
		),
		'tag' => array(
			'en' => array(
				'toc_link'				=> '/photography/tags',
				'toc_name'				=> 'Tags',
				'toc_title'				=> 'Articles tagged %tag%',
				'toc_item'				=> '%published% - %category% - %title%',
			),
			'ja' => array(
				'toc_link'				=> '/shashin/tags',
				'toc_name'				=> 'タグ',
				'toc_title'				=> '%tag%の記事',
				'toc_item'				=> '%published% - %category% - %title%',
			),
		),
		'article' => array(
			'en' => array(
				'urlScheme'				=> '/journal/{year}/{month0}-{date0}-{-title}',
				'rdfa'					=> TRUE,
				'type'					=> 'BlogPosting',
				'article_title'			=> '%title%',
				'article_subtitle'		=> 'By %author% - %published% - %category%',
				'article_footer'		=> 'Tags: %Tags%',
				'article_toc_title'		=> 'In this article',
			),
			'ja' => array(
				'urlScheme'				=> '/nikki/{year}/{month0}-{date0}-{seq}',
				'rdfa'					=> TRUE,
				'type'					=> 'BlogPosting',
				'article_title'			=> '%title%',
				'article_subtitle'		=> '撮影者: %author% - %published% - %category%',
				'article_footer'		=> 'タグ: %Tags%',
				'article_toc_title'		=> 'この記事の内容',
			),
		),
		'categories' => array(
			'Portfolio' => array(
				'en' => array(
					'urlScheme'				=> '/photography/{category}/{-title}',
					'rdfa'					=> TRUE,
					'type'					=> 'Article',
					'name'					=> 'Portfolio',
					'urlname'				=> 'portfolio',
					'link'					=> '/photography/portfolio',
					'article_subtitle'		=> 'Photograph by %author%',
				),
				'ja' => array(
					'urlScheme'				=> '/shashin/{category}/{seq}',
					'rdfa'					=> TRUE,
					'type'					=> 'Article',
					'name'					=> '作品',
					'urlname'				=> 'sakuhin',
					'link'					=> '/shashin/sakuhin',
					'article_subtitle'		=> '撮影: %author%',
				),
			),
			'Journal' => array(
				'en' => array(
					'urlScheme'				=> '/journal/{year}/{month0}-{date0}-{-title}',
					'type'					=> 'BlogPosting',
					'name'					=> 'Journal',
					'urlname'				=> 'journal',
					'link'					=> '/journal',
				),
				'ja' => array(
					'urlScheme'				=> '/nikki/{year}/{month0}-{date0}-{seq}',
					'type'					=> 'BlogPosting',
					'name'					=> '撮影日記',
					'urlname'				=> 'nikki',
					'link'					=> '/nikki',
				),
			),
		),
		'tags' => array(
			'night' => array(
				'en' => array('name' => 'Night photography', 'link' => '/photography/tags/night'),
				'ja' => array('name' => '夜景', 'link' => '/shashin/tags/yakei'),
			),
			'street' => array(
				'en' => array('name' => 'Street photography', 'link' => '/photography/tags/street'),
				'ja' => array('name' => 'ストリート写真', 'link' => '/shashin/tags/street'),
			),
			'architecture' => array(
				'en' => array('name' => 'Architecture', 'link' => '/photography/tags/architecture'),
				'ja' => array('name' => '建築', 'link' => '/shashin/tags/kenchiku'),
			),
			'film' => array(
				'en' => array('name' => 'Film photography', 'link' => '/photography/tags/film'),
				'ja' => array('name' => 'フィルム写真', 'link' => '/shashin/tags/film'),
			),
			'tokyo' => array(
				'en' => array('name' => 'Tokyo', 'link' => '/photography/tags/tokyo'),
				'ja' => array('name' => '東京', 'link' => '/shashin/tags/tokyo'),
			),
		),
		'authors' => array(
			'aiko-tanaka' => array(
				'en' => array(
					'type'					=> 'Person',
					'name'					=> 'Aiko Tanaka',
					'urlname'				=> 'aiko-tanaka',
					'link'					=> '/photography/authors/aiko-tanaka',
					'urlScheme'				=> '/photography/by/{author}/{-title}',
				),
				'ja' => array(
					'type'					=> 'Person',
					'name'					=> '田中 愛子',
					'urlname'				=> 'aiko-tanaka',
					'link'					=> '/shashin/authors/aiko-tanaka',
					'urlScheme'				=> '/shashin/by/{author}/{seq}',
				),
			),
		),
	);

De Engelse en Japanse URL schemes hoeven niet hetzelfde te zijn. In dit voorbeeld gebruiken de Engelse routes de article title, terwijl de Japanse routes {seq} als laatste identifier gebruiken. Daarmee is het voorbeeld niet afhankelijk van automatische romanisatie van Japanse titles: de URL-structuur wordt per language expliciet geconfigureerd.

Dit voorbeeld laat ook de semantische scheiding tussen de article fields zien. De author-key identificeert één geconfigureerde author. De category kiest één primaire category en kan zowel routing als rendering veranderen. Tags zijn een lijst met geconfigureerde concepten die ieder een eigen name en link kunnen hebben. Keywords blijven vrije, taalspecifieke metadata en kunnen daardoor gedetailleerder, meer search-oriented of per taal anders geformuleerd zijn. Deze fields worden bij het genereren van article metadata wel met elkaar gecombineerd, maar zijn niet onderling uitwisselbaar.

Een bijpassend article file

Onderstaand minimale article gebruikt de configuratie hierboven. De body is bewust vrijwel leeg, zodat juist de semantische rollen in de header zichtbaar blijven:

author			= aiko-tanaka
published		= 2026-09-19
category		= Journal
tags			= night, street, tokyo
keywords:en		= Shinjuku night photography, handheld low-light photography, neon reflections, Tokyo streets
keywords:ja		= 新宿 夜景写真, 手持ち夜景撮影, ネオンの反射, 東京 ストリート写真
title:en		= Neon after the rain
title:ja		= 雨上がりのネオン
description:en	= A short night-photography entry from Shinjuku after rainfall.
description:ja	= 雨上がりの新宿で撮影した短い夜景写真の記事です。

[body:en]
<P>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</P>


[body:ja]
<P>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</P>

Hier is aiko-tanaka de configuratie-key van de author, Journal de ene category-key en zijn night, street en tokyo tag-keys. De twee keywords-velden zijn onafhankelijke taalspecifieke text en hoeven niet één-op-één overeen te komen met de geconfigureerde tags. “Neon reflections” kan bijvoorbeeld nuttige article metadata zijn zonder dat daarvoor een tag-definition hoeft te bestaan.

Authors, categories, tags en index pages

De Blog-configuratie heeft twee samenhangende niveaus voor years, authors, categories en tags:

Tags, keywords, keys en URL names

Tags en keywords zijn in Nocterra verschillende mechanismen. Een article heeft één category, één author en nul of meer geconfigureerde tags. Tags verwijzen naar entries in de Blog-configuratie tags en kunnen daardoor een eigen display name, link, urlname en gegenereerde indexes hebben. keywords zijn daarentegen vrije, taalspecifieke article metadata. Het zijn geen tag definitions en ze maken geen tag indexes aan.

Nocterra gebruikt de term slug niet en kent geen Blog-setting slug. De configuratie gebruikt in plaats daarvan expliciete keys en expliciete properties. De array key identificeert een author, category of tag; name is de display name; urlname is de URL-gerichte waarde waar het betreffende mechanisme die gebruikt; en link is een expliciete destination/index-URL. Daardoor blijven display name, configuratie-key en URL-waarde afzonderlijke begrippen.

Settings op een index type

De enkelvoudige definitions voor year, author, category en tag kunnen onder andere deze settings bevatten:

SettingBetekenis
toc_linkURL van de gegenereerde top-level index voor dit type. Wordt ook als basis gebruikt voor relatieve per-item link-waarden.
toc_nameNaam die wordt gebruikt wanneer de gegenereerde index aan de navigatie wordt toegevoegd.
toc_titleDefault title/template voor de gegenereerde article index van een individueel item.
toc_itemDefault template voor een article entry in de index van een individueel item.
year_toc_item, author_toc_item, category_toc_item, tag_toc_itemContext-specifieke alternatieven voor toc_item.
toc_prologue, toc_interlude, toc_epilogueContent rondom de gegenereerde item-index.
toc_titleLevelHeading level voor de gegenereerde item-index.
toc_orderbyOrdering expression voor articles in de gegenereerde item-index.
list_title, list_item, list_prologue, list_interlude, list_epilogue, list_titleLevelBepalen de top-level gegenereerde lijst van alle years/authors/categories/tags.
Settings op individuele authors, categories en tags

Individuele items erven defaults voor de index-opmaak van hun enkelvoudige configuratie en kunnen deze overschrijven. Vooral de volgende settings zijn belangrijk:

SettingAuthorCategoryTagBetekenis
namejajajaDisplay name die in gegenereerde text en indexes wordt gebruikt.
linkjajajaURL voor de gegenereerde index of bestemming van deze author/category/tag. Relatieve waarden worden onder de toc_link van het type resolved; site-absolute en externe URL's worden eveneens ondersteund.
urlnamejajajaURL-gerichte naam. Voor authors en categories is dit ook de waarde die {author} of {category} in article URL schemes gebruikt.
urlSchemejajaneeOverschrijft de article routing voor articles van deze author of category. Tags kunnen geen article scheme leveren omdat een article meerdere tags kan hebben.
toc_title, toc_item, context-specifieke *_toc_item, toc_prologue, toc_interlude, toc_epilogue, toc_titleLevel, toc_orderbyjajajaOverschrijven de presentatie van de gegenereerde index voor dit specifieke item.
typejajaneeBij een author het RDFa type van de author, standaard Person. Bij een category het semantische type voor articles binnen die category.
rdfaneejaneeBepaalt RDFa-generatie voor articles binnen deze category.
article_title, article_subtitle, article_footerneejaneeCategory-specifieke templates voor het renderen van articles.
article_toc_location, article_toc_minLevel, article_toc_maxLevel, article_toc_subordinate, article_toc_quote, article_toc_tail, article_toc_trailing, article_toc_stop, article_toc_title, article_toc_titleLevelneejaneeCategory-specifieke defaults voor de automatische article TOC.
page, atjaneeneeAanvullende author metadata: een page URL en, waar van toepassing, de organisatie-/employer-relatie die voor RDFa author metadata wordt gebruikt.

Dit onderscheid is belangrijk: categories zijn niet alleen labels waarmee articles worden gegroepeerd. Een category kan zowel bepalen waar zijn articles worden gerouteerd als hoe die articles worden gerenderd, waaronder het semantische type, RDFa-gedrag, title/footer templates en defaults voor de automatische TOC. Authors kunnen article routing en author metadata beïnvloeden. Tags bieden classificatie en gegenereerde indexes, maar bepalen niet de article routing of article rendering.

Gegenereerde indexes zijn optioneel. Een handmatig onderhouden page kan dezelfde navigatie aanbieden zonder dat een gegenereerde index is ingeschakeld. Zo'n page hoeft niet in de Blog-configuratie voor te komen, tenzij de URL daarachter ook door Blog routing moet kunnen worden afgehandeld.

Caching en renderen

Nocterra gebruikt meerdere caches om het genereren van inhoud efficiënt te houden:

articles worden gerenderd door metadata, taalspecifieke bodies en geconfigureerde functies te combineren, zoals het vervangen van placeholders en optionele functies per article. Algemene opslag- en cachingconcepten worden beschreven in de handleidingsectie Storage engine.

Veelvoorkomende toepassingen

Omdat articles optioneel zijn en hun plaats door URL schemes wordt bepaald, kunnen ze op verschillende manieren worden gebruikt. Enkele veelvoorkomende voorbeelden: