CodeIgniter 4 Announces Development Roadmap

After taking into account the wishes and opinions of the community, we also think about what kind of future is most appropriate for CI, and then the CI Council makes some decisions about the future of the framework. In the future there will be significant changes, but we believe they will not only prepare for our future, but also maintain the codeigniter characteristics of simplicity, speed and flexibility.

This article is a brief overview of the future. Keep in mind that this is only the original plan. Any information may change as the development progresses.

Core changes

Great changes have taken place in the PHP community since the release of the first version of CodeIgniter. Many of CodeIgniter's core elements were necessary at the time, but when PHP5 was released, there was little change in the core of CodeIgniter. If the future CodeIgniter wants to maintain a high standard and consolidate its position in the PHP framework, it must make a big change.

This means that the system must be completely rewritten. The new CI will be developed in a separate code base to keep the code clear. We envision reusing some of the previous code, but the focus is on modern , clear code.

Since we've targeted php 7 , PHP 5.6 has entered security maintenance mode and will stop supporting it after a few months. CI will not release a new version for a PHP version that is about to stop supporting. We know that the host environment is very different, then some programs may not fully support PHP 7, so the 3.x branch will continue to maintain a period of time-will be much longer than 3.x post-release 2.x branch EOL time limit.

Both the application and the system directories will support PSR-4 automatic loading. CodeIgniter will use its own autoloader and will integrate the Composer.

We will encapsulate some components so that in most cases it can be used for projects other than CodeIgniter.

Package/Module

We will discard the concept of application packages and modules. Don't Panic! Because you can use namespaces to handle most situations-at least the controllers and models are like this. For other examples, such as views, profiles, and helpers, we believe we can allow these things to support namespaces. You can also put the functionality of all the packages and the routing capabilities of the modules into any directory, just tell the autoloader how to find them.

Routing

The routing feature will be updated. URI directly mapped to the controller/method This "Magic route" feature will be turned off so that you can choose your preferred route. In the routing configuration file you can choose to use magic route or specify each route individually.

Improved log system

The log system will be improved, but the specifics are not yet determined.

Test

We will continue to test with PHPUnit. This also means that you need to test your application yourself, but we will prepare the necessary tools for you.

Backwards compatibility

As mentioned above, this must be an incompatible version of the old version. We think this should be the best future for the framework. We have been doing the groundwork for many years on this major change, and we will make the transition as smooth as possible, but it remains to be seen how we can provide a modern base code.

We will do our best to keep the features that CodeIgniter have been popular for years, namely, fast, concise and "elegant".

Development timeline

The entire development process will be divided into three phases.

The following class libraries will be removed from the kernel to be downloaded on demand: Typesetting classes, FTP classes, ZIP classes, and XML-RPC classes.

Shopping cart classes, Javascript classes, Unit test classes, and Trackback classes will be deleted.

We expect to complete an Alpha version of the kernel's basic molding within one year. After that, we will focus on improving the kernel and developing the remaining packages. The exact timetable may be different because, as with most open source projects, it depends on the amount and quality of community contributions, as well as the time and effort of the core developer.

First Stage

The first phase will focus on capturing the most important parts of the framework. This will be the basis for other parts of the framework. They include:

• Auto Loader

• Dependency Injection

• Log

• Exception handling

• HTTP Request/Response layer (or input/output)

• Routing

• Controller

• Model

• Database tier

• Configuration

• Safety

Phase II

The second stage focuses on perfecting some of the classes and features that CodeIgniter users would like to have. They include:

• Helper

• Language/Internationalization Features

• Cache

• Email

• Encryption

• Form validation

• Image Processing Class Library

• Page out

• Upload class

• Session

• View

• Debugging and analysis tools

Phase III-Optional class library

The third phase will be used primarily to augment optional packages. At this point in time, the framework should be ready to be released, without having to wait until all class libraries are in place.

• Ftp

• Xml-rpc

• Zip

• Typesetting class

• Template Parser

The framework ushered in new opportunities and excited us, and we couldn't wait for the framework to take the first step towards the new version. Don't be on the sidelines, come and build the future of the frame.

Author: Lonnie Ezell (member of the CodeIgniter Council)

Translation: Hex

Originally published on August 5, 2015 , CI 4 is currently under development and has not yet been released

English Original: CodeIgniter 4 proposed roadmap

