OXID eShop v6.2.0 RC2 is published

OXID eShop v6.2.0 release candidate 2 is publicly available. You may find it tagged as https://github.com/OXID-eSales/oxideshop_metapackage_ce/releases/tag/v6.2.0-rc.2 on GitHub.

A „stable“ version is not just a software package, as for example compatible modules, documentation for this series, content of OXID Academy etc. need to be prepared and shipped as well. All this is planned to be released step by step in the next month. However, OXID eShop v6.2.0 RC2 presently is in a state of feature freeze, no more important changes, just bug fixes will be done. Updating from RC to the stable version later is like falling off a log.

Although still work in progress, the developer documentation may already give some great insights. Take a look at it!

What’s new with OXID eShop v6.2.0

With OXID eShop v6.2.0, we also introduced some changes in assembly of the compilation. Please find these information on this site: https://github.com/OXID-eSales/oxideshop_metapackage_ce/compare/v6.1.5…v6.2.0-rc.2

To see the entire change log, please turn to this page: https://github.com/OXID-eSales/oxideshop_ce/blob/v6.5.1/CHANGELOG.md


We also dared to introduce some changes that might cause adaptions to your modules. But no fear – just a few changes that are absolutely manageable:

Refactored module configuration and activation

In the mean time it became common to run an OXID eShop project in different environments like integration, staging and production. In order to simply configure modules instead of administering them separately in each environment, the module system has been extended accordingly. It is now possible to manage the environment via YAML configuration files. A classic example: environment-independent parameters like interface credentials. Depending on the environment, these parameters can be read out and set.

This is enabled with a new configuration format: OXID automatically transfers the identified module configuration of metadata.php into the new format if no configuration is found here.

Important: the parser will only deal with the configuration given by OXID. That means, if you run executable PHP code in your metadata.php you have to rewrite it, so the functionality of your module can be preserved.

When updating via composer update, a new folder var/ has to be written in parallel to source/ and vendor/. That’s why the greater directory has to be made writable for the CLI user. Please leave this state afterwards as during runtime, OXID will have to write other data to var/ as well.

Strict Metadata

Version notice

The version notice in metadata.php is mandatory from now on.

Constrains vs. constraints

So far, metadata.php incorrectly supports two notations for defining the settings “constrains” and “constraints”. From now on, we will only support the orthographically correct spelling “constraints”. If you still use “constrains” in your modules, please correct it.


Testing framework

Unit testing

With version 6 of the testing library also the test library PHPUnit changes to version 6 (previously version 4.8.26). Please change as follows:

  • If using OxidEsales\TestingLibrary\Printer methods, arguments have to be changed to namespaced PHPUnit classes (e.g. PHPUnit\Framework\Test instead of PHPUnit_Framework_Test)
  • If using OxidEsales\TestingLibrary\UnitTestCase or OxidTestCase
    • The methods getSession and getConfig are not static any longer
    • Method UnitTestCase::getMock() is deprecated, please use the new method UnitTestCase::getMockBuilder() instead.
    • Method getMock() now has the namespaced class \PHPUnit\Framework\MockObject\MockObject as return value
    • OxidEsales\TestingLibrary\UnitTestCase extends PHPUnit\Framework\TestCase with the result that several methods in OxidEsales\TestingLibrary\UnitTestCase can’t be used anymore, for example OxidEsales\TestingLibrary\UnitTestCase::setExpectedException(). For other methods removed please see https://github.com/sebastianbergmann/phpunit/blob/6.0.0/ChangeLog-6.0.md and https://github.com/sebastianbergmann/phpunit/blob/6.0.0/ChangeLog-5.0.md
    • Usage of non-namespaced PHPUnit classes in own tests have to be changed to the appropriate namespaced equivalent

Detailed changelog: https://github.com/OXID-eSales/testing_library/blob/v7.1.0/CHANGELOG.md

Changes in Testing Library

  • The log file has been renamed to source/oxideshop.log, also the format of the log messages has been changed for better readability. Please change your processes accordingly.
  • The dependency symfony/yaml has been updated to version 3. If you directly use symfony/yaml, changes might be necessary.
  • Removed goutte driver for acceptance tests.

Acceptance testing

  • Using OxidEsales\TestingLibrary\AcceptanceTestCase::onNotSuccessfulTest() the changed method signature has to be adapted.
  • For simple creation of acceptance tests, we introduced Codeception. OXID delivers for simple usage pre-defined objects to simplify the entry into this topic.

Installing OXID eShop v6.2.0 RC2

The most simple way to install the OXID eShop is to run the Composer command and create a project. Please make sure you have the latest version of composer installed by running composer self-update.

By default, Composer installs the OXID eShop compilation including the development resources (e. g. OXID Testing Library, IDE helper, Codesniffer). If you are planning to install the OXID eShop Compilation on production environments, make sure to add the –no-dev flag.

  • For Community Edition run:
composer create-project --no-dev oxid-esales/oxideshop-project your_project_name dev-b-6.2-rc-ce
  • For Professional Edition run:
composer create-project --no-dev oxid-esales/oxideshop-project your_project_name dev-b-6.2-rc-pe
  • For Enterprise Edition run:
composer create-project --no-dev oxid-esales/oxideshop-project your_project_name dev-b-6.2-rc-ee

Good luck checking OXID eShop v6.2.0 out! Please let us know in the comments of this blog post what you think and if you have requests.



Start the discussion at OXID forums

Prior comments
2 replies

Trackbacks & Pingbacks

  1. […] den soeben augeführten Punkten gab es außerdem noch Änderungen im Bereich Modulhandling (Aktivierung, Deaktivierung, Import, Export), Verwendung von QueryBuilder in Modulen, […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *