The Aimeos TYPO3 install is four commands and an imported page tree

Three supported release lines, and the readme tells you which is which

The installation section opens with a version statement that is more careful than most: this document covers the Aimeos TYPO3 25.10 release and later, with a stable release of 26.04 for TYPO3 13 and 14 LTS and an LTS release of 25.10 for TYPO3 12 and 13 LTS. That is a compatibility statement you can act on. It tells you that pinning the extension to the 25.10 line keeps you inside the support window of the two TYPO3 LTS generations, and that moving to 26.04 means accepting TYPO3 13 or 14 as a floor. The repository layout explains how the package supports both distribution channels at once. There is a composer.json for the modern path and a composer-ter.json for the classic extension repository path, an ext_emconf.php for the Extension Manager metadata, an ext_localconf.php for the extension bootstrap, ext_conf_template.txt for the install-time configuration template, and ext_tables.sql for the schema. The Classes, Configuration, Resources and Tests directories follow the standard TYPO3 extension convention, and build.xml is the Ant build. Reading that list tells you the extension is a first-class TYPO3 extension rather than a composer library pretending to be one, which is why the legacy install path is documented as carefully as the modern one.

The install path, command by command

The composer path starts by fetching composer itself if you do not have it, which the readme marks as required at version 2.2 or later:

php -r "readfile('https://getcomposer.org/installer');" | php -- --filename=composer

Then a base TYPO3 distribution, either at whatever version composer resolves or pinned to a major version:

composer create-project typo3/cms-base-distribution myshop

Inside that directory the TYPO3 setup command runs, you complete the browser setup wizard, and the extension is added:

composer req -W aimeos/aimeos-typo3:~25.10

The capital W matters and is easy to miss: without it, composer may refuse to update the TYPO3 packages the extension needs. If composer then complains that minimum stability is not met, the readme's fix is a two-line addition to composer.json:

"minimum-stability": "dev",
"prefer-stable": true,

That combination is the standard way to allow a development dependency while still preferring stable releases, and it is worth understanding rather than pasting, because it widens what composer will consider for the whole project. The final two commands depend on your TYPO3 version and are where the demo data decision sits:

php ./vendor/bin/typo3 extension:setup
php ./vendor/bin/typo3 aimeos:setup --option=setup/default/demo:1

The readme then tells you plainly that if you do not want the demo data you should remove the demo option from the Aimeos setup command. That is a flag you have to actively delete, which means a copy-and-paste install ships with sample products in it. If your installation is meant to look empty on day one, the fix is to type the command without the option the first time.

A Bootstrap package, and a layout that expects a grid

For a working installation out of the box on a new site, the readme recommends a second package:

composer req bk2k/bootstrap-package

The note that follows is the part that catches people. You have to create a root page and a root template, and that template must include the Bootstrap package templates. The deeper reason is stated separately in the page setup section, which says the Aimeos layout expects Bootstrap providing the grid layout. So the Aimeos shop templates are not self-contained. They emit markup that assumes a twelve-column grid with the usual container, row and column classes, and a site that has no Bootstrap, or has a different grid system, will render a shop that technically works and looks wrong in a way that is tedious to diagnose because nothing errors. The page tree files the readme offers for import are also Bootstrap-shaped, since the tree brings its own templates with it. Two consequences follow. If you already have a design system, check its grid before importing the tree rather than after. And if you want Aimeos to fit an existing template, the readme's claim that you can adapt, extend and overwrite anything is the relevant promise, though the mechanics of that are not documented here and belong to the TYPO3 template override system rather than to this extension.

The page tree import is the step people skip

Importing a page tree is what makes the shop appear, and the readme devotes a table of contents section to it, including a downloadable file for the current line and one for an older one: a 25.10 and later page tree as an XML file, and a 24.10 page tree as a T3D file. The procedure it describes is: create a page, mark it as a root page in the page properties, find the import view, upload the file, and import it. Two requirements are stated along the way. The first is that the target should be a page defined as a root page, and TYPO3 10 and later create a basic site configuration automatically when you create a page with the globe icon, which is where the site configuration requirement comes from. The second is the file format itself, which changes between the two downloads. An XML page tree and a T3D page tree are different formats produced by different TYPO3 generations, so the version of the file you import has to match the extension line you installed. Importing the wrong one is the kind of failure that appears as a missing shop rather than as an error, so the download line to use is the one matching your extension version. For legacy installations the readme points at the Aimeos extension in the TYPO3 Extension Repository, and for new ones at a one-click Aimeos distribution that gives a set up shop system including demo data.

The payment redirect cookie problem, and why the fix is the documented one

The security section of the readme deals with a specific failure that would otherwise be very hard to diagnose. Since TYPO3 9.5.14 the platform implements SameSite cookie handling, which restricts when browsers send cookies to your site. The consequence for a shop is that when a customer is redirected back from an external payment provider's domain, there is no session available on the confirmation page. The documented fix is to set the configuration option to None in either the local configuration file or the system settings file:

    'FE' => [
        'cookieSameSite' => 'None'
    ]

This is worth taking seriously rather than reading as a workaround. Setting that option to None applies to the front end generally, and it weakens a browser-side protection for every visitor, in exchange for a checkout flow that works. A shop that does not take payments through an off-site redirect may not need it at all, and applying it site-wide to fix a problem on one page is a broad change. The readme gives the fix and does not discuss the trade-off, so the decision is yours. If you do apply it, apply it because you have confirmed your payment provider redirects away and back, and review it as part of your own security posture rather than treating it as an install step. The same file choice matters, since the readme names both a legacy local configuration path and a system settings path, and which one applies depends on your TYPO3 generation.

Where this sits among the Aimeos integrations

The alternative to this extension is not another TYPO3 shop extension, it is running Aimeos outside TYPO3, and the difference is architectural rather than incremental. Standalone, Aimeos is the shop and you build the surrounding site. As a TYPO3 extension, the shop lives inside a content management system that already has editors, a page tree, site configurations, templates and a permission model, and Aimeos supplies the commerce layer within it. That is the whole value proposition, and it comes with the same trade you accept in any extension: the shop is constrained by the host's conventions, so a page tree import is the way in rather than a set of controllers you write, and TYPO3's grid, template and site concepts are now part of your shop's shape. The repository topics list includes json-api and vue alongside typo3 and b2b, which suggests an API-driven path exists for building a decoupled front end on top of the same commerce core, and that is worth asking about if your editorial team wants a TYPO3 back office with a separate storefront. The readme here does not document such a setup, so treat it as a question for the project's documentation rather than a supported path. The maintenance picture is healthy: no GitHub releases are published, but the last push was on 2026-09-10, and a Scrutinizer quality badge is present. The licence is GPL-3.0.

Editorial conclusion

Adopt aimeos-typo3 if you already run TYPO3 and want the Aimeos shop and admin inside that installation rather than as a separate service, because the extension keeps catalogue, checkout and CMS in one content tree and there is a distribution package for a one-click start. Do not adopt it for a headless front end or a non-TYPO3 stack, since the page tree import and the site configuration requirements are TYPO3 concepts with no equivalent elsewhere. Five things to verify before you commit. That your TYPO3 version matches the release line, since the document covers the 25.10 release and later, naming 26.04 as stable for TYPO3 13 and 14 LTS and 25.10 as the LTS line for TYPO3 12 and 13. That composer 2.2 or later is available, which the readme calls out as a requirement. That you remove the demo data option from the Aimeos setup command if you do not want it, because it is on by default in the documented command. That the same site option is set for payment returns, since SameSite cookie handling breaks the session on a redirect from a payment provider. And that your layout provides the Bootstrap grid the Aimeos layout expects. The licence is GPL-3.0 and the last push was on 2026-09-10.

Frequently asked questions

Official sources

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