Developers/Create an extension

From Aimeos documentation

Developers
Other languages:
English 100% • ‎русский 0%


2018.x+ version

Extensions are an easy way to add new features, change existing ones or manage configurations specific for your Aimeos shop project without touching the core code. Thus, you are still able to update to later versions while keeping your own code separate.

Create a new extension for your project by using the Aimeos extension builder. It generates a .zip package for download which contains the ready to use extension. Furthermore, it's able to create installable packages for content management systems with the Aimeos extensions pre-configured.



Location

Your new extension has to be placed in the Aimeos extension directory. This directory is usually named "./ext/" if you are working with either the Laravel, Symfony or SlimPHP framework.

CMS applications like TYPO3 require the Aimeos extension to be part of an application specific extension. The Aimeos extension builder can create both at the same time, packaged together in one .zip file. The Aimeos extension is then placed in the appropriate subdirectory like "./Resources/Private/Extensions/" for TYPO3.

Create only one extension for your project and add all code that modifies and extends Aimeos to that project specific extension. The main advantage to this approach is that you will only have one place to look. It will also keep the response times low because less directories have to be looked at for templates, configuration settings, and translations.

The extension files and directories have to be placed in a subdirectory of the Aimeos extension directory ( e.g. "./ext/myextname/"). This applies to the generated .zip file too, which must be unpacked in your newly created subdirectory.

You can use your extension immediately to overwrite existing template with your own version. If you want to add classes to your extension adding new features, make sure they will be found by composer. If you add your Aimeos extension to an own repository and add that repository to your composer.json file, you are on the save side because composer automatically configures its class loader correctly.

If you only copy your new Aimeos extension to the ./ext/ directory, your classes won't be found by composer. To make them known to composer, you need to add the directories to the composer.json autoload section:

  1.     "autoload": {
  2.         "classmap": [
  3.             "ext/<yourext>/lib/custom/src",
  4.             "ext/<yourext>/controller/common/src",
  5.             "ext/<yourext>/controller/frontend/src",
  6.             "ext/<yourext>/controller/jobs/src",
  7.             "ext/<yourext>/client/html/src",
  8.             "ext/<yourext>/client/jsonapi/src",
  9.             "ext/<yourext>/admin/html/src",
  10.             "ext/<yourext>/admin/jsonadm/src"
  11.         ]
  12.     },

Afterwards, you have to run

composer dump-autoload

to update the composer class map file for the autoloader.

In case you forget to add the directories of your Aimeos extension to the composer.json of your application, you will get class not found errors!

Structure

An Aimeos extension reflects the directory structure of the core and contains these main directories:

  • admin/jqadm
  • admin/jsonadm
  • client/html
  • client/jsonapi
  • controller/common
  • controller/frontend
  • controller/jobs
  • lib/custom

admin

There's a shared directory between all admin interfaces for translations:

  • i18n/ (gettext translation files)

admin/jqadm

The administration interface based on Bootstrap and JQuery including the classes plus templates generating the output. Also a default theme is included and it contains:

  • src/ (PHP client classes of the extension)
  • templates/ (html templates)
  • tests/ (unit tests for the client classes)
  • themes/ (default themes and shared JS files)
  • build.xml (automated development task)

There's a shared directory between all admin interfaces for translations:

  • i18n/ (gettext translation files)

admin/jsonadm

The directory for the admin JSON REST API contains:

  • src/ (PHP admin classes of the extension)
  • templates/ (html templates)
  • tests/ (unit tests for the admin classes)
  • i18n/ (gettext translation files)
  • build.xml (automated development task)

Tutorials:

client

There's a shared directory between all clients for translations:

  • i18n/ (gettext translation files)

client/html

The HTML front-end and the classes plus templates generating the HTML output. Also the default themes are included there and the directory contains:

  • src/ (PHP client classes of the extension)
  • templates/ (html templates)
  • tests/ (unit tests for the client classes)
  • themes/ (default themes and shared JS files)
  • build.xml (automated development task)

Tutorials:

Theme tutorials:

client/jsonapi

The JSON REST API for the front-end and the classes plus templates generating the JSON output:

  • src/ (PHP client classes of the extension)
  • templates/ (html templates)
  • tests/ (unit tests for the client classes)
  • build.xml (automated development task)

