Category: releases

2021-12-07 by Lonnie Ezell

Filed under:

About a month ago, we released the initial version of the CodeIgniter Settings package, that allows you to manage configuration settings in your database with a fallback to the config files. It is a simple solution to a problem we all face.

Thanks to the hard work of MGatner, one of the core developers and an active package developer, I'm happy to announce a version 2 already.

Contextual Settings

The first version of the library was great for what it did, but it pretty much had a single purpose - your app configuration settings. Version 2 introduces Contextual Settings, that allow settings to be saved and grouped together. When given a context they do not need to fall back to a config file. This allows things like save settings on a user-by-user case for example.

An example... Say your App config includes the name of a theme to use to enhance your display. By default, your config file specifies App.theme = 'default'. When a user changes their theme, you do not want this to change the theme for all visitors to the site, so you need to provide the user as the context for the change:

$context = 'user:' . user_id();
service('setting')->set('App.theme', 'dark', $context);

Now when your filter is determining which theme to apply it can check for the current user as the context:

$context = 'user:' . user_id();
$theme = service('setting')->get('App.theme', $context);

// or using the helper
setting()->get('App.theme', $context);

Contexts are a cascading check, so if a context does not match a value it will fall back on general, i.e. service('setting')->get('App.theme'). Return value priority is as follows: "Setting with a context > Setting without context > Config value > null".

Drop a note on the forums to let us know what other uses you find for it.

2021-11-08 by Lonnie Ezell

Filed under:

One common frustration when creating websites for clients is how to deal with configuration? You want to get the site ready to go, with all the settings exactly as they should be. Ideally, you want this in version control so that it doesn't get lost.

And you can't forget about the clients. As the site gets more popular the clients will want to change settings, tweaking the site to perform as they need, and support possible new use cases. You don't want to have to update the site and deploy new configuration changes every time this happens. Or create a new migration to update settings in the database. I could continue, but I'm sure you all have your own versions of this story you could tell.

If only we could have the best of both worlds.

Hello Settings!

The CodeIgniter team is proud to announce the release of a new library to help you deal with just this situation. CodeIgniter Settings is a standalone package that can be added to existing applications or used in new projects.

This library provides a new helper method setting() that you can use in place of config() calls (with small modifications). It will first check the database to see if it can find a saved setting. If it doesn't find a match, it will fall back to the associated config file.

// Instead of
$foo = config('App')->foo;

// Use
$foo = setting('App.foo');

It's all described over at the GitHub repo.

It has been optimized to hit the database as little as possible when reading settings, it's most common task, so you won't see much impact at all on your app's performance.

We hope that you'll find it as useful as we do and will enjoy using it and maybe even contribute back to help make it better for all of us.