Aimeos e-commerce framework documentation

The Aimeos Laravel package is a Composer-based extension for the Laravel web application framework. It integrates the core Aimeos web shop component library into Laravel applications, allowing you to place shop components on any page using Blade templates.

It also provides adapter classes for standard Laravel components such as logging, configuration, and URL generation, ensuring native integration with the Laravel ecosystem.

The Aimeos TYPO3 extension allows you to integrate the Aimeos e-commerce PHP library into an existing TYPO3 installation. This enables seamless e-commerce functionality within a TYPO3 website, such as a corporate presence.

Key features include:

• Plug-ins: Functional components (product filters, article listings, detail views, basket, checkout, etc.) that can be placed on any TYPO3 page.
• Back end Integration: The Aimeos administration interface is accessible directly via the TYPO3 back end, utilizing existing TYPO3 user accounts.
• Frontend Customization: The Aimeos frontend can be adapted to match corporate designs using standard TYPO3 techniques.

The context item is the central dependency container for Aimeos. It provides framework-independent access to the host system's core services (database, cache, filesystem, etc.). It is available in all classes within the data access layer and above via the $this->context() method. It acts as the gateway to all infrastructure services regardless of whether you are using Laravel, Symfony, TYPO3, or a custom application.

$context = $this->context();

Type managers can utilize sub-managers to handle specific aspects of a domain.

Key Concepts

• Instantiation: Sub-managers can be instantiated by their parent manager using the getSubManager() method.
• Search Integration: You can use search keys defined in a sub-manager directly within the parent manager. This allows you to filter the parent manager's results using the specialized criteria of its sub-managers.
• Configuration: The mshop/type/manager/submanagers key accepts an array of manager names that the type manager is allowed to instantiate.

// mshop/type/manager/submanagers configuration
'mshop/type/manager/submanagers' => ['submanager_name_1', 'submanager_name_2']

The step-active configuration determines the fallback behavior of the checkout process.

The checkout process consists of sequential steps. If a user provides all necessary data for a step, that step is skipped. If data is missing, the system forces the user to that step.

step-active defines the specific step the user is directed to if all preceding steps have been successfully completed or skipped. The order of these steps is determined by the configuration of sub-parts in the checkout client.

Never use the new operator to create Aimeos objects, as implementation variants and decorators depend on configuration. Always use the Aimeos\MShop class or a specific factory to create, search, or manipulate objects.

$manager = \Aimeos\MShop::create( $context, 'product' );
$filter = $manager->filter()->add( 'product.code', '==', 'test' );

foreach( $manager->search( $filter ) as $id => $item ) {
    // $item is the product object
}

Decorators are configuration-based tools that add features or rules to delivery and payment services. They act as a set of reusable rules that can be combined in any order to create complex logic (e.g., restricting a payment method to specific countries AND specific basket values).

Key Concepts:

• Reusability: Decorators can be applied to any type of service (delivery or payment).
• Execution Order: Decorators are called from right to left. The decorator at the end of the list executes first.
• Best Practice: Place decorators that require fewer resources at the end of the input field, and decorators that rely on external sources immediately after the service provider.
• Manual Configuration: When entering names manually in the "Provider" field, they must be case-sensitive and separated by a comma (no spaces).

PostPay,OrderCheck,Country

A JQAdm client can consist of several sub-clients that render specific parts of the output, creating a hierarchical tree. The order of the sub-clients in the configuration determines their rendering order inside the parent container.

• Reordering: Change the order of elements in the admin/jqadm/<clients>/subparts array.
• Removing: Omit a sub-client name from the array to prevent it from rendering.

Note: The layout should be fluid (CSS) to handle the addition, removal, or reordering of these structural elements.

// Example: Only rendering the first sub-client
admin/jqadm/review/subparts = array( 'subclient1' )

To reduce the number of network requests, you can combine multiple queries into a single GraphQL request. The server will return a single JSON object where each key corresponds to the requested query name.

query {
  findCustomer(code: "demo@example.com") {
    id
    type
    code
    label
  }
  searchProducts(filter: "{}") {
    items {
      id
      type
      code
      label
    }
    total
  }
}

JQAdm clients can be composed of multiple sub-clients that render specific parts of the output. This creates a hierarchical tree of clients where each sub-client's output is placed inside the container of its parent.

• Rendering Order: The parent client's code is printed first, followed by the sub-clients in the order they are listed in the subparts array.
• Reordering: You can change the visual order of elements by reordering the strings in the subparts array.
• Removing Parts: To prevent a sub-client from rendering, simply omit its name from the subparts array.

Note: Because clients generate structural JQAdm, your CSS should be designed to handle fluid layouts when content is added, removed, or reordered.

// Example: Reordering and removing subparts
admin/jqadm/product/related/subparts = array( "subclient1", "subclient2" )