List of TODOs for ~2.8|~3.0 compatibility:

• Twig SettingExtension deprecations
• Decide on bumping framework-bundle from 2.3 LTS to 2.6 or 2.7 LTS
• Service definition factory method #62
• FormType::getName, FormType::setDefaultOptions, buildForm via FormType FQCN

Hello,
Thank you for the bundle! It seems very useful for my purposes. The only problem is that I'm having trouble figuring out how to customize form labels. I tried adding a "label" option under "options" in the configuration file, but that had no effect. Any help would be appreciated.

I have the idea that it might be usefull to have integration with easyadmin.

I would suggest to follow Symfony best practices with coding standards. That means PSR-1 and PSR-2 + some extra Symfony stuff.

Any thoughts?

Hi. Its possible to save Entities in setting field ?

dmishh_settings:
    settings:
        project_filter:
            type: entity
            options: {class: AppBundle:Project, multiple: true, choice_label: name}

In this config it save, but then on form load (/settings/global) symfony throw error

Entities passed to the choice field must be managed. Maybe persist them in the entity manager?

I use a filesystem cache service like described in the docs. The problem is, when I change the value of a setting with the CachedSettingsManager set method, the cache with the single setting key (for example dmishh_settings__setting) is cleared, but not the cache that will be filled with the all method (dmishh_settings__).
So when I fetch the settings with $this->get('settings_manager')->all(), I get wrong values from the expired cache.
So maybe this cache should also be deleted in the set methods.

It make no sense anymore to have a User scope. We should consider renaming it to Local.

Hello and thx for your work these days !

I updated my project, and now I get an error when I want to display the built-in settings form :

The type name specified for the service "form.type.settings_management" does not match the actual name. Expected "settings_management", given "Dmishh\SettingsBundle\Form\Type\SettingsType"

You can quickly get rid of this error by replacing this line in SettingsController.php :

$form = $this->createForm('settings_management', $this->get('settings_manager')->all($owner));

by that :

$form = $this->createForm(SettingsType::class, $this->get('settings_manager')->all($owner));

(and add the corresponding use statement)
And then, delete the corresponding service.

Thx again for your work 👍

Because of Doctrine that requires PHP 5.4+ for version 2.5.0

Hi,

thanks for this nice bundle.

could you provide a symfony 4 support please ?

thanks

You mention overriding the layout and manage Twig file in your readme, but I think this can easily be done by using Symfony's default Bundle inheritance.

Copying layout.html.twig to app/Resources/DmishhSettingsBundle/views will allow users to override it without having to define it in the config. 👍

There is a very deep tree. A typical setting config looks like this:

dmishh_settings:
    settings:
        my_first_setting:
            scope: user
            validation:
                type: number # any Symfony2 form type
                options: # options passed to form
                    required: false
                    attr: { class: 'my-class' }
                    constraints: # To make sure the data looks like you expect
                        Symfony\Component\Validator\Constraints\Range:
                            min: 1
                            max: 65535

I suggest to make it a bit more flat. Maybe something like:

dmishh_settings:
    settings:
        my_first_setting:
            scope: user
            type: number # any Symfony2 form type
            options: # options passed to form
                required: false
                attr: { class: 'my-class' }
            constraints: # To make sure the data looks like you expect
                Symfony\Component\Validator\Constraints\Range:
                    min: 1
                    max: 65535

I've moved the type and constraints up one level and removed the validation. How do you feel about this change? Should I make a PR?

We should rewrite the WrongScopeException to something more descriptive. Ie there are two reasons for the WrongScopeException to be thrown.

1. You have misconfigured the scope
2. You have called the SettingsManager::get with the wrong amount of parameters. Either you forgot the $owner on Local scope or you used $owner on a Global scope.

Today I installed this bundle in my SF 5.1 project and encountered the following issues:

Routing not working properly

Changed:

# Dmishh\SettingsBundle\Resources\config\routing.yml
dmishh_settings_manage_global:
    path:         /global
    defaults:     { _controller: DmishhSettingsBundle:Settings:manageGlobal }

dmishh_settings_manage_own:
    path:         /personal
    defaults:     { _controller: DmishhSettingsBundle:Settings:manageOwn }

into:

# Dmishh\SettingsBundle\Resources\config\routing.yml
dmishh_settings_manage_global:
    path:         /global
    defaults:
        _controller: Dmishh\SettingsBundle\Controller\SettingsController::manageGlobalAction

