---
name: typo3-ext-blog
description: Install, configure, customize, or troubleshoot the TYPO3 Blog Extension (t3g/blog, EXT:blog). Use for matching blog templates to a custom design, composing blog list and post page layouts with a sidebar, tag cloud, recent posts, recent comments, post comments and comment forms, or configuring blog site sets, page IDs and routing. Do not use for georgringer/news, generic blog copywriting, or unrelated Fluid layouts.
license: CC-BY-4.0
compatibility: Requires access to the target TYPO3 project and its site package; installation needs Composer and compatible PHP/TYPO3 versions. Follow the project's DDEV, asset-build, and browser-test tooling when present.
---

# TYPO3 Blog Extension

Integrate `t3g/blog` into the existing site's design, including its surrounding
page layout and functional blog components. Posts are TYPO3 pages with ordinary
content elements. Keep custom configuration, Fluid overrides, and assets in the
owning site package; leave the installed extension unchanged.

## Workflow

1. **Establish the version and rendering baseline.** Read repository instructions,
   `composer.json`/`composer.lock`, the installed blog source, site configuration,
   effective TypoScript, page renderer, existing overrides, and asset commands.
   Resolve the site's design references, blog root, data folder, languages, and
   list/post URLs. Use version-matched official documentation; `main`/`master`
   documentation may describe unreleased behavior. Ask only for missing details
   that materially affect implementation; continue independent inspection.
   **Complete when:** the owning files, package version, page renderer, and
   requested components are identified without invented IDs or API names.
2. **Install or configure only what is missing.** Read
   [installation and configuration](references/setup.md). Select the shipped
   integration mode for an existing design, verify set dependencies or legacy
   includes, map each page ID by purpose, and merge routing into the existing
   site configuration. Reuse working setup instead of running the wizard again.
   **Complete when:** the effective configuration resolves the intended blog,
   data folder, target pages, and plugins under the installed version.
3. **Map the design to both rendering layers.** Read
   [design and template overrides](references/design.md). Separate the site page
   shell from blog plugin templates, widget layouts, and Form Framework fields.
   Map typography, spacing, cards, imagery, metadata, forms, and responsive
   behavior to existing project components. Copy only files that need changes;
   preserve names, data contracts, ViewHelpers, links, and functional hooks.
   **Complete when:** both page selection and extension view-path precedence
   resolve site-package overrides, and styling uses the site's asset pipeline.
4. **Compose the page and sidebar.** Read
   [page composition and widgets](references/page-and-sidebar.md). Render the
   post's content column once, add reusable post components in the dedicated
   post template, and render the native sidebar or selected native widgets in
   the intended region. Prefer `settings.sidebarWidgets` for selection/order.
   Keep the current post's comments/form distinct from recent-comments links.
   Do not require editors to insert the same components into every new post.
   **Complete when:** list and post layouts show all requested regions without
   duplicate content, headers, comment forms, or nested main landmarks.
5. **Preserve and verify comments end to end.** For comment work, read
   [comments and form styling](references/comments.md). Check global and
   per-post controls, moderation, language behavior, and the native form factory
   before changing markup. Preserve validation, finishers, messages, redirects,
   and comment anchors. Use approved local/staging data for submission checks.
   **Complete when:** requested recent comments, post discussion, and form are
   independently accounted for, including closed, empty, and pending states.
6. **Verify rendered behavior and report evidence.** Follow
   [verification and troubleshooting](references/verification.md). Build changed
   assets, run project checks, clear relevant caches, and inspect real frontend
   pages at desktop and mobile widths. Report changed paths, configuration,
   editor steps, checks, and any unavailable runtime verification.
   **Complete when:** each requested component has rendered evidence or a
   precise untested limitation; static checks alone do not prove visual parity.

## Safety

Work within the user's authorized scope. A request to install/configure authorizes
necessary local dependency and configuration changes; do not ask again for
routine reversible edits. Inspect dependency/database changes before executing
them. Obtain authorization for destructive migrations, production record writes,
deployment, or test submissions that publish comments or send notifications
outside an approved test environment. Never edit `vendor/` or extension source
as the customization mechanism. Keep secrets out of committed settings and
rendered HTML; preserve existing moderation and third-party service choices.

## Resources

- [Setup](references/setup.md): dependencies, sets, page tree, IDs, and routes.
- [Design](references/design.md): page/plugin/form override boundaries.
- [Page and sidebar](references/page-and-sidebar.md): rendering bridge and widget settings.
- [Comments](references/comments.md): moderation, form factory, and safe customization.
- [Verification](references/verification.md): frontend checks and failure diagnosis.
- [Source map](references/sources.md): pinned evidence and version caveats.
- [README](README.md): installation, usage examples, and related skills.
- [Evaluation prompts](evals/evals.json): maintainer scenarios and objective expectations.