Skip to content

Installation

Memory for the PDF check. The PDF accessibility check uses smalot/pdfparser; multi-page, graphics-heavy PDFs can need well over 256 MB (a common default CLI memory_limit). For auditing large corpora a CLI memory_limit of 512 MB is recommended. nt_ai:pdf-audit stays robust even against an over-hungry file (records it as "not auditable", optional --max-size-mb).

Via Composer

composer require netthinks/nt-ai

Activate in Admin Tools → Extensions, or via CLI:

vendor/bin/typo3 extension:setup

The extension creates its database tables (tx_ntai_audit_report, tx_ntai_page_score, tx_ntai_lighthouse_report, tx_ntai_token_usage) on activation. After a manual composer update, run:

vendor/bin/typo3 database:updateschema

Manual installation

  1. Download the latest release from the GitHub releases page.
  2. Extract to typo3conf/ext/nt_ai.
  3. Activate in Admin Tools → Extensions.

After installation

Open Admin Tools → Settings → Extension Configuration → nt_ai and configure at least one AI provider (see Configuration).

Note

Until a provider is configured, the backend modules load but AI-powered features report "no provider configured".

Enabling the accessibility widget & read-aloud in the frontend

The frontend widget and read-aloud are provided as a Site Set. On a customer system you only add the set as a dependency — either in the site configuration or as a dependency of your own sitepackage set:

# config/sites/<identifier>/config.yaml  (or in your own set)
dependencies:
  - netthinks/nt-ai

The settings then appear automatically under Site Management → Settings (categories "Barrierefreiheit" and "Vorlesen (TTS)"). No manual settings.definitions.yaml entries are needed. The set ships the assets, settings and the frontend config (data-nt-* on the <html> tag).

Only site-specific theming stays in the sitepackage: a native dark theme (brand colours), optional frontend tweaks and — if wanted — a "read aloud" button in the template (<f:render partial="ReadAloud"/> or [data-nt-tts]).

Deploying by rsync or tar

If you roll the extension out as files — rsync, tar, an artefact copied onto the target — rather than running composer install there, replace the directory through a staging path and swap it in one move:

rsync -a --delete nt_ai/ /path/to/vendor/netthinks/nt-ai.new/
mv /path/to/vendor/netthinks/nt-ai /path/to/vendor/netthinks/nt-ai.old
mv /path/to/vendor/netthinks/nt-ai.new /path/to/vendor/netthinks/nt-ai

Deleting the old directory first and then copying the new one into place leaves a window in which the extension is present but incomplete. A request landing in that window fails with a class-not-found error for a class that does exist — misleading enough to send the search in entirely the wrong direction. This applies to any TYPO3 extension; it is mentioned here because it was diagnosed the hard way in a production installation.

Afterwards clear the caches and run extension:setup, so the DI container and the database schema match the new code.