CodeIgniter 4 – What will change?
As already mentioned in the last post about CodeIgniter, the framework which was originally developed by EllisLab, was adopted by the BCIT (British Columbia Institute of Technology).
Just a few weeks after this acquisition, the new improved version 3.x of this framework was released.
Although the framework had now a relative solid base, it still lagged in parts strongly when comparing with the frameworks of its competitors.
So CodeIgniter had, compared to Laravel, fewer chances to score with developers, because the competitor frameworks’ functionality and coding style were always a bit better.
However with version 4 of CodeIgniter the tide could turn!
The big move
In the official CodeIgniter forum, it was already announced on 26/06/2016, that the first milestone of CI4 has now been achieved. At this time the repository was also transferred on GitHub: https://github.com/bcit-ci/CodeIgniter4
A documentation can be found here. But please be aware that these is not finished yet, and therefore it’s still in partls rather sketchy.
The most striking and obvious change to the previous versions is the fact, that there is now a public directory.
Like in other frameworks this has an essential and security-related background: the separation of application/framework and public resources (as like Javascript, CSS or images).
Due to the fact, that the framework will be revealed not so freely, it is much more difficult for potential attackers to find vulnerabilities or deliberately exploits.
The only neccessary modification on the server-side is a little change in the vhost configuration (if available or possible). The document root will no longer be placed in the root directory of CodeIgniter, but now in the public folder.
Such a vhost configuraton could now look like this:
<VirtualHost *:80> ServerName codeigniter4.local DocumentRoot /var/www/vhosts/codeigniter4.local/public/ </VirtualHost>
The most significant changes
It is quite obvious that the minimum requirement for the PHP interpreter was set relatively high. So for the installation and operation PHP >7.0 is required.
A brief view to the folder structure of the framework remembers at a first glance quite strong to Zend 1 or Laravel.
CI4 is now (such as already known e.g. from Laravel) ready for database migrations and seeds. So the deployment itself and also deploying changes is now much easier, because database adjustments must no longer be done manually. Now this happens automatically. Optional seeders are then subsequently filling the database with dummy data.
The configuration of the environment (in which the framework is running, and also the related configurations can be set) can now be done via DotENV (.env).
For comparison: CI2 offered only the possibility for a single environment, CI3 however for three (development, testing, production).
Installation
CodeIgniter now relies after its rewrite with version 4 to the (already many familiar) PSR-4 autoloading in combination with Composer.
For all those who don’t know what Composer is: this is a command line based package management system especially for PHP, by which always the latest vendor packages will be installed, and also their versions can be centrally managed and updated.
The current development version of the CI4 framework mainly uses packages from Zend framework and Symfony framework.
After copying all files from GitHub to the appropriate directory on the server, Composer has to be set up initially.
For this purpose, a new terminal (or command promt / CMD on Windows systems) has to be opened. Then navigate to the root directory of CodeIgniter.
If Composer is installed on the relevant system, it can now be initialized for the new project via composer setup .
When you now open the vhosts’ URL in browser, you can see the welcome-screen of CI4.
If you have a look at the “public” folder you will find already a .htaccess file, which already contains a basic configuration.
Furthermore, there is also a robots.txt, which currently blocks all crawling bots. The robots.txt is a text file with information for crawlers of search engines – e.g. which pages should be indexed, and which not.
Configuration
The basic configuration, which was located up to CI3 under /application/config.php, has now moved to /application/Config/App.php (note the uppercase and lowercase letters in the paths and filenames!)
The configuration is now no longer just a simple array. It has turned to an independent class (with inheritance and namespaces):
<?php namespace Config;
use CodeIgniter\Config\BaseConfig;
class App extends BaseConfig
{
/*
|--------------------------------------------------------------------------
| Base Site URL
|--------------------------------------------------------------------------
|
| URL to your CodeIgniter root. Typically this will be your base URL,
| WITH a trailing slash:
|
| http://example.com/
|
| If this is not set then CodeIgniter will try guess the protocol, domain
| and path to your installation. However, you should always configure this
| explicitly and never rely on auto-guessing, especially in production
| environments.
|
*/
public $baseURL = '';
/*
|--------------------------------------------------------------------------
| Index File
|--------------------------------------------------------------------------
|
| Typically this will be your index.php file, unless you've renamed it to
| something else. If you are using mod_rewrite to remove the page set this
| variable so that it is blank.
|
*/
public $indexPage = 'index.php';
...
For smooth operation of CI4 it’s necessary, that the base URL is configured here once. This was chosen deliberately for security reasons.
public $baseURL = ‘http://codeigniter4.local/’;
The optional configuration of the database is defined in the Database.php file. It should be noted here that there are two configurations available: one for the application itself and a second for testing purposes (as like with PHPUnit).
These parameters can also be configured via DotEnv (.env). For this purpose, those parameters can also be defined in the .env file in the frameworks’ root directory.
database.default.username = 'root'; database.default.password = 'passw0rd!'; database.default.database = 'codeigniter4';
Coding examples will follow once the version 4 of the framework has become reasonably stable. Currently there are still some bugs, by which, inter alia, the migrations are not working properly.
Roadmap
Here’s a brief listing of the already implemented and still planned functions. These are taken from the updated user guide.
Milestone 1
In the first milestone, these functions have been implemented or completely rewritten:
- Autoloader (PSR-4)
- Logging
- Exception Handling
- HTTP Request/Response
- Routing
- Controllers
- Models
- Database (MySQL & Postgres)
- Config
- Security
- Views
- Sessions
- Basic debugging and profiling
Milestone 2
These functions are currently under active development (as of July/August 2016):
- The helpers
- Language/Localization features
- Caching
- Encryption
- Form Validation
- Image Library
- Pagination
- Uploader
It’s quite possible that there will be after the completion of this milestone already a first stable version or at least a release candidate (RC) available.
The planned completion of this milestone is in December 2016.
Milestone 3
This milestone represents on the current state only enhancements and new functions, which (theoretically) could be supplied also in form of updates.
- FTP
- XML-RPC
- Zip
- Typography
- Template Parser
Conclusion
A view of the current state of development of CodeIgniter 4 makes at a first glance a more than positive impression. Since this version of the framework already requires PHP 7 as a minimum requirement, it is on the cutting edge of technology. However, at this time, many internet providers and shared hosting providers still are not supporting the latest PHP versions, and therefore many of them aren’t able to offer PHP in version 7.
In my opinion, the BCIT with their CI4 has a good chance to establish itself adequately, because now also almost all ailments of the previous versions are solved, and the software was completely written from scratch.
Since the framework is still in the development phase, it should not be used in production environments!
And finally still good news to all the followers of the 3.x version: the BCIT is already planning a new update: v3.1.0 – this will be also the last update for the 3.x series.
For existing 3.x projects there should be a possibility to upgrade to version 4 (but this wasn’t officially confirmed by the BCIT yet).
So we can stay curious to see what’s coming in future times!