Thanks to the team and many contributors, we released v4.3.0 with lots of enhancements.

Unfortunately, there are some breaking changes, so please upgrade with caution. Please read the ChangeLog and the Upgrading Guide carefully.

You must update the spark executable and a few Config files.

Most existing apps will not need more intervention, unless you use your own classes that extend framework classes.

And some of the default Config values in the Config files have changed, but existing apps will most likely not break unless you change the Config values by yourself.

This release contains over 50 enhancements. A few things I want to highlight:

• Query Builder supports upsert() and upsertBatch(), deleteBatch(), and now *batch() methods can set data from a query
• Database Forge supports adding indexes in the existing tables and named indexes
• "spark route" command enhancements
• Improvement for CLI command testing
• View Cells enhancements

You can see the list of enhancements in the ChangeLog

• ChangeLog: https://www.codeigniter.com/user_guide/changelogs/v4.3.0.html
• Upgrading Guide: https://www.codeigniter.com/user_guide/installation/upgrade_430.html

View forum announcement

Very pleased to announce the next much-needed release of the framework: version 4.2.0! This brings a ton of updates and new features, which you should definitely go read about right now

A few things I want to highlight:

• The minimum PHP version has been increased to 7.4. Composer should ignore this version for 7.3 environments, but be careful not to do a manual update if you haven't migrated yet!
• There are a number of breaking changes that you should review for relevancy to your projects, but this one applies to everybody:

The CodeIgniter\CodeIgniter class has a new property $context and it must have the correct context at runtime. So the following files have been changed: public/index.php, spark

• (You must update those files for your project to work; read the release notes for more details!)
• Lots of enhancements but two new component classes to highlight, first the "Improved Auto Routing" (opt-in) brings a more secure alternative to the traditional way of mapping URLs to routes
• ... and the long-awaited OCI8 driver for Oracle databases, supporting SQL and PL/SQL statements
• And, just because it amounts to so much: hundreds of bugs fixed and small improvements (three months worth)

With this release we hope to be back on a regular monthly-ish release cycle for bugfix patches. Planned for the next minor release will be the refactored version of the Email class, and more.

While I have you, be sure to check out our updated list of official packages that has been growing quietly.

This includes the just-released Shield for authentication and authorization.

As always a GIANT shoutout to the team who has volunteered countless hours of code contributions and numerous more behind-the-scenes conversations and planning to make this happen.

And always, thanks to all the contributors and supporters (that's YOU!) from the community! Code on.

View forum announcement

One of the most requested features in CodeIgniter for years has been an authentication/authorization solution. I'm proud to announce that today is that day. CodeIgniter now has an official auth library: Shield.

Among the many features that Shield ships with are:

• Session-based authentication (traditional email/password with remember me)
• Stateless authentication using Personal Access Tokens
• Optional Email verification on account registration
• Optional Email-based Two Factor Authentication after login
• Magic Login Links when a user forgets their password
• Flexible groups-based access control (think roles, but more flexible)
• Users can be granted additional permissions
• User Entity and UserModel ready for you to use or extend
• A simple helper that provides access to the most common auth actions
• Easily extendable controllers
• All required views that can be used as is or swapped out for your own
• Highly configurable
• Built to extend and modify
• Save initial settings in your code so it can be in version control, but can also be updated in the database, thanks to our Settings library

While this is a beta release, it already provides a fairly thorough set of features, that should handle the needs of 80% of the projects your work on. We hope you find it helpful, and we're looking forward to see it continue to help you build secure applications in the future.

View forum announcement

CodeIgniter 3.1.13 was released today.

This includes a fix for a bug in the Session library that broke for PHP 5 due to a misnamed polyfill interface. It fixes a possible session fixation vulnerability where session.use_strict_mode wasn’t enforced on PHP 7+, as well as several other important changes.

See the change log for full details.

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.

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.

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.