Important

You are browsing the documentation for version 3.1 of OroCommerce, OroCRM and OroPlatform, which is no longer maintained. Read version 5.1 (the latest LTS version) of the Oro documentation to get up-to-date information.

See our Release Process documentation for more information on the currently supported and upcoming releases.

Differences to Common Symfony Applications

When you are familiar with building Symfony applications from scratch, you will recognize many well known building blocks when you start your first project using OroPlatform or OroCRM. However, there are some not so subtle differences you need to understand to efficiently develop your application.

This article will give you a short overview about the most important things OroPlatform differs from usual Symfony applications. Each section will link to other resources where you can learn more about a particular feature.

The Application Kernel

In Symfony applications, you usually register your own bundles as well as all the third-party bundles from the vendor directory in the famous AppKernel class. This is not needed when using OroPlatform. It ships with it own kernel that discovers bundles under the src and the vendor directories automatically if the contain a bundles.yml configuration file in their Resources/config/oro directory.

This file has to contain a list of bundle classes to initialize under the bundles key. usually, this will only be one class name:

1# src/Acme/DemoBundle/Resources/config/oro/bundles.yml
2bundles:
3    - Acme\DemoBundle\AcmeDemoBundle

Optionally, you can also specify a priority. The priority defines the order in which bundles will be loaded. If you omit the priority, its value will implicitly be 0:

1# src/Acme/DemoBundle/Resources/config/oro/bundles.yml
2bundles:
3    - { name: Acme\DemoBundle\AcmeDemoBundle, priority: 10 }

Caution

Other than what you would probably expect, a higher priority does not mean that a bundle is loaded before a bundle with a lower priority. Instead, lower prioritized bundles will be loaded first.

Tip

The default priority for all bundles is 0.

Routing Configuration

You can configure routes for your controller actions the same way that you are used with Symfony. However, usually you would manually an import for your routing configuration in the main routing.yml file in your config directory like this:

1# config/routing.yml
2default_controller:
3    resource: "@AcmeDemoBundle/Controller/DefaultController.php"
4    type:     annotation
5
6acme_demo:
7    resource: "@AcmeDemoBundle/Resources/config/routing.yml"
8    prefix: /demo

With OroPlatform, you can still configure your routes the way you like. Though as long as you create a main routing.yml file located in the bundle’s Resources/config/oro directory, you do not have to register your routing config in the application config, but it will be discovered automatically.

Access Control Lists

When it comes to Access Control Lists (ACLs), things are getting complicated. You need to deal with the ACL provider, object identities, ACEs, the mask builder, etc. OroPlatform makes things easier by providing an @Acl annotation that you can use to define an ACL and to protect a controller in a single step:

 1// src/Acme/DemoBundle/Controller/BlogController.php
 2namespace Acme\DemoBundle\Controller;
 3
 4use Oro\Bundle\SecurityBundle\Annotation\Acl;
 5
 6// ...
 7
 8/**
 9 * @Acl(
10 *     id="acme_demo.blog_post_view",
11 *     type="entity",
12 *     class="AcmeDemoBundle:BlogPost",
13 *     permission="VIEW"
14 * )
15 */
16public function indexAction()
17{
18    // ...
19}

Furthermore, once an ACL has been defined, you can reuse it using the @AclAncestor annotation:

 1// src/Acme/DemoBundle/Controller/BlogController.php
 2namespace Acme\DemoBundle\Controller;
 3
 4use Oro\Bundle\SecurityBundle\Annotation\AclAncestor;
 5
 6// ...
 7
 8/**
 9 * @AclAncestor("acme_demo.blog_post_view")
10 */
11public function postAction()
12{
13    // ...
14}

See also

Read more in the Security documentation.

Extension Management

Using composer, you can easily pull in third-party libraries and bundles that you need in your application. This does not change when using OroPlatform. But additionally to the common dependency management with Composer, you can also install a special type of package - an Oro Extension. An extension is a package that adds new features to the Platform. To achieve this, the OroDistributionBundle leverages Composer and Packagist. All extensions are feature on the Oro Marketplace. The cool thing is that you do not have to use the command-line to install extensions (of course, you can do this if you want to), but that a user with admin permissions can install them on their own in the UI.

See also

You can also add your own extension to the Oro Marketplace.