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).

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.

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.

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

These functions are currently under active development (as of July/August 2016):

• The helpers
• Language/Localization features
• Caching
• Email
• 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.

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!