Tutorials:

controller/common

Code shared by more than one controller is located in the "common" directory. This includes mainly the media and order processing code as well as the CSV import processors and caches:

  • config/ (default configuration for the controllers)
  • src/ (PHP controller classes)
  • tests/ (unit tests for the controller classes)
  • build.xml (automated development task)

controller/frontend

The front-end clients use these classes to perform standard actions like retrieving product lists, adding a product to the basket, or doing the necessary actions for a checkout. The directory layout includes:

  • i18n/ (gettext translation files)
  • src/ (PHP front-end controller classes)
  • tests/ (unit tests for the front-end controller classes)
  • build.xml (automated development task)

controller/jobs

A shop has to run several tasks in an asynchronous manner, like sending e-mails or payed orders to the ERP system. Each class in this part of the directory tree performs one task and they are located in:

  • i18n/ (gettext translation files)
  • src/ (PHP job controller classes)
  • tests/ (unit tests for the job controller classes)
  • build.xml (automated development task)

Tutorials:

lib/custom

For the low level layer of the core including the adapters and data access manager layer (lib/mwlib and lib/mshoplib in the core), the lib/custom directory is used and it contains:

  • config/ (default configuration for the managers)
  • i18n/ (gettext translation files)
  • setup/ (setup tasks creating and updating the database tables)
  • src/ (PHP manager, item and provider classes)
  • tests/ (unit tests for the classes)
  • build.xml (automated development task)

Tutorials:

Manifest

The manifest.php is one of the most important files in an extension. It describes the extension and where are the directories that should be included, used for configuration, translation and setting up the database. It also contains a custom section which contains the configuration for specific parts of the shop.

The basic structure looks like:

  1. <?php
  2. return array(
  3. 	'name' => '<vendor key>-<extension name>',
  4. 	'depends' => array(
  5. 		// ...
  6. 	),
  7. 	'config' => array(
  8. 		// ...
  9. 	),
  10. 	'include' => array(
  11. 		// ...
  12. 	),
  13. 	'i18n' => array(
  14. 		// ...
  15. 	),
  16. 	'setup' => array(
  17. 		// ...
  18. 	),
  19. 	'custom' => array(
  20. 		// ...
  21. 	),
  22. );

depends

When you overwrite templates or configuration settings in your own extension, the Aimeos bootstrap process have to make sure that the file are loaded in the correct order. For templates, this means to look into the custom extensions first, configuration files from custom extensions must be added last so they can overwrite the configuration from the core and other Aimeos extensions. By depending on the core and the Aimeos extensions, you can be sure that you are able to overwrite both, templates and configuration settings. The default dependencies are:

  1. 'depends' => array(
  2. 	'aimeos-core',
  3. 	'ai-admin-jqadm',
  4. 	'ai-admin-jsonadm',
  5. 	'ai-client-html',
  6. 	'ai-client-jsonapi',
  7. 	'ai-controller-jobs',
  8. 	'ai-controller-frontend',
  9. ),

config

Aimeos is very flexible by using a lot of configuration, especially by avoiding to hard-code any SQL statements. These configuration is provided in .php files in the "config" directory of the custom library part and may look like:

  1. 'config' => array(
  2. 	'lib/custom/config',
  3. ),

include

The list of directories that contains the source code and which should be used by the autoloader to search for the PHP class files. If your extension provides classes for managers, controllers and clients, it will usually look like:

  1. 'include' => array(
  2. 	'lib/custom/src',
  3. 	'client/html/src',
  4. 	'controller/frontend/src',
  5. 	'controller/extjs/src',
  6. 	'controller/jobs/src',
  7. 	'admin/jqadm/src',
  8. ),

i18n

Strings that are displayed in the front-end or in the adminstration interface should be available in the native language of the customer or the editor. Aimeos uses the well known and mature gettext infrastructure to extract these strings and makes them available as .po files which can be easily translated using standard tools. After translation to a new language these files are compiled into a binary representation for fast lookups while generating the output. The "i18n" section of the manifest file lists the directories that contains .po files like this:

  1. 'i18n' => array(
  2. 	'admin' => 'admin/i18n',
  3. 	'client' => 'client/i18n',
  4. 	'custom' => 'lib/custom/i18n',
  5. 	'controller/frontend' => 'controller/frontend/i18n',
  6. 	'controller/extjs' => 'controller/extjs/i18n',
  7. 	'controller/jobs' => 'controller/jobs/i18n',
  8. ),

