The new Aimeos feature release contains some long-awaited new stuff for developers and customers alike. What you get by using the 2020.07 release among various minor improvements and bugfixes is:

• PDF invoice in order confirmation e-mail
• Supplier CSV import
• Improved admin backend for mobile phones
• Better full text search and URL segments
• Official TYPO3 10 support
• Simplified manager and criteria filter methods

PDF invoice in confirmation e-mail

One of the most often requested features is now part of the Aimeos core: A nice looking template which can be easily adapted to the clients requirements and corporate design. The full source code for the invoice PDFs was contributed by the Aimeos GmbH.

The PDF document is generated from a HTML template and automatically attached to the e-mails sent to customers when the order has been paid. You can change the content and the layout of the PDF by adapting the template only, including header and footer sections repeated on each page.

Internally, the TCPDF library is used for creating the PDF from the HTML template, which also supports splitting long content to several pages automatically. In composer based setups, TCPDF is automatically added and installed as dependency. For TYPO3 integrators who still download packages from TER, there’s a new dependency the pdfviewhelpers extension due to the size of the TCPDF libary.

Supplier CSV import

Up to version 2020.07, you have been able to import several entities via configurable CSV files:

• attributes
• categories
• coupon codes
• products
• stock levels

Now, you can also import supplier data including addresses, images, texts and references to other domains like products. Also, you can add supplier references in the product CSV import too.

This part of the new release was a big contribution by Alexey, an Aimeos developer and freelancer who offers his expertise for custom projects.

Improved admin backend for mobile phones

Thanks to Robert, who did an amazing job improving the backend styles, the Aimeos admin interface is much better usable by mobile phone users regardless of their display size. Even with an old iPhones which only have 320px width, managing the items is fully possible now.

Header texts which are too long fade out, the size of the buttons has been adapted to the smallest supported viewport size and all tables gets a scollbar if their columns are bigger than the screen.

Additionally, the left navigation menu got some love and displays the names of the navigation items when clicking on the bottom arrow button. Thus, mobile phone users can see what their meaning is if they can’t remember.

Better full text search and URL segments

The results of the full text search offered by MySQL, PostgreSQL and SQL Server has been refined to return more relevant results. Especially for phrases with several words, stop words and special characters, it yields much better results now.

Optimized URL segments can be added as text to products and categories, but generating URL segments from labels led to a loss of characters if special characters not covered by the ASCII character set was used. Thanks to the “voku/portable-ascii” library, these characters are now transliterated to the best matching ASCII character or to several characters like for “ä -> ae”.

Official TYPO3 10 support

Three month after TYPO3 10 LTS has been released, the Aimeos TYPO3 extension officially supports the new TYPO3 major release. It took some time until the static_info_tables extension was available for TYPO3 10, which Aimeos depends on.

The Aimeos 20.7.x extension supports TYPO3 v9 and v10 only because it removes all methods deprecated by v9 and dropped in v10 to clean up the code base. Furthermore, it uses the new APIs if applicable and offers it’s own panel for all Aimeos plugin elements with icons and descriptions to support new users.

Simplified manager and criteria filter methods

Working with Aimeos should be fun and even you can do the most complex things in e-commerce using Aimeos, the code you have to write should be as small as possible. Therefore, the manager methods have been shorted to:

Also, building filter criteria for the search() method is now much easier. Instead of:

$search = $manager->createSearch( true )->slice( 0, 100 );
$search->setConditions( $search->combine( '&&', [
    $search->compare( '==', 'product.type', 'default' ),
    $search->compare( '==', 'product.dataset', 'shirt' ),
    $search->compare( '>', 'product.datestart', '2020-01-01' ),
    $search->getConditions()
] ) );
$search->setSortations( [
    $search->sort( '-', 'product.label' ),
    $search->sort( '+', 'product.id' )
] );

You can now write using the new 2020.07 release:

$f = $manager->filter( true )->slice( 0, 100 )
    ->add( ['product.type' => 'default', 'product.dataset' => 'shirt'] )
    ->add( 'product.datestart', '>', '2020-01-01' )
    ->sort( ['-product.label', 'product.id'] );

