Clearing out the cobwebs and dusting off the counters we found a brand new website for CodeIgniter.
This site has a huge history that I'm only partly aware of. Back before Jim's passing, Paul was working with a number of volunteers discussing the direction that a new site should take, determining goals, and generally trying to modernize the site and build the future of CodeIgniter's face. This group included some names I'm sure you will recognize from the forums: php_rocs, tsrules, marcogmonteiro, little-j, jreklund, insitefx, ignitedcms, damianturner, and demyr.
Shortly after Jim, the project lead, passed away Paul felt he needed to step down from his duties since a new job took him away from CodeIgniter into new directions. A lot of momentum was lost at that point, unfortunately, though I don't think through any fault of the website team. Demyr, Marco and Little-J had the basic HTML about finished. Lonnie started fresh repo for a new website with the hopes of creating a good example of how you might use CodeIgniter 4 to build a simple website. The HTML and design work was all from the previous team, though.
We meant to get this site launched earlier. Famous last words of most volunteer-driven teams, I'm sure. One good excuse was that we wanted deployment of both it and the user guides largely automated and on new hosting platforms so that it could all be moved at once. We're not quite there, but we are getting close. A small issue with an update of the previous version of the site gave us the kick in the pants we needed to release it anyway.
A huge thanks to the time these volunteers put in with general discussion, planning, design, and implementation. It is very much appreciated by the core team, and I'm sure by everyone else as well.
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.
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.