As the year comes to a close, it’s time to look back at the work that’s been done so far on the rewrite for CodeIgniter. Much of the work needed to get the core into a place where it’s more in the public eye has been done. That doesn’t mean that things won’t change, but it’s getting closer and more finalized every day.
So, what can you expect?
Simplicity has always been a hallmark of CodeIgniter in the past. It’s simple to pick up and get started with. It’s fairly simple to learn. And it doesn’t do a lot of magic in the background to make everything happen. That’s one of the things that has come more and more to the forefront while we’re developing this: a focus on simplicity.
Not just simple for the user, though we feel that we’re doing pretty good there, too. But a simplicity of the solutions chosen within the core framework itself. Config files are one example. They are simply classes. That means that there’s no extra loader needed for a configuration file, and that a configuration file can exist anywhere that the autoloader can find it. While we’ve used some modern practices like dependency injection, that has been kept simple, too. Initially, I had created a convention-based DI container that I was pretty proud of. Eventually, though, I decided it was too complex of a solution, when all that was needed was a single class with methods that return a class for you.
Simpler isn’t just code for us. Simpler code frequently executes faster. It’s also simpler to understand when you’re debugging your own code. And simpler for us to maintain.
CodeIgniter has always been known for being pretty speedy compared to some of the other well-known frameworks. Version 4 will continue that trend. Now that we have all of the required pieces in place that are loaded during a simple “Hello World” example, I had to see how we were comparing with CI3. I was pleasantly surprised.
My first, very informal, test was done by simply refreshing the page quite a few times on both versions and determining an average display time based on the number that it shows on the default home page. CI4 was showing an average of around 0.0086 seconds, while CI3 was averaging 0.0124. Now, this is on a 5-year old iMac, running Apache with XDebug off and no opcaching, and entirely too many applications open. Nothing here has been optimized for speed, so ignore the actual numbers. But that’s a pretty good speed difference there.
Next up was to determine how that translated to something more like a real-world use case. Tests were ran on the same computer, using Apache, with XDebug disabled and opcache turned on. I used Apache bench to slam the sites with 3 rounds of the following command, taking the average number:
ab -n 2000 -c 10 http://ci4.dev/
The results? CI4 gave around 2500 requests per second, while CI3 clocked about 2250 requests per second. That’s about a 10% improvement. On code that has had no optimization, yet, and that has a few portions where more files were needed to implement a more robust solution, like the Request and Response process. I’m thrilled by those results so far. Use that with Nginx and you’d see even better results.
Another thing that I’ve seen touted about CodeIgniter on the forums for years has been that it doesn’t force you do anything in one particular way. You’re free to use models (or not) as you see fit. Controllers can be thin or fat. The choices are yours. In many ways, I feel that the core we’ve come up with takes that even farther.
You can still work with models and controllers in much the same way that you’re used to, sticking them in the familiar directories. You’re encouraged, though, to use Namespaces. Certain parts of the framework do require it, like config files. Once you get in the habit of namespacing all of your classes, then the flexibility explodes. The application folder can be modified to whatever fits your need, or your application’s architecture. You can add directories for EntityModels, Repos, Interfaces, whatever you need.
You can split your code into modules by simply namespacing them and letting the autoloader know where to find that namespace. Simple classes make up most of your module’s parts (config files, controllers, models, and libraries), and non-class files, like helpers and views can be loaded from namespaced directories just like they were actually namespaced. In addition, routes can point to any class/method that the autoloader can find, whether it’s officially a controller or not.
I know, everyone says that, and we all try as hard as we can. And in many cases, the framework itself cannot make it secure, but it can provide you the tools to most easily secure it yourself, and make it as easy as possible to use. Some tools you’re already familiar with. CSRF protection is largely the same as what we currently have. It’s good, effective, and meets the OWASP recommendations. Other parts, like XSS protection have drastically changed.
First off, doing XSS protection well is hard work. The solution that CI has always had was a little brittle, and a gave a false sense of security that you could simply flip one config setting to TRUE and have your site protected. There’s too many variables to make that work. So we’ve broken the problem down into it’s component parts so that you can always know what you’re securing and what you’re not. There will be a little bit of a learning curve for many developers, but that’s a good thing in the long run for everyone. The more you know and understand about securing your applications, the better job you’ll do.
The first part is filtering the input. The Request class provides a simple integration with PHP’s
filter_var command and the methods to retrieve GET and POST variables, as well as SERVER, ENV, and COOKIE values. It’s not automatic, but it couldn’t be simpler. The filter_* commands built into PHP are very good, and they only get better over time with no effort on your part.
Content Security Policy
Finally, we make it easy to implement Content Security Policy which is probably the best defense available against XSS attacks. It basically forces you to whitelist URI’s for scripts, images, etc. Very powerful and most browsers have pretty good support for it today.
Before it’s all said and done, we’ll walk through OWASP’s Top Ten vulnerabilities and do what we can to provide tools to combat those situations.
It’s the Bonuses
Much of what is in the framework, when it’s done, will be familiar to you if you’re a old hand with CodeIgniter. Already, though, new features are making their way into the system.
When creating API’s it’s especially important to be able give the user agents content the way they want it. They might request the data preferably in JSON, but XML is fine if you don’t support JSON. They might request it in a certain language, or encoded a certain way. Your application's job is to be able to interpret those requests and match what you can provide up with what they are requesting and give them the best match. This is known as Content Negotiation and is now almost as simple as
$lang = $negotiate->language().
Quite often, our application’s need to interact with other servers, usually through cURL. Often, though, we need to pull in a third-party library like Guzzle to handle authentication, etc. This will be made easier in many cases with CodeIgniter’s new CURLRequest class, which is a lightweight HTTP client. We know that it won’t meet every need you’ll have, so the syntax has been kept as close as possible to Guzzle’s so that if you find you need asynch calls, or some other advanced features, you won’t need to modify what you’ve already written much to get it working.
CodeIgniter has never required the command line to work. However, there are times when having scripts in our apps that did work on the CLI would be a great thing. That might be part of an installation script, or maybe a CRON job. You could even build tools that allow you to interact with your site through SSH, even when the site is down for maintenance. The framework now makes it easy to create cli-only routes, and provides tools for interacting with the user on the CLI by asking them questions, displaying colored output, and more.
Wrap It Up, Already!
We’ve been hard at work these past 3 months or so creating a system that helps you out when you need it, and stays out of the way when you don’t. We’ve tried to balance the changes that the system needs to bring it into the modern era and thrive for years to come, with the feel and features that have made CodeIgniter popular. We think you’re going to love it and can’t wait for you to get your hands on it.
When Can You Get It?
Of course, at this point you’ll be wondering when you can get it. As always, the only answer we can give is, “When it’s ready”. There are two main portions remaining to be implemented, including one beast: the database layer. Then we’ll need to increase our unit tests, write some better and more accurate docs than we currently have, and put it through it’s paces a little bit. So, we’re close to having Phase 1 done, but we’re not there, yet.
We are excited, though, and hope that you are, too.