dmishh_settings_manage_own:
    path:         /personal
    defaults:
        _controller: Dmishh\SettingsBundle\Controller\SettingsController::manageOwnAction

Autowiring not working properly

Changed:

# Dmishh\SettingsBundle\Resources\config\services.yml
    Dmishh\SettingsBundle\Controller\SettingsController:
        arguments:
            - '@translator'
            - '@Dmishh\SettingsBundle\Manager\SettingsManagerInterface'
            - ~ # template
            - ~ # manage own settings
            - ~ # security role

Into:

# Dmishh\SettingsBundle\Resources\config\services.yml
    Dmishh\SettingsBundle\Controller\SettingsController:
        public: true
        autowire: true
        tags: ['container.service_subscriber']
        arguments:
            - '@translator'
            - '@Dmishh\SettingsBundle\Manager\SettingsManagerInterface'
            - ~ # template
            - ~ # manage own settings
            - ~ # security role

Using deprecated templating paths

Changed:

// Dmishh\SettingsBundle\DependencyInjection/Configuration.php

//...
        $rootNode
            ->children()
                ->scalarNode('template')
                    ->defaultValue('DmishhSettingsBundle:Settings:manage.html.twig')
//...

Into:

// Dmishh\SettingsBundle\DependencyInjection/Configuration.php

// ...
        $rootNode
            ->children()
                ->scalarNode('template')
                    ->defaultValue('@DmishhSettings/Settings/manage.html.twig')
//...

If I have the time, I will open a PR.

Hey @dmishh

Could you re-authenticate with Packagist? See here under Github hook: https://packagist.org/about

New versions is not showing up :/

I've just begun using this bundle and I've come across a few code snippets in the documentation that are wrong or outdated when compared to the current master. Proposed fixes in the pull request #83:

Resources/doc/installation.md

master:

<?php

// in AppKernel::registerBundles()
$bundles = array(
    // ...
    new Dmishh\SettingsBundle\DmishhSettingsBundle(),
);

is missing the Bundle part of the namespace just before SettingsBundle.

Fixed:

<?php

// in AppKernel::registerBundles()
$bundles = array(
    // ...
    new Dmishh\Bundle\SettingsBundle\DmishhSettingsBundle(),
);

Resources/doc/advanced-configuration.md

master:

dmishh_settings:
    template: DmishhSettingsBundle:Settings:manage.html.twig
    cache_service: null
    cache_lifetime: 3600
    security:
         manage_global_settings_role: ROLE_USER
         users_can_manage_own_settings: true
    serialization: php # database serialization mechanism (php|json)
    settings:
        my_first_setting:
            type: number # any Symfony form type
            options: # options passed to form
                required: false
            constraints:
                Symfony\Component\Validator\Constraints\Range:
                    min: 1
                    max: 65535

The options and constraints sections of my_first_setting appear directly below it but they should go below a validation section. Also the constraints section must go under the options section.

Fixed:

dmishh_settings:
    template: DmishhSettingsBundle:Settings:manage.html.twig
    cache_service: null
    cache_lifetime: 3600
    security:
         manage_global_settings_role: ROLE_USER
         users_can_manage_own_settings: true
    serialization: php # database serialization mechanism (php|json)
    settings:
        my_first_setting:
            validation:
                type: number # any Symfony form type
                options: # options passed to form
                    required: false
                    constraints:
                        Symfony\Component\Validator\Constraints\Range:
                            min: 1
                            max: 65535

master:

dmishh_settings:
    settings:
        my_first_setting:
            type: text
            options:
                max_length: 15
            constraints:
                Symfony\Component\Validator\Constraints\Regex:
                    pattern: "/^\d+$/"

Fixed:

dmishh_settings:
    settings:
        my_first_setting:
            validation:
                type: text
                options:
                    max_length: 15
                    constraints:
                        Symfony\Component\Validator\Constraints\Regex:
                            pattern: "/^\d+$/"

Resources/doc/faq.md

master:

dmishh_settings:
    settings:
        my_first_setting:
            options:
                required: false

same error as Resources/doc/advanced-configuration.md

fixed:

dmishh_settings:
    settings:
        my_first_setting:
            validation:
                options:
                    required: false

