Download the PHP package craue/config-bundle without Composer

Information

CraueConfigBundle manages configuration settings stored in the database and makes them accessible via a service in your Symfony project. These settings are similar to those defined in parameters.yml but can be modified at runtime, e.g. by an admin user.

Installation

Get the bundle

Let Composer download and install the bundle by running

in a shell.

Enable the bundle

If you don't use Symfony Flex, register the bundle manually:

Create the table

Preferably you do this by calling

or

or however you like.

Add the route to manage settings (optional)

You can either import the default routing configuration

...or add your own to have full control over the URL pattern.

Some CSS is needed to render the form correctly. Install the assets in your project:

Usage

Defining settings

This bundle does not provide functionality to create new settings because this would make no sense at runtime. Those settings will be used in your application and thus code needs to be written for that. This means that you have to create new settings in the database table craue_config_setting yourself, e.g. using a migration.

Managing settings' values

If you added the route described above you can manage the values of all defined settings in a simple form. By default, you can access that form by browsing to /settings/modify. But you probably want to limit access to this form in your security configuration.

Reading and writing settings

For accessing settings, the bundle provides the service Craue\ConfigBundle\Util\Config. To use it directly in a controller, either add an autowired type-hinted argument to the action...

...or let your controller extend Symfony\Bundle\FrameworkBundle\Controller\AbstractController and make the service alias craue_config available by defining getSubscribedServices:

The service defines the following methods:

• all() - get an associative array of all defined settings and their values
• get($name) - get the value of the specified setting
• getBySection($section) - like all(), but get only settings within the specified section (or those without a section if explicitly passing null)
• set($name, $value) - set the value of the specified setting
• setMultiple([$name1 => $value1, $name2 => $value2]) - set values for multiple settings at once

Keep in mind that each setting has to be present, or an exception will be thrown.

Usage in Twig templates

The Twig extension in this bundle supports reading settings directly in your template.

Enable caching (optional)

Caching is disabled by default. To reduce the number of database queries, configure the cache pool craue_config_cache. For example, to enable a filesystem-based cache:

Check the Symfony Cache component documentation for details.

If you modify settings outside of your app (e.g., using Doctrine migrations), make sure to also clear the cache pool using the corresponding Symfony cache command.

Customization

Redirect to a different page after submitting the built-in form

If you've enabled the build-in form, you can define where to redirect on successfully saving the changes by setting the target route name:

Rendering of settings in sections

If you want to render settings in a group (called section here), you'll have to assign those settings a common section name (in the database). Optionally, you can influence the order of these sections:

Settings without a section will be rendered at first. Sections without explicit ordering are rendered at last.

Translation

You can add translations for all settings (and sections) to be shown in the form by adding them to translation files with the CraueConfigBundle domain, e.g.

Using a custom entity for settings

The custom entity has to provide a mapping for the field value. The class BaseSetting defines this field, but no mapping for it. This allows easy overriding, including the data type. In the following example, the value field will be mapped to a text column, which will in turn render the built-in form fields as textarea.

So create the entity and its appropriate mapping:

And make the bundle aware of it:

Using a non-default entity manager

By default, the bundle uses Doctrine's default entity manager. If you use another entity manager for the settings, configure its name:

The bundle's Doctrine mapping is automatically registered with the configured entity manager.