OXID eShop Community Edition

The Internal namespace is organized into four main functional directories:

• Container: Contains classes that allow traditional code to access the Internal namespace via the ContainerFactory.
• Domain: Contains all packages that directly handle business logic.
• Framework: Contains application infrastructure classes that do not include business logic.
• Transition: Contains classes that allow the Internal namespace to interact with traditional code.

As of v8.0.0-alpha.2, product image functionality has been redesigned. Images are no longer limited to 12 and are stored in separate tables rather than oxarticles.

Important Breaking Change: The following methods on Article and ArticleDetails have been removed in favor of a new MediaView-based access pattern. You must migrate your code to use the new Internal\Domain\Media and Internal\Domain\Product\Media infrastructure.

Removed Methods (Do not use):

• Article: getThumbnailUrl(), getIconUrl(), getPictureUrl(), getMasterZoomPictureUrl(), getZoomPictureUrl(), getPictureFieldValue(), getMasterPicturePath(), getPicturesProduct(), getMasterZoomPicture(), getZoomMedia()
• ArticleDetails: getActPicture(), morePics(), getIcons(), showZoomPics(), getZoomPics()

The Internal namespace provides the public API of OXID eShop through interfaces. You can access these services using the Symfony DI container.

In traditional code, you can fetch the container via the ContainerFactory and use the get() method to retrieve a service. Note that only services explicitly marked as public can be accessed this way; all other services are protected.

When developing modules, you can define your own services and inject any service from the Internal namespace directly via dependency injection.

// Traditional code access pattern
$container = ContainerFactory::getContainer();
$service = $container->get(SomeServiceInterface::class);

Files within the downloads directory are stored based on how they were uploaded:

• Admin Interface Uploads: Files uploaded via the OXID eShop admin interface are renamed to a hash and stored in separate subdirectories.
• Manual Uploads: Files uploaded manually (e.g., via FTP) are stored in the uploads directory.

The database layer has undergone significant changes in v8.0.0-alpha.2:

• Shop Setup: Shop setup now proceeds with an empty database. The database_schema.sql file no longer removes existing oxmigrations tables during setup; therefore, the schema dump should only be applied to a completely empty database.
• Database Adapter: The DatabaseConfiguration namespace has been renamed. The getScheme() method has been replaced by getDriver().
• Error Handling: The DatabaseInterface::getLastInsertId() method will now throw a DatabaseErrorException if no insert ID is available.
• Result Sets: The ResultSet constructor now strictly requires a Doctrine\DBAL\Statement object.

Interfaces within the Internal namespace are subject to change.

• Stable Interfaces: Only interfaces explicitly marked with the @stable annotation follow the official OXID eShop deprecation procedure.
• Other Interfaces: May change between versions. While they are generally kept stable for patch versions (to allow for security fixes), they may change in minor versions without following the standard deprecation process.

When writing modules that inject Internal services, be aware that implementations may change between versions.

OXID eShop can be installed via a compilation process. For detailed, step-by-step instructions on performing a full installation, refer to the official OXID eShop compilation installation manual.

Note: If you are looking to install a development version for the purpose of contributing to the core component, refer to the CONTRIBUTING.md file in the repository.

Refer to the official manual: https://docs.oxid-esales.com/developer/en/latest/getting_started/installation/eshop_installation.html

To improve your development experience with code completion in your IDE, you can use the eshop-ide-helper script. You must install the script from the provided repository and follow its generation instructions to enable completion for the OXID eShop codebase.

https://github.com/OXID-eSales/eshop-ide-helper

In OXID eShop v8.0.0-alpha.3, a new locale management system is introduced. You can manage locales (create, edit, delete, and assign to shops) via the Admin page.

To configure a global fallback locale for the entire shop, use the Dependency Injection (DI) parameter oxid_esales.locale.default_fallback.

Developers can use ContextInterface::getCurrentLanguageAbbreviation() to retrieve the current language code. Additionally, product images now support alt text which can be edited per image per locale in the Admin area; the storefront automatically resolves these using the locale's fallback chain.

DI parameter: `oxid_esales.locale.default_fallback`

Starting with v8.0.0-alpha.1, configuration parameters have moved from config.inc.php to environment variables and container parameters. The project now uses the Symfony Dotenv Component for registering environment variables.

Note that the oe:setup:shop command now fetches parameters from the current environment configuration, and previous command-line parameters for this command have been removed.

The oe-console script is a PHP-based CLI entrypoint used to manage OXID eShop via Symfony Console commands. It bootstraps the application container and loads available commands based on the configured shop ID.

To use the console, ensure you have run composer install so that the autoload.php file is available in your project structure. The script automatically searches for the autoloader in several parent directories.

# Basic usage (defaults to shop ID 1)
./bin/oe-console

# Specify a specific shop ID
./bin/oe-console --shop-id <ID>