This will cover 95% of all use cases. A more complex example including mixed AND and OR operators:

$f->add( $f->and( [
    $f->or( [
        $f->is( 'product.datestart', '<', '2000-01-01' ),
        $f->is( 'product.datestart', '==', null ), ]
    ),
    $f->or( [
        $f->is( 'product.dateend', '>', '2000-01-01' ),
        $f->is( 'product.dateend', '==', null )
    ] ),
] );

You can use the NOT operator for negating all conditions:

$f->add( $f->not( $f->and( [
    $f->is( 'product.type', '==', 'default' ),
    $f->is( 'product.status', '==', 0 ),
] ) ) );

Creating search functions to pass parameters as part of the search key are also much easier to use now:

$f->add( $f->make( 'product:has', ['attribute', 'default', 123] ), '!=', null );

Finally, you can parse a complete condition block like before:

$f->parse( ['||' => [
    [
        '<' => ['product.datestart' => '2000-01-01'],
        '==' => ['product.datestart' => null]
    ], [
        '>' => ['product.dateend' => '2000-01-01'],
        '==' => ['product.dateend' => null]
    ]
] ] );

The old manager and criteria API is still available so all extensions developed from 2020.x will continue to work without problems, but the old APIs are deprecated and will be removed in the future.

More about Aimeos

• Web site: https://aimeos.org
• Github: https://github.com/aimeos
• TYPO3 TER: https://extensions.typo3.org/extension/aimeos/

• Facebook: https://facebook.com/Aimeos
• Twitter: https://twitter.com/Aimeos
• YouTube: https://youtube.com/c/aimeos

E-Commerce frameworks are flexible enough to adapt them to your specific requirements. As result, they are suitable for building virtually all kinds of online shops and e-commerce related (web) applications like the Aimeos e-commerce framework does.

An e-commerce framework must

• allow replacing all parts of the framework code
• forbid changes in the framework code itself
• contain bootstrap code to start the application
• be extensible by user-written code

E-Commerce frameworks should

• define the general program flow
• consist of reusable components
• be organized in functional domains

Examples of e-commerce frameworks are

• Aimeos (Laravel, Symfony, TYPO3, SlimPHP, Flow)
• Spryker (Symfony only)
• Sylius (Symfony only)

They provide an overall structure for e-commerce related applications. Furthermore, they implement the general program flow e.g. how the checkout process works. Contrary to monolithic shop systems, existing program flow can not only be extended but completely changed according to your needs.

Evolution of e-commerce systems

Since the beginning of (internet) e-commerce around 1995, a lot has changed on the technology side. The first generation of e-commerce systems evolved from existing ERP and related systems. This was followed by the 2. generation of standalone shop systems between 2004 and 2008. E-commerce frameworks are the latest generation of e-commerce systems and started around 2012.

Hybris, the shop system owned by SAP is one of the representatives of the 1. generation. It’s strongly connected to the SAP ERP system and Hybris is mainly a shop front-end for SAP. Customer relationship (CRM) and content management (CMS) tools are available in the ERP system but very limited.

The Magento shop system represents the 2. generation of standalone e-commerce systems. They usually contain CRM and CMS and some other functionality but also only at a very basic level. They might be enough for the smallest shops but are unusable for shop owners who run for real profits.

Aimeos is one of the few real e-commerce frameworks that are currently available. These 3rd generation systems excel in their own domain: Present and sell products. For all other e-commerce related tasks, they connect to specialized systems and exchange data in both ways. Thus, shop owners can choose the best systems for their needs.

E-Commerce framework architecture

E-commerce frameworks must be based on a strong architectural model. Usually, they make heavy use of interfaces and design patterns like

• Dependency Injection (make components independent of used object implementation)
• Factories (create objects at a central place that instantiates the actual implementation)
• Decorators (dynamically add functionality to existing objects)
• Publish/Subscribe model (notify listening objects about changes instead of polling for updates)

A “design pattern” is re-usable solution that solves similar software design problems in an elegant way. They require programming language templates which enforce public class methods and their signatures called “interfaces”.

The basic requirement are independent, side-effect free components that form the building blocks. One or more components care about the functionality of a business “domain”. Such a domain can be the HTML front-end, a JSON REST API and the administration interface.

The vertical separation of code into business domains enables scaling out applications by deploying the application as a bunch of micro services.

Micro services are loosely coupled applications that offer their service over lightweight protocols like HTTP and JSON. They are easier to extend, maintain and especially deploy than monolithic applications.

More about Aimeos

E-Commerce Frameworks sind flexibel genug um sie an kundenspezifische Anforderungen anzupassen. Dadurch können sie als Basis für praktisch alle Arten von Onlineshops und E-Commerce bezogene (Web-)Applikationen dienen, wie beispielsweise das Aimeos E-Commerce Framework.

Ein E-Commerce Framework muss

• es erlauben, jeden seiner Bestandteile zu ersetzen
• Änderungen am Framework-Code selbst verbieten
• Bootstrap-Code beinhalten um die Applikation zu starten
• erweiterbar für kundenspezifischen Code sein

E-Commerce Frameworks sollen

• den allgemeinen Programmablauf definieren
• aus wiederverwendbaren Komponenten bestehen
• in funktionalen Domänen unterteilt sein

Beispiele für E-Commerce Frameworks sind

• Aimeos (Laravel, Symfony, TYPO3, SlimPHP, Flow)
• Spryker (nur Symfony)
• Sylius (nur Symfony)

Sie bieten eine komplette Infrastruktur für E-Commerce bezogene Applikationen. Weiterhin implementieren sie den allgemeinen Programmfluss, z.B. wie der Checkout-Prozess funktioniert. Im Gegensatz zu monolithischen Shopsystemen kann der bestehende Programmfluss nicht nur erweitert werden, sondern auch komplett für die eigenen Bedürfnisse geändert werden.

Evolution von E-Commerce Systemen

Seit dem Beginn des E-Commerce im Internet um 1995 hat sich vieles auf Seiten der Technologie verändert. Die erste Generation von E-Commerce Systemen entwickelte sich aus existierenden Warenwirtschaftsprogrammen und ähnlichen Systemen. Daraufhin folgte die zweite Generation von eigenständigen Shopsystemen zwischen 2004 und 2008. E-Commerce Frameworks sind die neuste Generation von E-Commerce Systemen und begannen ab 2012 auf den Markt zu kommen.

Hybris, das Shopsystem von SAP ist einer der Vertreter der ersten Generation. Es ist eng mit dem SAP ERP System verzahnt und Hybris ist hauptsächlich eine Shopoberfläche für SAP. Customer Relationship (CRM) und Content Management (CMS) Werkzeuge sind im Umfeld von SAP verfügbar aber mit eingeschränkter Funktionalität im Gegensatz zu spezialisierten Systemen.

Das Magento Shopsystem repräsentiert die zweite Generation von eigenständigen E-Commerce Systemen. Sie beinhalten CRM und CMS Komponenten sowie ein paar weitere Funktionalitäten, aber ebenfalls nur mit einem beschränkten Funktionsumfang. Sie können für Kleinstunternehmen ausreichend sein, für Shopsbetreiber mit größeren Umsätzen aber meistens unbrauchbar.

Aimeos ist eines der wenigen echten E-Commerce Frameworks die im Moment verfügbar sind. Diese Systeme der dritten Generation glänzen in ihrer Kerndomäne: Der Präsentation und dem Verkauf der Produkte. Für alle weiteren E-Commerce bezogenen Aufgaben verbinden sie sich mit spezialisierten Systemen und tauschen Daten in beide Richtungen aus. Dadurch können Shopbetreiber das jeweils beste System für ihre Bedürfnisse wählen.

E-Commerce Framework Architektur

Gute E-Commerce Frameworks müssen einer stringenten Architektur folgen. Dafür verwenden sie ausgiebig Interfaces und Design Patterns wie

• Dependency Injection (Komponenten sind unabhängig von der konkreten Objektimplementierung)
• Factories (erzeugen zentral Objekte und instanzieren die tatsächliche Implementierung)
• Decorators (fügen dynamisch zusätzliche Funktionalität zu existierenden Objekten hinzu)
• Publish/Subscribe (benachrichtigen registrierte Objekte über Änderungen anstatt wiederholt auf Änderungen zu testen)

Ein “Design Pattern” ist eine wiederverwendbare Lösung, die ähnliche Softwaredesign-Probleme elegant löst. Sie benötigen Schablonen names “Interfaces” in den Programmiersprachen, die öffentliche Klassenmethoden und ihre Signaturen erzwingen können.

Die wichtigste Anforderung sind unabhängige Bausteine ohne Seiteneffekte, die zu Komponenten zusammen gefügt werden können. Ein oder mehrere Bausteine sind für die Funktionalität einer Fachdomäne zuständig. Eine Domäne kann eine HTML Oberfläche, eine JSON REST API oder eine Administrationsoberfläche sein.

Die vertikale Trennung von Code in Fachdomänen ermöglicht es Applikationen beliebig zu skalieren, indem sie als Microservices auf mehreren Serverinstanzen laufen können.

Microservices sind lose gekoppelte Applikationen, die ihre Dienste über leichtgewichtige Protokolle wie HTTP oder JSON anbieten. Sie sind leichter zu erweitern, zu warten und auszurollen als monolithische Applikationen.

Mehr über Aimeos

The new beta version contains a lot of improvements and focuses on:

• Even more performance
• Developer experience
• Code cleanup

Performance improvements

Aimeos is already known as ultra fast e-commerce solution for Laravel, Symfony, SlimPHP, TYPO3 and Flow/NeosCMS even for complex requirements. This release pushes the limits teared down by Aimeos #gigacommerce further with render times of 20ms and below if content caching is enabled. Without caching, response times are exceptional too compared to other shop systems and in the 2019.01 release, we reduced that time further.

First, we denormalized tables that use types, so the type code is now stored directly instead of the type ID. This saves several database queries per request. Additionally, it’s possible to retrieve related data for e.g. products filtered by type:

$manager->searchItems( $filter, ['text', 'price', 'product' => ['suggestion'] );

This fetches related products of type “suggestion” only instead of all related products. Especially for shops with many relations, this can be a huge performance improvement if components can’t be cached.

PHP 7.3 promises another huge performance improvement and we are testing that version every time. Unfortunately, there’s a bug in PHP 7.3 with prevents production usage yet. It seems that the PHP developers over-optimized opcode caching so PHP 7.3 produces wrong results: https://bugs.php.net/bug.php?id=77310

Simplifications for developers

One of the major goals for this Aimeos release was to simplify interfaces so the first steps for new developers are easier. As a result, creating managers, controllers and clients requires only:

$manager = \Aimeos\MShop::create( $context, 'product' );
$cntl = \Aimeos\Controller\Frontend::create( $context, 'catalog' );
$client = \Aimeos\Client\Html::create( $context, 'catalog/lists' );

Items with relations are fetched recursively now and a decorator limits the recursion depth to two levels. The allowed depth is configurable like everything else in Aimeos. This allows you to get all releated data you need at one without fetching and merging data from several calls to searchItems():

$products = $manager->searchItems( $filter, ['product', 'price', 'text] );

For bundle and selection products, the items in the result list contains the bundled and variant articles including prices, texts and related products.

Also, all newly created items have the status “enabled” by default and must be explicitly disabled if required. This saves many calls to “setStatus()” especially when implementing a new importer. The frontend controllers allow multiple category IDs for filtering so it’s possible to search for
products in multiple categories with one method call.

Code cleanups

Finally, a lot of old code has been removed due to the switch to document oriented managment of items. Especially in the index managers and the filter criteria implementation was some code left after the changes required to use ElasticSearch natively.

The 2019.x releases are the last ones that will support PHP 5 as 5.6 isn’t maintained any more since this year. You should use PHP 7 nevertheless to get the best performance.

For a full list of backward incompatible changes, please have a look at the Wiki article. BC breaking changes in 2019.01 are listed up to 2018-12-31:

https://aimeos.org/docs/Developers/Changelog/2019