@@ -24,7 +24,7 @@ Working with cached Container
24
24
Before building it, the kernel checks to see if a cached version of the container
25
25
exists. The ``HttpKernel `` has a debug setting and if this is false, the
26
26
cached version is used if it exists. If debug is true then the kernel
27
- :doc: `checks to see if configuration is fresh<components/config/caching> `
27
+ :doc: `checks to see if configuration is fresh</ components/config/caching> `
28
28
and if it is, the cached version of the container is. If not then the container
29
29
is built from the application-level configuration and the bundles's extension
30
30
configuration.
@@ -51,11 +51,11 @@ Bundle-level Configuration with Extensions
51
51
52
52
By convention, each bundle contains an Extension class which is in the bundle's
53
53
``DependencyInjection `` directory. These are registered with the ``ContainerBuilder ``
54
- when the kernel is booted. When the ``ContainerBuilder `` is :doc: `compiled<components/dependency-injection/compilation> `,
54
+ when the kernel is booted. When the ``ContainerBuilder `` is :doc: `/ compiled<components/dependency-injection/compilation> `,
55
55
the application-level configuration relevant to the bundle's extension is
56
56
passed to the Extension which also usually loads its own config file(s), typically from the bundle's
57
57
``Resources/config `` directory. The application-level config is usually processed
58
- with a :doc: `Configuration object<components/config/definition> ` also stored
58
+ with a :doc: `Configuration object</ components/config/definition> ` also stored
59
59
in the bundle's ``DependencyInjection `` directory.
60
60
61
61
Compiler passes to allow Interaction between Bundles
0 commit comments