The se7enxweb forks and replace #

This page is for developers who see se7enxweb/* packages in composer.lock and Ibexa\ namespaces in the code and want to understand how the two fit together. It explains the forks, the replace mechanism and how to check your project.

Contents #

1. Why there are forks
2. Which DXP packages are forks
3. How replace works
4. Checking your project
5. The rule: never both
6. Namespaces stay the same

Why there are forks #

The DXP continues the eZ Platform and Ibexa OSS line. Where an upstream package needed a change for this line, 7x forked it under the se7enxweb vendor: product naming in the administration, build paths that work with only se7enxweb packages installed, PHP 8.4 compatibility, and the exponential: command names (Platform package forks and command renames). Where no change was needed, the DXP requires the upstream package as it is.

Which DXP packages are forks #

Every other ibexa/* package in the metapackage is the upstream package. The full table of the family's forks is the Platform package map.

How replace works #

A package that lists another under replace tells Composer that it provides that package. Composer then installs only the fork, and every package that requires the upstream name is satisfied by it. Since 2026-04-12 the forks declare replace with the wildcard *, so the fork satisfies any version constraint another package puts on the upstream name. One exception you can see in an installed project: se7enxweb/fieldtype-richtext replaces ibexa/fieldtype-richtext with self.version and ezsystems/ezplatform-richtext with * (its composer.json) (Step 1).

The result: a third-party bundle that requires ibexa/admin-ui installs in a DXP project and uses se7enxweb/admin-ui.

Checking your project #

composer why ibexa/admin-ui                              # expect: se7enxweb/admin-ui replaces it
composer why netgen/layouts-core                         # expect: se7enxweb/layouts-core
composer show | grep -E "^(ibexa|ezsystems|netgen)/"     # upstream packages actually installed

If an upstream package whose fork you have is listed as installed, something requires a version the fork does not cover, or the lock file is older than the fork. Update on a copy of the project and read the plan Composer prints.

The rule: never both #

A project must never have a fork and its upstream installed together. Both define the same classes in the same namespaces, and the autoloader would load one of them unpredictably. Symptoms are classes that "lose" methods, admin builds that read files from vendor/ibexa/... instead of vendor/se7enxweb/..., and errors that appear only on some requests (The se7enxweb forks, never install both).

Namespaces stay the same #

The forks keep the upstream PHP namespaces (Ibexa\...), service ids and Twig namespaces. Code written for the upstream API works unchanged; only the Composer package names and some user facing strings differ. That is why these pages name ibexa/* packages and Ibexa\ classes: they are real identifiers, not the product's name.

Related pages #

• Reading the metapackage
• Contributing to the forks
• Platform package forks, command renames and version rules
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.