TypoScript or Fluid – which install path fits?
For a global setup TypoScript is the clean route: `page.headerData.1900 = TEXT` with `value = <script …></script>` in your site package setup, versioned in Git and therefore reproducible across instances. If only certain page trees need sign-off, add a condition (`[page["uid"] in tree.rootLineIds]`). Alternatively put the snippet straight into the Fluid layout (`Layouts/Page/Default.html`) – handy when the project barely uses TypoScript, but less flexible because every additional layout needs the code as well.
Cache layers: the usual reason nothing shows up
TYPO3 caches on several levels – `pages`, `pagesection`, `hash` – usually plus a reverse proxy such as Varnish or Nginx FastCGI and a CDN. After installing, use "Flush frontend caches" and, for site-package changes, "Flush all caches", then purge Varnish or the CDN. If the snippet only appears on some pages, stale `pagesection` entries are still active or the TypoScript was included on the wrong root page.
Ship it in staging only, never in production
Because TYPO3 projects almost always run a deployment chain with several contexts, tie the snippet to the application context: `[applicationContext == "Development/Staging"]` in the TypoScript condition, or an environment variable evaluated in the Fluid template. The same code then travels through every instance without a feedback snippet leaking to production – exactly the point where generic website-builder instructions stop being useful.
Multi-language and site configuration
In TYPO3 setups with several languages or several sites per instance every language variant has its own URL, and the note is attached to that URL. For sign-off that means: review languages as separate passes, and register every domain and subdomain from your site configuration in the nootiz project, otherwise the snippet is rejected on a language domain.
Sign-off without backend training
The most expensive part of a TYPO3 sign-off is clients who cannot navigate the backend: they report editorial content as bugs, or report nothing because the login stops them. With frontend notes they only need the link – feedback arrives precisely on the element instead of as one long email, and you instantly see whether it concerns the template, the content or an extension's output.
Editorial workflow and extension output
Notes replace neither backend workspaces nor approval workflows; they complement them. Feedback on extension output – news lists, Powermail forms, EXT:form fields or slider elements – lands on the rendered element with its CSS selector. Development immediately knows whether a Fluid partial, a TypoScript setting or a content element is the cause.
Limits in a TYPO3 context
nootiz knows nothing about TYPO3 user groups: anyone with the project link can leave notes. For confidential pre-release content, combine the snippet with basic auth or an IP restriction on the staging domain. Likewise, notes are not a ticket system – they are handed over to one (Trello, Asana, Jira, GitHub).
