CodeIgniter 4 — Getting to Know You

Disclaimer: I’m not a programmer by trade but I have developed and maintained a comprehensive reporting site for my company using CodeIgniter 3 over the past five years.

Since there’s no time like the present, let’s get CodeIgniter 4 installed and examine what we find in our filesystem. We’ll start by using Composer to install CI4 using the AppStarter method into our very descriptive and highly marketable project name: fred. I used the “ — no-dev” option so composer won’t install the development dependencies listed for CI4. We’ll define our own later, thankyouverymuch.

Pretty quick install, eh?

As you can see, CI4 depends on very little. It pulls in kint, a very useful debugging tool, and laminas-escaper, a library for helping escape content in the never-ending battle against XSS attacks, and finally, psr/log so you can attach any PSR-3 compliant logger. The laminas-zendframework-bridge is just a bit of shim needed to bridge the old Zend Framework code to the new Laminas project.

Don’t let this fool you into thinking the framework doesn’t have a lot to offer — it packs plenty of punch. You see, CodeIgniter isn’t about giving you everything plus the kitchen sink. That’s not its design or philosophy. It’s about giving you a small, fast framework that’s not opinionated and doesn’t get in your way by providing enough features and structure to give you the freedom to build greats apps.

So, what does it give you? Before we dig in to features and functions, let’s get familiar with what it deposits in your filesystem.

Definitely not a lot of cruft.

We’ll start with the files before moving on to the directories.

• “builds” is a PHP script for switching the installed CodeIgniter from a production release to a developer release. For these articles, I’m sticking with the production code, so I’ll be ignoring this file completely.
• “contributing.md” talks about how you can contribute back to CodeIgniter. We’d love to have you join us.
• “env” is an example environment configuration file. It allows you to set most of the framework’s configurables in a familiar .env fashion. Just don’t commit credentials to your repo, okay.
• The “LICENSE” and “license.txt” are the same license (MIT) just with different Copyright notices.
• “phpunit.xml.dist” is a starting point for configuring PHPUnit testing.
• “README.md” is, well, the readme file.

The last file, “spark,” deserves special mention. It’s a script that simplifies working with CodeIgniter apps from the command line. It can show you all the configured routes, check namespaces, run database seeds and migration scripts, and more. Lastly, it can launch the development server using the hostname, port, or even specific PHP binary of your choosing. We’ll do that after we talk about the directories.

I’ll go in reverse order with the directories.

• “writable” is where CodeIgniter writes file-based session data, file and database cache, logs, and an “uploads” directory for user content. It’s the only directory that needs to be writable by the user your web server runs as. This helps you to lock down permissions on your filesystem as part of a larger security strategy.
• “vendor” is where all your Composer-managed libraries will be installed, if you are using Composer (you are, right?)
• “tests” are for PHPUnit tests. CI4 comes with some tests to help get you started. Check out the README.md file in the directory for more info.
• The “public” directory is what you would set your site’s document root to. Again, as part of your security strategy, all of your app’s code should be outside the document root. You can put static content (images, CSS, Javascript, etc.) inside the public directory.

Finally, the “app” directory is where your application code will live. Let’s take a quick peek in there.

You’ll spend 99% of your time here, so get comfy.

CodeIgniter is a MVC framework with directories for your models, views and controllers, conveniently named “Models,” “Views,” and “Controllers.” The “Config” directory contains a fair number of configuration files and three you’ll want to customize first are going to be “App.php,” “Autoload.php,” and “Database.php.” They have lots of helpful comments to explain what each setting is to guide you along. Other directories you may find helpful to utilize:

• “Database” is for holding seed and migration scripts for your database(s), should you choose to use them.
• “Filters” are for classes that can run before or after Controllers.
• “Helpers” is for small functions that are probably too simplistic for a full-fledged class.
• “Language” is for holding language strings for internationalizing your app.
• “Libraries” would be for code that can be used by models, views and controllers — in particular, code that may not fit into one of the other categories, have its own namespace or be managed by Composer.
• “ThirdParty” is where code from 3rd parties can be located if it can’t be managed by Composer.

Remember that “spark” script I mentioned earlier? Let’s do something with it.

Like using “php -S” but with more bells and whistles.

In this example, we are launching the built-in development server. We can use the “-host”, “-port”, and “-php” options to define the specific host and port for the server it listen on as well as a specific PHP binary (if you have multiple installed.)

This isn’t the only thing the “spark” script can do. Its purpose is to execute commands within CodeIgniter, meaning that it bootstraps the framework, then loads the appropriate Command controller, and runs the run() method. This is very useful because you can write your own commands, giving you access to the full power of the framework. This comes in particularly handy when you have to do things like:

• Runs jobs via cron to create reports
• Roll-up data in a database
• Purge soft deletes
• <your idea here>

Well, that’s it for this article. Now that you’ve seen the files and directories, our next article will start delving into the features of the framework.