setup

Setup tasks are a great way to create and update your database structure. They are part of your extension and take care of creating your tables and updating them as changes occur. Setup tasks are usually only located in the lib/custom/setup directory:

  1. 'i18n' => array(
  2. 	'lib/custom/setup',
  3. ),

custom

The "custom" section of the manifest.php is reserved for directory configurations that are specific for the different parts of the library. The directory for the library part must the key and the value is always a list of subdirectories or files that are required for specific the purpose. A full example would be:

  1. 'custom' => array(
  2. 	'admin/jqadm/templates' => array(
  3. 		'admin/jqadm/templates',
  4. 	),
  5. 	'admin/jsonadm/templates' => array(
  6. 		'admin/jsonadm/templates',
  7. 	),
  8. 	'client/html/templates' => array(
  9. 		'client/html/templates',
  10. 	),
  11. 	'client/jsonapi/templates' => array(
  12. 		'client/jsonapi/templates',
  13. 	),
  14. 	'controller/jobs' => array(
  15. 		'controller/jobs/src',
  16. 	),
  17. 	'controller/jobs/templates' => array(
  18. 		'controller/jobs/templates',
  19. 		'client/html/templates',
  20. 	),
  21. ),
admin/jqadm/templates 
Specifies the directories that contains the HTML template files for the JQAdm interface, either new ones for newly implemented sub-parts or files with the same name of existing ones which will be used instead of the original files.
admin/jsonadm/templates 
List of directories that contains the template files for the JSON admin clients, either new ones or files with the same name of existing ones which will be used instead of the original ones.
client/html/templates 
Specifies the directories that contains the HTML template files for the HTML clients, either new ones for newly implemented sub-parts or files with the same name of existing ones which will be used instead of the original files.
client/jsonapi/templates 
List of directories that contains the template files for the front-end JSON REST API clients, either new ones or files with the same name of existing ones which will be used instead of the original ones.
controller/jobs 
Describes the source directory which should be used to generate a list of asynchronous tasks presented to the shop administrator.
controller/jobs/templates 
List of directories that contains the template files for the job controllers, either new ones or files with the same name of existing ones which will be used instead of the original ones.

phing.xml

Phing is a great tool for automating tasks and in Aimeos it's used to e.g. set up the database, execute the unit tests or handle the extraction and compilation of the translations. For an Aimeos extension it's not absolutely necessary but can help a lot during development. Therefore, the XML configuration files for phing are always included in the packages generated by the Aimeos extension builder. The phing.xml file in the base directory of your extension should contain at least this targets:

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <project name="<extension name> extension" default="test">
  3.   <target name="test" description="Executes all tests"></target>
  4.   <target name="testperf" description="Executes all performance tests"></target>
  5.   <target name="coverage" description="Generates the code coverage report"></target>
  6.   <target name="check" description="Executes all tests"></target>
  7.   <target name="clean" description="Cleans up temporary files"></target>
  8.   <target name="i18n" description="Creates all translation files"></target>
  9.   <target name="build" description="Builds package for deployment"></target>
  10.   <target name="release" description="Creates new release" depends="build"></target>
  11. </project>

For a detailed example which also contains the executed tasks, please have a look at the extensions generated by the Aimeos extension builder.

Running the tests of your extension

The easiest way is using Phing for executing the unit tests of extensions. You also need composer and set up a database that will contain the unit test data. Then follow these steps:

  • Checkout the Aimeos core somewhere on your disk (git clone https://github.com/aimeos/aimeos-core)
  • Configure your database connection in ./config/resources.php available in the cloned directory
  • Copy your extension to the ./ext/ directory created during cloning the repository
  • Execute composer update to install the dependent packages and development tools
  • Run vendor/bin/phing setup to populate the database with unit test data from the cloned directory
  • Execute vendor/bin/phing -Ddir=ext/<extname> testext to run the tests also from the cloned directory

That are the same steps as done by the integration tests of every extension running on the Travis-ci platform: .travis.yml example