As you might already know, starting from OXID eShop version 6 we completely stripped down the editions and run them in completely different GitHub repositories in a manner that OXID eShop Community Edition is the basis, additional code for Professional Edition as well as for Enterprise Edition resides in separate repositories on top of the other edition.
This step not only made it possible to actively participate in the development as well as making cross-upgrades between the editions easier. It also cleared the way to make use of modern, state-of-the-art technologies like composer and namespaces for PHP classes in OXID eShop for good reasons:
- comply with PSR-1, PSR-2, PSR-4 coding standards
- the usage of composer is possible, including many features like the composer autoloader. This results e.g. in performance improvements.
- namespaces are a de facto standard in the PHP world
And of course, the introduction of namespaces also led to a number of questions and decisions I want to explain in the following section:
Editions and unified namespaces
Each OXID eShop edition is now located in its own namespace. For example, OXID eShop Community Edition is located in the namespace OxidEsales\EshopCommunity.
OXID eShop editions inherit from each other. Community Edition is a subset of Professional Edition where Professional Edition is a subset of OXID eShop Enterprise Edition. This means, for example, the namespace OxidEsales\EshopEnterprise\Application\Model\Article inherits from OxidEsales\EshopProfessional\Application\Model\Article as you can see in figure 1:
Introducing namespaces also leads to the deprecation of the former non-namespaced classes like oxarticle. The new namespaced class Article from now on replaces the deprecated (for backwards compatibility) class oxarticle.
Module developers usually extend OXID eShop classes in order to adapt them to their needs. This raised several questions:
- Which namespaced class should a module developer extend now? If a module developer would extend OxidEsales\EshopEnterprise\Application\Model\Article, this module would not work in a shop based on OXID eShop Community Edition.
- Also: should a developer re-write all source code with the new namespaced classes?
One of the benefits of OXID eShop is its backwards compatibility and the possibility easy updates. Even for the major update from OXID eShop 5.3 to OXID eShop 6, we wanted to keep the effort and costs for projects and modules as small as possible. For these reasons, we decided for a technical solution which minimizes the costs for updates and fulfills the requirements of a software that is entirely compatible with namespaces as well as with composer.
Here are the results of this decision:
- The usage of non-namespaced classes like oxArticle is still possible in OXID eShop 6. They are deprecated but still usable for the period of transition.
- The usage of composer and namespaces in a module is possible but not mandatory.
- We needed a new namespace which wraps the edition namespaces. We called this namespace “unified namespace”. The unified namespace classes can be used to make a feature working in all editions.
How did we reach these goals?
We decided to implement the unified namespace classes as separate classes and the backwards compatible classes as class aliases (PHP method class_alias) because of reasons I will explain immediately.
We called the unified namespace \OxidEsales\Eshop. A class in the unified namespace extends all other existing OXID eShop edition classes. If your OXID eShop is, for example, based on a Professional Edition, the inheritance would look like in figure 2.
If your OXID eShop is based on an Enterprise Edition, the inheritance would look like figure 3.
This means, a module can extend the unified namespace class OxidEsales\Eshop\Application\Model\Article, and the module will work in all editions.
The deprecated class “oxarticle” is created – as mentioned before – via the PHP method class_alias and is not a real class. This constellation has several benefits:
- You still can use the backwards compatible class “oxarticle” e.g. in type hints or when catching exceptions. But if you request the type of a class, either the unified namespace class name (OxidEsales\Eshop\Application\Model\Article in our case) or a module class which extends this unified namespace class (see figure 4) will be returned.
- The backwards compatible classes can be removed at any point in the future without breaking the behaviour for module or project developers – once everybody of you guys use unified namespaces.
Generating unified namespace classes
Every time, at the end of executing composer install, composer update and composer require, unified namespace classes will be generated. That’s why you’d have to follow certain steps on updating an OXID eShop like described here.
The generated unified namespace classes are located in the folder vendor/oxid-esales/unified-namespace-generator/generated. Browsing through these classes, you can, for example, find out which backwards compatible class was replaced by what namespaced new class:
class Article extends \OxidEsales\EshopEnterprise\Application\Model\Article
OXID eShop 6 introduced several new concepts like namespaces in PHP classes and autoloading via PSR standards. The integration of proven solutions like composer helped us with this goal.
We did this a backwards compatible way which minimizes the costs for updating projects and modules. Module developers can use new features like PHP namespaces in their modules but it is not mandatory to fully update OXID eShop 5.3 compatible modules.
In case of any requests or comments please feel free to use the comment section below.