Configuration

Site Sets (TYPO3 13.4+)

mpc/mp-core is an aggregator that depends on mpc/mp-core-base plus all feature sets. Including only mpc/mp-core in your site is sufficient. If you need fine-grained control, include mpc/mp-core-base and pick individual feature sets.

Set roles

 

Important: When authoring a custom Site Set, set dependencies: [mpc/mp-core-base, …] — never mpc/mp-core. Depending on the aggregator from a child set causes a SetRegistry recursion deadlock.

 

mpc/mp-core-base dependencies

Required: typo3/form, typo3/redirects, typo3/indexed-search

Optional (used when installed): georgringer/news-recordlinks, georgringer/news-sitemap, mpc/mpc-vidply, mpc/mpc-rss

Enabling Sets

Backend: Site Management -> Sites -> Sets tab -> enable and order sets.

YAML (config/sites/[site]/config.yaml):

base: 'https://example.com'
rootPageId: 1
dependencies:
  - mpc/mp-core

Or cherry-pick individual sets:

dependencies:
  - mpc/mp-core-base
  - mpc/mp-core-container
  - mpc/mp-core-seo

Site Settings

Editable via Site Management → Sites → Settings or config/sites/[site]/settings.yaml.

Regenerate after changing settings.definitions.yaml / settings.yaml:

node Documentation/scripts/sync-site-settings.mjs

Core (shared — mpc/mp-core / registered via mpc/mp-core-base)

Site Settings definitions and defaults live in Configuration/Sets/mp-core/settings.definitions.yaml and settings.yaml. The base set only references these files.

Source: Configuration/Sets/mp-core/

 

Schema default — default in settings.definitions.yaml (Site Settings UI). Shipped default — value from settings.yaml when it overrides the schema (column — = same as schema).

 

PIDs

Configuration

Performance

Navigation

Search

Meta

Templates & paths

Container (mpc/mp-core-container)

Source: Configuration/Sets/mp-core-container/

News (mpc/mp-core-news)

Source: Configuration/Sets/mp-core-news/

Form (mpc/mp-core-form)

Source: Configuration/Sets/mp-core-form/

SEO (mpc/mp-core-seo)

Source: Configuration/Sets/mp-core-seo/

Using Settings in TypoScript

Site settings are exposed as flat TypoScript constants under their dotted key (no settings. prefix), e.g. {$navigation.maxDepth}, {$config.admPanel}, {$PIDs.pidWebFonts}. The path settings (pageTemplates, basePath, …) are additionally exposed with a settings. prefix, which is why the mpcSitepackage.* path constants reference {$settings.pageTemplates}.

For values that must be resolved at render time (e.g. inside config, page.meta, or DataProcessor properties), read them directly via the site:settings.* data getter instead of a constant:

# Flat constant (resolved at TypoScript parse time)
page.10.dataProcessing.110.levels = {$navigation.maxDepth}

# Runtime getter (preferred for config / meta / processor stdWrap)
config.compressJs.data = site:settings.performance.compressJs // {$config.compressJs}
page.meta.robots.data = site:settings.meta.robots

Font design tokens are not consumed via TypoScript: they are generated from the Web Font records (see Web Fonts) by WebFontProcessor and emitted as CSS custom properties in Resources/Private/Partials/Page/Styles.html.

Web Fonts

Editors can self-host custom fonts (uploaded to / picked from the FileManager) instead of relying on system fonts. The feature replaces the former design.fonts.* string settings.

Data model

A family's Applies to field maps it to a CSS custom property:

Editor workflow

1. Create a sysfolder to hold the records and set its page ID in the PIDs.pidWebFonts site setting. Leave it at 0 to store the records on the site root page.
2. In the List module of that folder, create a Web Font Family: enter the family name (e.g. Inter), a fallback stack (e.g. sans-serif), and choose Applies to.
3. Add one Font Face per weight/style. Upload or pick a woff2 file via the FileManager and set its weight (100–900) and style (normal/italic).
4. Flush the frontend cache. WebFontProcessor generates the @font-face rules and the :root variable mapping into the nonce'd inline <style> block in the page <head>.

Rendering pipeline

Webfont records (FAL files)
  -> WebFontProcessor (page.headerData.2040.dataProcessing.20)
  -> WebFontCssBuilder (validate + sanitize, build @font-face + :root CSS)
  -> {webFontsCss} in Styles.html
  -> <f:asset.css useNonce="1"> + mpc:format.cssSanitize

All values are validated against fixed allow-lists in WebFontCssBuilder (weight, style, font-display, file format, custom-variable name, unicode-range) and the family name / fallback / URL are stripped of any character that could break out of the CSS declaration, so an attacker-supplied value can never escape the inline <style> block.

Constraints

• CSP: self-hosted fonts in fileadmin are same-origin and already covered by font-src 'self' in Configuration/ContentSecurityPolicies.php. Serving fonts from another domain requires adding that origin to font-src via a per-site config/sites/<id>/csp.yaml.
• Backend permissions: admins can edit the records immediately. Non-admin backend groups need tables_modify (and tables_select) granted for tx_mpcore_domain_model_webfontfamily and tx_mpcore_domain_model_webfontface.
• A family is only emitted when it has at least one face with a resolvable font file; otherwise the :root mapping is skipped (the family name alone would not load anything).

Site configuration (config.yaml)

Beyond Site Settings, mp-core extends the site record and site language via Configuration/SiteConfiguration/Overrides/sites.php. Configure these in Site Management → Sites → [site] → Configuration (or in config/sites/[site]/config.yaml).

Language-specific palettes: copyrightText, logo fields, and logoText / logoTextHidden can differ per site language.

TypoScript Structure

Configuration/
├── ContentSecurityPolicies.php     # Frontend CSP mutations auto-applied when
│                                   # the `security.frontend.*ContentSecurityPolicy`
│                                   # feature toggle is on (see "Content Security
│                                   # Policy" below)
├── Services.yaml                   # PSR-4 autowiring for `Mpc\MpCore\*`; explicit
│                                   # `public: true` for DataProcessors and the
│                                   # `ColorPickerValueItems` itemsProcFunc; optional
│                                   # `Services.local.yaml` import (see below)
├── Services.local.yaml             # (optional, gitignored) local-only DI overrides
├── Sets/
│   ├── mp-core/
│   │   ├── config.yaml               # Aggregator (depends on all feature sets)
│   │   ├── settings.yaml             # Shared Site Settings defaults
│   │   ├── settings.definitions.yaml # Shared Site Settings schema
│   │   ├── constants.typoscript, setup.typoscript, page.tsconfig
│   ├── mp-core-base/
│   │   └── config.yaml               # System deps + pointers to mp-core settings
│   ├── mp-core-container/
│   │   ├── config.yaml, settings.yaml, settings.definitions.yaml
│   │   ├── constants.typoscript, setup.typoscript
│   ├── mp-core-news/
│   │   ├── config.yaml, settings.yaml, settings.definitions.yaml
│   │   ├── constants.typoscript, setup.typoscript
│   ├── mp-core-form/
│   │   ├── config.yaml, settings.yaml, settings.definitions.yaml
│   │   ├── constants.typoscript, setup.typoscript
│   └── mp-core-seo/
│       ├── config.yaml, settings.yaml, settings.definitions.yaml
│       ├── constants.typoscript, setup.typoscript
├── TypoScript/
│   ├── constants.typoscript, setup.typoscript
│   ├── VueComponents.typoscript
│   ├── Helper/PageClass.typoscript
│   ├── Constants/*.typoscript
│   └── Setup/
│       ├── 10.Config, 20.Page, 30.Page.Styles, 40.Page.Scripts
│       ├── 50.Page.Navigation, 60.Lib, 90.CleanupRTE
│       ├── Page/*.typoscript
│       └── ContentElements/tt_content/*.typoscript
└── Extensions/
    ├── constants.typoscript, setup.typoscript

Dependency Injection (Services.yaml)

Configuration/Services.yaml autowires the Mpc\MpCore\* namespace and registers the services that TYPO3 has to resolve outside the container as public: true:

Local-only DI overrides (Services.local.yaml)

The shipped Services.yaml imports an optional sibling file with ignore_errors: not_found, so projects can register local-only services (ad-hoc helpers, environment-specific wiring) without modifying the published file or breaking container compilation when the file is absent:

# Configuration/Services.local.yaml  (gitignored)
services:
  # Example: register a local-only helper or override a service binding.

Configuration/Services.local.yaml is listed in .gitignore for this exact pattern.

Project tooling (bin/)

Project-local scripts live in mpcore/bin/ (outside any extension repository). Full command reference: mpcore/README.

Docs-site import (bin/docsite-import.php)

php bin/docsite-import.php
php bin/docsite-import.php --dry-run
ddev exec php bin/docsite-import.php --dry-run

From docs-site/: npm run import / npm run import:dry (wraps the same script).

XLF sorting (bin/sort-xlf.php)

php bin/sort-xlf.php
php bin/sort-xlf.php --dry-run --package=mp-core
ddev exec php bin/sort-xlf.php

Content Security Policy (ContentSecurityPolicies.php)

Configuration/ContentSecurityPolicies.php ships a strict frontend CSP that is auto-applied by TYPO3 13.4+ once one of these feature toggles is enabled (System -> Settings -> Feature Toggles):

• security.frontend.enforceContentSecurityPolicy -- enforce mode
• security.frontend.reportContentSecurityPolicy -- report-only mode

The shipped policy mutates the TYPO3 frontend defaults as follows:

Per-site overrides

Operators can relax or tighten the policy per site via config/sites/<id>/csp.yaml:

inheritDefault: true
mutations:
  - mode: extend
    directive: img-src
    sources: ["https://cdn.example.com"]
  - mode: extend
    directive: form-action
    sources: ["https://newsletter.example.com"]

Trust boundary for site colour configuration

Inline CSS variables in Resources/Private/Partials/Page/Styles.html are now funnelled through the mpc:format.cssColor ViewHelper, which delegates to Mpc\MpCore\Service\CssColorValidator. Only syntactically valid CSS colours (named, #rgb[a], #rrggbb[aa], rgb()/rgba()/hsl()/hsla()) are emitted; malformed or attacker-supplied site-configuration entries are silently dropped, so they can never break out of the inline <style> block.

The same validator is reused in Mpc\MpCore\UserFunc\ColorPickerValueItems so the backend colour-picker dropdown also filters out invalid slots and caps labels at 200 characters.

Template Path Configuration

page.10 = FLUIDTEMPLATE
page.10 {
  templateRootPaths {
    0 = EXT:mp_core/Resources/Private/Templates/Page/
    10 = {$settings.pageTemplates}
  }
  partialRootPaths {
    0 = EXT:mp_core/Resources/Private/Partials/
    10 = {$settings.pagePartials}
  }
  layoutRootPaths {
    0 = EXT:mp_core/Resources/Private/Layouts/
    10 = {$settings.pageLayouts}
  }
}

Path precedence: 0 = core, 10 = extension, 20+ = project. Higher numbers override lower.

Extension Overrides

plugin.tx_news.view.templateRootPaths.10 = EXT:mp_core/Resources/Extensions/news/Templates/
plugin.tx_form.view.templateRootPaths.10 = EXT:mp_core/Resources/Extensions/form/Templates/
plugin.tx_indexedsearch.view.templateRootPaths.10 = EXT:mp_core/Resources/Extensions/indexed_search/Templates/

Conditional Configuration

Navigation bundles depend on the site configuration field navType (see Configuration/SiteConfiguration/Overrides/sites.php):

[traverse(site("configuration"), "navType") == "1"]
  page.includeJSFooter.navigationPrimary = EXT:mp_core/Resources/Public/JavaScripts/navigationPrimary.js
[END]

TCA Overrides

Quick Reference

Page Fields (pages.php)

Global Link Wizard (tt_content_00_base.php)

Palette: link_config

Custom Content Elements

File Metadata / References

Common Customization Patterns

Adding a Field to an Existing Element

$myColumns = [
    'tx_my_field' => [
        'label' => 'My Field',
        'config' => ['type' => 'input', 'size' => 30],
    ],
];
ExtensionManagementUtility::addTCAcolumns('tt_content', $myColumns);
ExtensionManagementUtility::addToAllTCAtypes('tt_content', 'tx_my_field', 'textmedia', 'after:bodytext');

Database Schema

Add columns to ext_tables.sql, then run Admin Tools -> Maintenance -> Analyze Database Structure.

CREATE TABLE tt_content (
    tx_my_field varchar(255) DEFAULT '' NOT NULL
);

Tips

1. Reuse existing palettes from tt_content_00_base.php and tt_content_00_header.php
2. Prefix custom fields with tx_ to avoid conflicts
3. Use LLL:EXT:... references for all labels
4. Use displayCond for conditional field visibility: 'displayCond' => 'FIELD:my_toggle:=:1'
5. Use Site Settings instead of hardcoded TypoScript values
6. Follow path numbering: 0 (core), 10 (extension), 20+ (project)

Further Reading

• Backend -- RTE, Page TSconfig, content previews
• Content elements -- Per-CType TCA field reference
• Frontend -- Build system and asset pipeline
• Favicons -- Favicon generation
• TYPO3 TCA Reference
• TYPO3 Site Sets
• TYPO3 TypoScript Reference
• b13/container