Welcome to the new eZ Publish 5.x Kernel, this code repository contains several layers of API's and implementation of them. However it does not contain all parts that make up the eZ Publish 5 install, for the full eZ Publish 5 package including bundles, Legacy Stack, install doc and more; please see our ezpublish-community repository.
Legacy Stack: Legacy kernel (4.x) + extensions
eZ Publish 5.x is a bottom up rewrite of eZ Publish, so a conservative approach where taken on backwards compatibility by bundling both Legacy Stack (4.x) and 5.x Stack together in one integrated package (ref ezpublish-community repository above).
In addition to the BC reason, the second reason is that eZ Publish 5.x does not yet provide own UI's, editor and admin gui is for the time being still provided by Legacy Stack.
The legacy integrations are done in many parts of the systems, making it possible to use both kernels in the same request, hence being able to do a smooth transition from existing 4.x installation to 5.x installation going forward.
However for performance reasons we recommend trying to use either legacy with "legacy_mode" turned on or pure 5.x Stack on a siteaccess case by case basis. This will still make sure cache and other integrations work together (something that is not the case if you point Apache directly to eZ Publish Legacy), but will avoid duplicate lookups ("fallbacks").
5.x Stack: 5.x kernel + Bundles (former extensions)
The highest level in the eZ Publish 5 architecture are bundles that builds on top of everything bellow, this is where most eZ Publish 5 Bundles will be written. They will exist in separate git repositories, and optionally defined as dependencies in your project composer.json file (see ezpublish-community repository).
These bundles are important parts of the eZ Publish 5.x kernel.
- Core Bundle: Provide additional features to a standard Symfony2 distribution like multilingual UrlAlias routing, siteaccess matching, permissions and helpers for Public API use.
- Legacy Bundle: Integrations with Legacy kernel, like fallbacks and code reuse across 5.x/Legacy Stack.
- REST Bundle: Integration of REST API to 5.x (Symfony) Stack
You can find these in eZ/Bundle and their lower level parts in:
- eZ/Publish/Core/REST The REST API implementation
- eZ/Publish/Core/MVC MVC implementation that integrate with Symfony and Legacy
Public API currently provides access to the Content Repository of eZ Publish, exposing Content, Locations (former Nodes), Sections, Content Types (former Content Classes), User Groups, Users and Roles. It also provides a new clear interface for plugging in custom field types (former Datatypes).
Public API is built on top of a set of SPI's abstracting storage/file/* functionality. By using Public API your code will be forward compatible to future releases based on enhanced, more scalable and more performant storage engines. It is also fully backwards compatible by using the included "Legacy" storage engine, which stores data in the way legacy kernel is used to finding it.
Important parts of this layer is:
- eZ/Publish/API Public API Interfaces
- eZ/Publish/Core/Repository Public API Repository implementation
Service Provider Interfaces are interfaces that can contain one or several implementations, in some cases Public API will only be able to use one at a time; Persistence (database), IO (file system). In other cases it expects several implementations; FieldTypes (former DataTypes), Limitations (permissions system).
SPI layer is currently considered "private" as it will still undergo changes, it will be made "final" by the time we have a fully working NoSQL implementation of Persistence and scalable IO storage implementation like S3. Meaning you can make your own implementation if you want, but we don't guarantee that it will work across versions.
Currently SPI consists of:
- eZ/Publish/SPI Service provider interfaces
- eZ/Publish/Core/Persistence/Legacy Legacy Storage-Engine (Persistence-handler)
- eZ/Publish/Core/Persistence/InMemory InMemory Storage-Engine (for unit testing)
- eZ/Publish/Core/IO IO (file) Handlers; Legacy, Dispatcher and InMemory (for unit testing)
- PHP 5 Modules: php5_intl php5_xsl php5_gd php5_sqlite
- Database: sqlite3
You can also run tests (slower) on mysql or postgres, see .travis.yml for how.
- Clone this repo
git clone https://github.com/ezsystems/ezpublish-kernel.git - Enter directory
cd ezpublish-kernel - Get Composer using curl
curl -s http://getcomposer.org/installer | php - Install dev dependencies:
php composer.phar install --prefer-dist --dev - Copy config.php-DEVELOPMENT
cp config.php-DEVELOPMENT config.php - Execute
phpunit -vc phpunit*.xmlwith one of:- phpunit.xml unit test xml configuration
- phpunit-integration-legacy.xml integration test xml configuration for running integration tests with Legacy Storage engine
This should produce similar result as travis. If you don't double check .travis.yml for up-to-date info on how travis is setup.
Submitting bugs, improvements and stories is possible on https://jira.ez.no/browse/EZP
eZ Publish 5.x is a fully open source, community-driven project, and code contributions are simply done via github pull requests.
Short:
- Remember to first create a issue in our issue tracker and refer to it in commits and pull requests headers, example: "Fix EZP-20104: ContentController should return error status when content is not found" or "Implement EZP-201xx: Add support for X in Y"
- If you want to contribute implementation specification proposals, place them in doc/ folder.
- Keep different changes in different commits in case cherry-pick is preferred instead of a merge later.
- A Pull Request should only cover one issue
- A commit should not contain code changes at the some time as doing coding standards/whitespace/typo fixes
- TDD: Write/Change the test(s) for the change you do and commit it before you do the actual code change
- If a bug affects Public API, write or enhance a integration test to make sure the bug is covered.
- Unit tests should only use mocks/stubs and never test the full stack like integrations tests does.
- Please test/check your commits before pushing even if we have automated checks in place on pull requests:
- Run unit tests and integration test before commits
- Make sure you follow our coding standards
For further information please have a look at the related guidance page. You will, amongst other, learn how to make pull-requests. More on this here : "How to contribute to eZ Publish using GIT".
A dedicated forum has been set-up to discuss all PHP API-related topics : http://share.ez.no/forums/new-php-api
eZ Systems AS & GPL 2.0