README

Adds the Chatixy AI support agent to every front-end page of a TYPO3 site. Install, paste your widget key, save. No TypoScript, no template edits, no partial to include.

Requirements


TYPO3	12.4 LTS or 13 LTS (`typo3/cms-core: ^12.4 \|\| ^13.4`; TER constraint `12.4.0-13.4.99`)
PHP	whatever your TYPO3 version already requires - the extension adds no floor of its own
Chatixy account	any plan; a widget key is all the extension needs

Extension key: chatixy.

Install

composer require chatixy/typo3-chatixy
vendor/bin/typo3 extension:setup

Then go to Admin Tools -> Settings -> Extension Configuration -> chatixy, paste the Widget key from your Chatixy dashboard (under Install), and save. Flush the front-end cache and open your site.

The field accepts any of the three shapes the dashboard hands out:

the bare 64-character key,
<key>.js,
the whole <script src="https://chatixy.com/source/<key>.js" async></script> snippet.

The first 64-character hex run is extracted from whatever you paste, and the value is lower-cased for you. Leave it empty and the extension does nothing at all.

No Chatixy account yet? Start at https://chatixy.com/register.

What it does

A PSR-14 listener (registered with the #[AsEventListener] attribute, identifier chatixy/inject-loader) on AfterCacheableContentIsGeneratedEvent splices one tag into the rendered page before the closing </body>:

<script src="https://chatixy.com/source/<key>.js?platform=typo3" async></script>

That is the whole payload. Nothing is added to <head>, no CSS, no extra requests from the server side. The src is HTML-escaped before it is inserted.

Caching

The listener runs on the cacheable content event, so the tag is part of the page content TYPO3 stores in its page cache - there is no per-request PHP cost on a cache hit. The consequence is that changing the key means flushing the front-end cache, or the site keeps serving pages built with the old one.

Notable behaviour

All of this is in Classes/EventListener/InjectLoader.php:

Only the first </body> is replaced, so a literal </body> later in the markup is left alone.
HTML with no </body> gets the tag appended at the very end rather than being left without the support agent.
A page that already carries the loader is skipped - the listener looks for /source/<key>.js in the content first, so you get exactly one support agent per page, ever.
An unreadable or unset extension configuration is not an error. The read is wrapped in a try/catch, and a failure simply means no tag.
A missing or malformed key means no tag. Anything that is not exactly 64 lowercase hex characters after sanitisation is dropped rather than emitted as a broken script.

Settings

One field. ext_conf_template.txt declares widgetKey and nothing else.

There is deliberately no host setting - see below. If a host value survives in an existing install's EXTENSIONS/chatixy configuration it is harmless, because nothing reads it.

Security: the origin is pinned

The widget key is public; the host is not configurable. There is no "advanced host" field and no environment variable, because the stored host would build a first-party <script src> on every page of the site - i.e. site-wide stored XSS if it could be influenced. Every loader URL still goes through ChatixyKey::sanitizeHost() as a single choke point, and that method ends in an allow-list: only an https origin whose host is chatixy.com or a subdomain of it is accepted, and anything else is replaced with https://chatixy.com. The pattern is anchored at both ends and requires a literal dot before the canonical domain, so evilchatixy.com, chatixy.com.evil.example, chatixy.com@evil.example and http://chatixy.com are all rejected.

Support

MIT licensed. See LICENSE.

chatixy / typo3-chatixy

Package info

Security

Statistics