ai-typo3 binds the shop to TYPO3's cache, mail and session, and leaves the user table alone

The readme's first instruction is to install a different package

The third paragraph says that if you are using the TYPO3 CMS you do not have to install and set up the ai-typo3 extension yourself, and that you should instead use the Aimeos TYPO3 package to create a web shop within minutes. Same structure as the other adapters in this family, and the same underlying distinction. One package is a shop. The other is a binding layer that makes Aimeos components behave like they belong inside a host application. If you want a shop, stop reading here and use the package. This extension exists for the case where TYPO3 is your application and Aimeos is supplying commerce behaviour inside it, which is a smaller and more technical audience. The readme gives no install commands, no configuration examples and no framework version matrix, and the links section points to a web site, documentation, a help page and the issue tracker. For an extension this thin, that is a deliberate choice rather than an omission, but it does mean evaluating it means reading the documentation site and reading the composer manifest, not the readme.

Four delegated services, and one that is conspicuously absent

The description is precise, and the precision is the useful part. Aimeos web shop components are described as integrating into almost any PHP application by using that application's infrastructure for building URLs, caching content, configuration settings, logging messages, session handling, sending e-mails and handling translations. The TYPO3 adapter is then specified as using the native TYPO3 components for content caching, sending mails, session handling and generating URLs. Four services, in that order. Compare that with the sibling Laravel adapter, whose list additionally includes accessing the user table, and the difference is worth a paragraph of its own. The TYPO3 adapter does not claim to touch identity. That may be a deliberate design, since TYPO3 has its own user model and its own frontend user handling that a shop adapter has no business rewriting, and it may also mean customer accounts are something you wire yourself. Either way, the practical question is the same: does your TYPO3 user model express the identity a basket needs, and if not, where does the mapping live? The readme does not answer it, so the documentation and the issue tracker are where to look. What the four delegated services do tell you is that caching, mail and session state are not duplicated inside Aimeos here, which is the class of integration bug you avoid entirely.

The repository layout: a themes directory is the tell

With so little prose, the tree is the specification, and one entry is more informative than the rest. There is a themes directory. For a package whose job is described as delegating infrastructure rather than rendering pages, owning themes implies the adapter supplies presentation as well as wiring, and that is a larger surface than the readme's two sentences suggest. The rest follows the family pattern: a manifest.php for the Aimeos extension system, a composer.json, a config directory for the adapter's own settings, a setup directory for migrations, src, tests, and a phing.xml build file. A manifest.jsb2 appears here too, which belongs to the GrapesJS build rather than to TYPO3, so the adapter carries frontend assets of its own. The tests directory and the CircleCI directory match the build and coverage badges in the readme, so this adapter is covered by tests and checked in continuous integration rather than being a thin unverified shim. The practical reading of the layout is that you are installing a component with its own opinions about configuration, its own migrations and its own frontend build, which is a different proposition from a set of interfaces, and which means an upgrade can touch your TYPO3 configuration and your templates rather than only your own code.

The licence paragraph names a different project

The licence section reads that the Aimeos ai-flow extension is licensed under the terms of the LGPLv3 license and is available for free. The repository is not ai-flow. It is the TYPO3 adapter. The repository licence field says LGPL-3.0, so the terms are consistent with the classification, but the paragraph names the wrong extension, and the same paragraph in the sibling Laravel adapter reads correctly. This is a copy-paste artefact from another project in the same family, and it is minor in itself. It is worth mentioning because it is a small piece of evidence about documentation maintenance in a family of packages that describe themselves in near-identical words, and because a reader verifying a licence by reading the readme would be reading a sentence about a different piece of software. For LGPLv3, the practical question is what you distribute and under what terms, and that is a question for whoever owns your licensing rather than something a readme sentence settles. Nothing else in this readme suggests a problem: the badges are honest, the scope statement is accurate, and the redirect to the shop package is helpful rather than evasive.

What to check before you let it touch a CMS database

The setup directory is the part that deserves a review rather than a run, and the reason is the host. In a greenfield shop, a migration that creates tables is unremarkable. In a TYPO3 site, the database already contains pages, users, content and possibly other extensions, and a migration written against a fresh install can collide with names that are already taken or assume tables that exist in a different shape. The readme does not describe the migrations, does not say whether they are reversible, and does not document a dry run. So the checklist before running anything is empirical rather than documented: read the setup directory, confirm the table names your installation has not already used, take a database snapshot, and run the migration on a copy of production data rather than on a fresh one. The same reasoning applies to config. The adapter has a config directory, which is the right design for a CMS extension because it lets a site adjust behaviour without patching vendor code, and it also means a config change during a framework upgrade is possible. Confirm which of your TYPO3 configuration files the adapter expects to be edited, because an extension that appends to a config array has a habit of being overridden by a later merge.

Where the documentation actually is

The links are the deliverable here, and the documentation section is the one to open first:

https://aimeos.org/docs/TYPO3

There is also a web site for the TYPO3 integration, a help page specific to the TYPO3 extension, and an issue tracker on GitHub. A help page scoped to one extension, rather than a general support channel, suggests the maintainers route version-specific questions through it, and that is a better place to ask about framework compatibility than a new issue. The issue tracker is also where the interesting archaeology is: for an extension with no release tags, the pattern of which TYPO3 versions people report problems against is the practical version support matrix, and it is the only version evidence available beyond the composer constraint. Read that before you plan an upgrade rather than after. Two things the readme does not tell you and that documentation probably does: the supported TYPO3 and PHP range, and how customer accounts are meant to work given that the delegated service list does not include identity. Those are the two questions to arrive with, because both change whether you adopt the adapter or the shop package.

Editorial conclusion

Adopt ai-typo3 if you are embedding Aimeos inside a TYPO3 site you already maintain, because it hands caching, mail sending, sessions and URL generation to the CMS rather than duplicating them, and check first whether the absence of any mention of a user table is a problem for you, because the delegated service list stops at identity. Do not install it expecting a shop: the readme says outright that TYPO3 users should use the separate Aimeos TYPO3 package instead, and it points there rather than giving setup steps. Four things to verify. That your TYPO3 and PHP versions fall inside what the composer manifest allows, since the readme names no version constraint at all. That the setup directory migrations are safe against a database that already holds content, since a CMS database is never empty. That customer identity is something your own TYPO3 user model can express, because the adapter does not claim to touch it. And that you are comfortable with the licensing, since the readme states LGPLv3 for a package that reaches into your CMS configuration. The last push to the master branch was on 2026-06-15 and there are no published GitHub releases, so composer metadata rather than a tag is what identifies a version.

Frequently asked questions

Official sources

1. aimeos/ai-typo3 on GitHub
2. Issues
3. License: LGPL-3.0
4. Project website
5. README