I want to discuss planned features of this bundle. The PR (#54) from @juanolon got me thinking of this.

Currently we have 3 scopes. GLOBAL and USER where the latter requires you to provide an entity. We do also have ALL which is some kind of default for the USER scope. (One can discuss if the names are proper #23).

PR #54 introduce a granularity of the USER scope. I understand the need and I agree with it. He wants to make sure class A does not access settings of class B. (Both are naturally in the USER scope). This is a fix for #3.

I can see some possible solution for this. I don't know which one is better. .

Option 1) Making scopes dynamic. Lets use GLOBAL, ALL and DYNAMIC and then extend the SettingsOwnerInterface with a getScope function.

Option 2) Something more like #54 where we define a namespace and make sure the entity in the USER scope is an instance of that namespace.

Option 3) In the configuration specify what entities that are allowed to what sections of the configuration.

Option 4) ??? There must be something else

This bundle can't currently handle EntityType fields. It will always persist {}.

We need to add some basic testing for the controllers.

Ref: http://symfony.com/doc/current/book/testing.html#your-first-functional-test

Memcached, file system, etc

I have a use case where putting the choices for a setting in the configuration files is not naturel.
I have content stored in a database and users can select some items from this content and put it
in their preferences.

The form type class Dmishh\Bundle\SettingsBundle\Form\Type/SettingsType builds choices from the configuration and I think it does not allow to provide choices from another source.

By design the Symfont Form Component does not allow to change form options after it has been built.

Letting dev provide the choices from another source would add more flexibilite and allow building more complex settings.

What about doing it using Symfony Event dispatcher ?

How set default value in config ?

It would be great if this bundle will be configurable to choose serialization type - (un)?serialize, json_(en|de)code. To provide availability to read data from different systems.

I think the Symfony Serializer might be better than php's serialize().

Or in addition to, I guess.

I have found a weird problem when using alpha2, the database is storing duplicated settings.

With this configuration...

dmishh_settings:
    settings:
        test1: ~

...and this code in a Symfony command:

protected function execute(InputInterface $input, OutputInterface $output)
{
    $manager = $this->getContainer()->get('settings_manager');

    $manager->set('test1', 1);
    $manager->set('test1', 2);
    $manager->set('test1', 3);
}

Everything works fine, the "dmishh_settings" table stores a single row:

With this configuration...

dmishh_settings:
    settings:
        test1: ~
        test2: ~

...and this code in a Symfony command:

protected function execute(InputInterface $input, OutputInterface $output)
{
    $manager = $this->getContainer()->get('settings_manager');

    $manager->set('test1', 1);
    $manager->set('test1', 2);
    $manager->set('test1', 3);
    $manager->set('test2', true);
}

It inserts 5 rows in "dmishh_settings":

This is required to support sf 3.0.

Does this mean we need to specify the FQCN in the config?

dmishh_settings:
    settings:
        my_first_setting:
            type: 'Symfony\Component\Form\Extension\Core\Type\IntegerType'

We maybe should have a converter somehow for some standard types.

Hi guys,

I am trying to install this bundle in my project but when i create a new database and run doctrine:schema:create i get the following error:
There is no column with name 'ownerId' on table 'dmishh_settings'.
Any idea what could be causing this?

As the topic suggest, what should be returned on all? (A) All settings that the users have stored or (B) All settings that the user can store?

Scenario A:

$sm=$this->get('settings_manager');
$sm->all(); // array('all_scope_setting'=>null)
$sm->all($this->getUser()); // array()  /* difference */

$sm->set('all_scope_setting', 'value');
$sm->all(); // array('all_scope_setting'=>'value')
$sm->all($this->getUser()); // array() /* difference */

$sm->set('all_scope_setting', 'foobar', $this->getUser());
$sm->all(); // array('all_scope_setting'=>'value')
$sm->all($this->getUser()); // array('all_scope_setting'=>'foobar')

Scenario B:

$sm=$this->get('settings_manager');
$sm->all(); // array('all_scope_setting'=>null)
$sm->all($this->getUser()); // array('all_scope_setting'=>null)  /* difference */

$sm->set('all_scope_setting', 'value');
$sm->all(); // array('all_scope_setting'=>'value')
$sm->all($this->getUser()); // array('all_scope_setting'=>'value')  /* difference */

$sm->set('all_scope_setting', 'foobar', $this->getUser());
$sm->all(); // array('all_scope_setting'=>'value')
$sm->all($this->getUser()); // array('all_scope_setting'=>'foobar')

