Over the last 3 years, the OroTeam has worked hard to deliver OroPlatform, OroCRM, and OroCommerce features and we’ve created a lot of code for new applications, extensions, and packages. As the OroTeam continues to work on the new 2.0 release, we wanted to provide an update on the new changes our community members should expect when the next major version is released. It is especially important for those creating custom apps to understand how our code has been structured and what changes are to be expected so the process of creating new applications is smooth and straightforward.
Oro products are currently using the Symfony2 full stack framework and we are following the standards and recommendations set for that version.
Note: We are still on Symfony 2.x but planning to upgrade to 3.x with first long-term support release.
All Oro applications structures are based on the standard Symfony project structure and have app, src, vendor, and web folders in place. OroPlatform, OroCRM, and OroCommerce applications, including OroCRM Enterprise Edition, define dependency on proper application package(s) and once the dependency installation via composer occurs, the source code from all packages in the dependency list will be installed to the vendors folder.
As multiple parts of our code are reusable across different applications (i.e. OroPlatform functionality) with some functionality optional for use (i.e. OroEntitySerializedFieldsBundle), we organize all the code into composer packages which are then installed into applications with the composer install command. A typical package would include one or multiple bundles or components while defining dependencies on other packages. As an example, “oro/crm” package of the OroCRM application depends on “oro/platform” package, so once OroCRM application is installed, it has functionality of both the platform and CRM.
Forking or cloning the Oro application repository is a good starting point if you start working on any customizations. Once you have your own repository, you can update the application configurations and resources from the app folder as well as develop your own customizations and features under the src folder. Application code will be organized in bundles and could be distributed with the application repository as well as a standalone composer package if preferred.
Oro Code Namespaces
Code inside the package must be written in the scope of namespace and namespace must follow PSR-0 or PSR-4 standards. Most of the Oro applications code uses the first level namespace “Oro“, but some application specific packages use the Oro prefix in the namespace name (i.e. OroCRM, OroB2B, etc.). Once you start working on the custom code in the “src” folder of the application, we recommend using your company name, personal name, or nickname as the top-level name of the Oro code namespace. Please do not use “Oro” as the namespace in order to avoid potential naming conflicts in the future.
Structural changes in the next major version release
We have been asked multiple times by our community to make some OroPlatform and OroCRM features optional as not all businesses need them. But in order to enable cross package maintainability of the code in Oro applications, we have decided to move all code under the “Oro” top-level namespace as well as move some bundles to standalone packages so they could be used as a base for the creation of custom Oro applications structures (i.e. Call, Tasks, and Magento bundles of “oro/crm”).
In addition, we will move some bundles out of the “oro/platform” package (i.e. Reports and Calendar) so developers will be able to use them when necessary.
We have already started incorporating these changes to the newest major release of OroPlatform and OroCRM and more updates will be coming.
We are always eager to get your feedback, so please either comment on this blog or send us questions or comments via our forum.