Hi, Nice Extension to CI 4. Unfortunately, when i installed with composer, the composer ran but nothing got installed. I checked the Migration folder and nothing was there.

Did i do something wrong or do i have to do somethings manually?

Every time I think about adding new handlers I run into the same logical issue: how to deal with multiple handlers that need to write a state. I would like to hear a bit more of the logic behind the single-handler approach, in case I am missing something; then maybe consider expanding it to support any registered handler.

This PR expands the core function to add a new feature: contexts. A "contextual setting" is a way of defining a setting for a specific subset of circumstances, left to the developer to define (see https://github.com/codeigniter4/settings/pull/15#issuecomment-968101752). Contextual settings fall back on their "global" version (i.e. the current behavior), providing one more layer of customizability. An example of a contextual setting might be environment-specific URLs:

service('Settings')->set('App.homepage', '/welcome', 'environment:production');
service('Settings')->set('App.homepage', '/debug', 'environment:development');

In order to facilitate detection of "hits" versus "misses" this PR also adds the has() method to handlers to determine whether a value is present or not. This expands on null value support, since we can now differentiate between "nonexistent" and "present but null".

Note: Because this feature modifies an abstract method definition it will require a major release.

A nod towards DI and to ease extending the actual class, this PR adds a parameter for the Config file to be used to make handler definition easier. I think ideally this parameter would be required and the service would handle the config fallback, but that BC will have to wait for version 2.

There should be some meaningful way to specify handler priority, aside from "whichever comes first in Settings Config". Probably the way to do this is add a priority field to the handler arrays - this way if a module uses a Registrar to tack on a handler it can make it the "preferred" version.

Addendum: it might be good to allow some way of specifying a handler(s) to use for a single call.

Your latest commit points out a problem in the current flow: settings with null values. I think this will be a frequent enough need with Config handling that it will merit handling explicitly (maybe types will help?). Handlers should be able to:

• Handle a set() request to store an overriding null value
• Differentiate "no handler value" that should percolate from an actual null value response from get() requests that should stop

The service and helper will need updating to accommodate these parameters.

Hello, I'm trying to implement new settings library into my project. Everything is going fine, but I would like to have an option for the user to change his theme of app based on the logged in user ID. I am using myth-auth so is no problem to get actually logged in user. I tried to use user_id() as a $context so if is logged in user with ID for example 1 than he can go to settings and change via the form theme of the app.

Here is the form-select:

<div class="mb-3">
    <label class="form-label" for="theme"><?= lang('Settings.theme') ?></label>
    <div class="col">
        <select name="theme" class="form-select <?php if (session('errors.theme')) : ?>is-invalid<?php endif ?>">
            <?php
            foreach ([1 => lang('Settings.themes.light'), 2 => lang('Settings.themes.dark')] as $k => $v) {
                if ($k === set_value('theme', (int) setting()->get('App.theme', user_id()))){
                    echo '<option value="'.$k.'" selected>'.$v.'</option>';
                } else {
                    echo '<option value="'.$k.'">'.$v.'</option>';
                }
            }
            ?>
        </select>
    </div>
</div>

This show to user by default theme-light what is ok. Now he want to change theme to theme-dark so he will choose theme-dark and submit the form. Form is going to the controller method:

    public function attemptUpdate()
    {
        // Validate basics first since some password rules rely on these fields
        $rules = [
            'theme' => 'required',
        ];

        if (! $this->validate($rules)) {
            return redirect()
                ->back()
                ->with('errors', $this->validator->getErrors());
        }

        // Update settings of the user logged in
        setting()->set('App.theme', $this->request->getPost('theme'), user_id());

        // Success!
        return redirect()
            ->route('settings')
            ->with('message', lang('Settings.updateSuccess'));
    }

and create settings row in the table settings like:

1	Config\App	theme	2	string	1	2021-11-20 08:07:47	2021-11-20 08:07:47

as far so good. When another user log in and try to change his settings of theme another row will be created what is ok:

2	Config\App	theme	2	string	5	2021-11-20 08:07:47	2021-11-20 08:07:47

but for example he want to change his settings back to ligh-theme and all rows in the table are changed like:

1	Config\App	theme	1	string	5	2021-11-20 08:07:26	2021-11-20 08:09:32
2	Config\App	theme	1	string	5	2021-11-20 08:07:47	2021-11-20 08:09:32

and setttings of the user with ID 1 are lost.

Note that boolean true/false will be converted to strings :true and :false when stored in the database, but will be converted back into a boolean when retrieved. Arrays and objects are serialized when saved, and unserialized when retrieved.

One of the most recent additions to Tatter\Settings was type casting - storing the actual setting type in the database so the Library can cast it upon retrieval. I would love to see something like that added here, even if it was "optional" (or auto-detect during set()).

Is there multi-language support? For example, it would be better to add an extra new column and have multi-language support for example "local".

Could you please give me a hint how to use Settings to store values from Config/App.php? For example we have $defaultLocale = 'en' defined in the file, but in the database I have settings(id, class, key, value, created_at, updated_at) VALUES ('1', 'Config/App', 'defaultLocale', 'en', '2022-04-15 08:39:25', '2022-04-15 06:42:47'.

Should the values from the database automatically override the value from Config/App.php? Do I need to somehow manipulate the framework to use the values from the database for $dafaultLocale?

I ask because overriding the value from the database does not change the language in the framework (manually changing it in Config/App.php obviously works fine).

First off, thanks for this! Currently using it in my project :)

As I wanted to migrate the settings table programmatically, I had to input this package's namespace. So, it came as a surprise that CodeIgniter/Settings didn't work. I had to go through the package files to find out that the Sparks/Settings was to be used instead.

What is the reason for naming it Sparks/Settings? Shouldn't the namespace be CodeIgniter/Settings?

It is possible to get multiple values or an array as result? e.g. - see code Get all the settings from a specific key (App.theme) : setting()->get('App.theme','') Get all the settings form a specific context : setting()->get('','user1') Get all the settings from a specific class : setting()->get('Log')

        $br='<br/>';

        service('settings')->set('App.theme', 'dark', 'user1');
        service('settings')->set('App.theme', 'white', 'user2');
        service('settings')->set('App.theme', 'red', 'user3');
        echo setting()->get('App.theme', 'user1').$br;
        echo setting()->get('App.theme', 'user2').$br;
        echo setting()->get('App.theme', 'user3').$br;
        print_r(setting()->get('App.theme','*')).$br;
        print_r(setting()->get('*','user1')).$br;

        service('settings')->set('Log.location', 'site/log');
        service('settings')->set('Log.date', '20220102');
        service('settings')->set('Log.name', 'service');
        echo setting()->get('Log.location').$br;
        echo setting()->get('Log.date').$br;
        echo setting()->get('Log.name').$br;
        print_r (setting()->get('Log')).$br;

Sample database

-- Dumping structure for table ca70_assets.da_settings
CREATE TABLE IF NOT EXISTS `da_settings` (
  `class` varchar(255) COLLATE armscii8_bin DEFAULT NULL,
  `key` varchar(255) COLLATE armscii8_bin DEFAULT NULL,
  `type` varchar(31) COLLATE armscii8_bin DEFAULT NULL,
  `context` varchar(255) COLLATE armscii8_bin DEFAULT NULL,
  `value` text COLLATE armscii8_bin DEFAULT NULL,
  `created_at` datetime NOT NULL,
  `updated_at` datetime NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=armscii8 COLLATE=armscii8_bin;

-- Dumping data for table ca70_assets.da_settings: ~11 rows (approximately)
INSERT INTO `da_settings` (`class`, `key`, `type`, `context`, `value`, `created_at`, `updated_at`) VALUES
	('Config\\App', 'theme', 'string', 'user1', 'dark', '2023-01-02 16:10:06', '2023-01-02 16:14:10'),
	('Config\\App', 'theme', 'string', 'user2', 'white', '2023-01-02 16:10:06', '2023-01-02 16:14:10'),
	('Config\\App', 'theme', 'string', 'user3', 'red', '2023-01-02 16:10:06', '2023-01-02 16:14:10'),
	('Log', 'location', 'string', NULL, 'site/log', '2023-01-02 16:13:08', '2023-01-02 16:14:10'),
	('Log', 'date', 'string', NULL, '20220102', '2023-01-02 16:13:08', '2023-01-02 16:14:10'),
	('Log', 'name', 'string', NULL, 'service', '2023-01-02 16:13:08', '2023-01-02 16:14:10');

Performance-wise it would be a good idea to implement some bulk handling, so multiple settings can be retrieved with e.g. a single database call. For storage this might mean deferred writes, which shouldn't be too hard since we already use a local store.