At the moment is A implemented. I suggest we should implement B instead because it make more sense. Especially with #15.

Currently we only allow TranslationInterface from Contracts. We should allow the same interface from the component too.

Symfony 3.4 is not using contracts.

The checker detected 1 security issues in package doctrine/orm installed in version 2.4.7.0 1) Security Misconfiguration Vulnerability in various Doctrine projects.

Posted from SensioLabsInsight

Hi,

I am getting the following error on Symfony 4.4:

The controller for URI "/settings/global" is not callable: Controller "Dmishh\SettingsBundle\Controller\SettingsController" cannot be fetched from the container because it is private. Did you forget to tag the service with "controller.service_arguments"?

This is solved by adding public: true to the service definition of SettingsController

https://travis-ci.org/dmishh/SettingsBundle/jobs/159238973

Here, the second param should pass the same entity most likely
https://github.com/dmishh/SettingsBundle/blame/1c7b58053ba732862e966fd15050d5bbba570e8e/Resources/doc/general-usage.md#L71

I have the idea that it might be usefull to have integration with api-platform.

The backend to edit Settings is great, especially because it just uses the Symfony form component in a proper way.

Some of my Settings require translation, that's why I'd like to know you opinion on integrating the TranslationFormBundle into your bundle. It will allow the SettingsBundle to introduce an optional config parameter:

dmishh_settings:
    settings:
        my_first_setting: 
            translatable: true

Can you maybe comment on the translation strategy to use? I'm using the KnpDoctrineExtension strategy in my application, which works great.

I am using this bundle in a project to define a global shipping_cost setting. Since an admin can set a "discounted" shipping cost to specific customers, the setting has ALL scope. This way I can do something like $settings->get('shipping_cost', $user) to retrieve either the specific (customer) shipping cost, or the global one.

The problem appears when an admin wants to remove the specific shipping cost from the customer. It does not get deleted from the database. Instead of that, it is set to the same value as the global one. This creates a problem when the global value changes.

Wouldn't it make sense to support 5.4 as the 2.8 -branch of framework-bundle
( https://github.com/symfony/framework-bundle/blob/2.8/composer.json ) supports >=5.3.9? As does Symfony 2.8. Doctrine 2.5 supports >5.4, so why require php 5.6, when some servers might still be on 5.4?

Hey,
nice bundle btw. i do have a question:
i would like to have different settings per user. On my project, we use different entities per user group. And each of them has different settings. The user entity already implements the SettingsOwnerInterface interface and getSettingIdentifier() returns different id's per user type. But all settings with scope "user" are being show to all users.

So my question is, did i miss something? or is this the current behaviour of the scope "user"? if so, does adding a new config namespace to the scope "user", and then filter the settings per entity class would be a good approach? something like this:

dmishh_settings:
    settings:
        guide:
            scope: user
            namespace: 'My\Bundle\Entity\Student'
            validation:
                type: choice
                options:
                    choices:
                        - opt1
                        - opt2
                    required: false
                    expanded: true
                    attr:
                        class:  'form-group checkbox'
                    placeholder: false

Hi,
Has anyone already started working on the changes to be made to be compatible with Symfony 6?
Thank you

When we build the new cached container, we get the following exception:

Catchable Fatal Error: Argument 2 passed to Dmishh\SettingsBundle\Manager\CachedSettingsManager::__construct() must be an instance of Psr\Cache\CacheItemPoolInterface, instance of Doctrine\Common\Cache\ApcCache given

The cache service we inject right now is defined via doctrine_cache:

dmishh_settings:
    cache_service: my_apc_cache
    cache_lifetime: 3600

doctrine_cache:
    providers:
        my_apc_cache:
            type: apc
            namespace: my_apc

See https://github.com/dmishh/SettingsBundle/blob/master/Resources/doc/advanced-configuration.md

@Nyholm The caching layer has changed, so can you also add some docs to UPGRADE.md about that?

Do you think we should make the Doctrine\Common\Cache that was supported before compatible with the new Psr\Cache\CacheItemPoolInterface that is used now? Or will Doctrine eventually also move to PSR? That would mean everybody has to require https://github.com/php-cache/adapter-bundle right?

We got some legacy code in SettingsType.php. We do no support sf 2.3 anymore.

Add ability to group settings into sections