Extension metadata file

Metadata file structure

id

The extension id must be unique. It is recommended to use vendor prefix + module root directory name. Module ID is used for getting all needed information about extension. If this module has defined config variables in “oxconfig” and “oxconfigdisplay” tables (e.g. “module:efifactfinder”), the extension id used in these tables should match extension id defined in metadata file. Also same id (“efifactfinder”) must be used when defining extension templates blocks in “oxtplblocks” table.

Please note: the extension id for modules written for OXID eShop versions >= 4.7.0 mustn’t be > 25 characters. The extension id for modules written for OXID eShop versions >= 4.9.0 mustn’t be > 93 characters. Please also see https://bugs.oxid-esales.com/view.php?id=5549.

title

Used to display extension title in the extensions list and detail information.

description

Used to display extension description in the extension detail information page. This field is multilang capable.

lang

Default extension language. Displaying extension title or description there will be checked if these fields have a selected language. If not, the selected language defined in the lang field will be selected. E.g. if admin is opened in German and extension is available in English, the English title and description value will be shown as there is translation into German.

thumbnail

Extension thumbnail filename. Thumbnail should be in root folder and it is displayed in admin under extension details page.

version

The version number of this extension.

author

The author/developer of this extension.

url

Link to module writer web page.

email

Module vendor email.

extend

On this place shall be defined which shop classes are extended by this module. Here is an example:

This information is used for activating/deactivating extension.
Take care you declare the keys (e.g. oxorder) always in lower case!
Take care you declare the file names case sensitive!
It is suggested to use lower case for file names, to avoid difficulties.

files

All module php files that do not extend any shop class. On request shop autoloader checks this array and if class name is registered in this array, loads class. So now no need to copy module classes to shop “core” or “view” folder and all module files can be in module folder.

 

blocks

In this array are registered all module templates blocks. On module activation they are automaticly inserted into database. On activating/deactivating module, all module blocks also are activated/deactivated

 

Differences in block file definition per shop/metadata version.

In OXID eShop >= 4.6 with metadata version 1.0 template block “file” value was relative to “out/blocks” directory inside module root.

In OXID eShop 4.7 / 5.0 with metadata version 1.1 template block “file” value has to be specified directly from module root.

To maintain compatibility with older shop versions, template block files will work using both notations.

Template block “file” value holding path to your customized block shoul’d be defined using full path from module directory, earlier it was a sub path from modules “out/blocks” directory,

settings

There are registered all module configuration options. On activation they are inserted in config table and then in backend you can configure module according these options. Lets have a look at the code to become a clearer view.

Each setting belongs to a group. In this case its called ‘main’. Then follows the name of the setting which is the variable name in oxconfig/oxconfigdisplay table. It is best practice to prefix it with your moduleid to avoid name collisions with other modules. Next part is the type of the parameter and last part is the default value.

In order to get correct translations of your settings names in admin one should create views/admin//module_options.php where is the language with 2 letters for example ‘en’ for english. There should be placed the language constants according to the following scheme:

So the shop looks in the file for a language constant like SHOP_MODULE_GROUP_ and for the single setting for a language constant like SHOP_MODULE_.
In php classes you can query your module settings by using the function getParameter() of oxConfig class:

or since OXID 4.7 you can also use

templates

Module templates array. All module templates should be registered here, so on requiring template shop will search template path in this array.

events

Module events were introduced in metadata version 1.1. Currently there are only 2 of them (onActivate and onDeactivate), more events will be added in future releases. Event handler class shoul’d be registered in medatata files array.

custom JavaScript / CSS / Images

Create out/src/js/, out/src/img/ and out/src/css/ directories so it fit Shop structure and would be easier to debug for other people. You can use something like this to include your scripts in to templates:

Metadata file version

Metadata file must be include metadata version info. Latest Metadata version is “1.1” used for OXID eShop versions PE / CE 4.7 and EE 5.0 ant.

Previous OXID eShop versions < 4.6 supports only metadata version "1.0" and is compatible with metadata "1.1", expect of some newly introduded features as module events. Here is an example of PayPal module metadata file:

 

Multilanguage fields

Extension description is a multilanguage field. This should be an array with a defined key as language abbervation and the value of it’s translation.

The field value also can be a simple string. If this field value is not an array but simple text, this text string will be displayed in all languages.

Mandatory fields

The list of fields that are mandatory for metadata file:

• metadata version
• id
• title
• extend
• files (if module has any php files which are used only in module, and does not extends shop classes)
• blocks (if module has any templates blocks)
• settings (if module has any settings)

Vendor directory support

All modules can be placed not directly in shop modules directory, but also in vendor directory. In this case the “vendormetadata.php” file must be placed in the vendor directory root. If the modules handler finds this file on scanning the shop modules directory, it knows that this is vendor directory and all subdirectories in this directory should be scanned also. Currently the “vendormetadata.php” file can be empty, in future here will be added some additional information about the module vendor.
Vendor directory structure example:

• modules
  • oxid
    • module1
      • module1 files…
    • module2
      • module2 files…
    • module3
      • module3 files…

In case of using a vendor directory you still need to describe file paths relatively to the modules directory: