Love Fuel?    Donate

Roadmap

Where is the framework heading? What has the future in store for you? What are we working on, and who is working on what? What is the status and the quality of the code? How well tested is it?
Updated: realtime

Version 2 Repository status

Repository Build Coverage Quality HHVM Status
Agent Build status Code Coverage Code Quality HHVM status B
Alias Build status Code Coverage Code Quality HHVM status B
Auth Build status Code Coverage Code Quality HHVM status A
Common Build status Code Coverage Code Quality HHVM status B
Config Build status Code Coverage Code Quality HHVM status B
Database Build status Code Coverage Code Quality HHVM status B
Dependency Build status Code Coverage Code Quality HHVM status A
Display Build status Code Coverage Code Quality HHVM status B
Email Build status Code Coverage Code Quality HHVM status A
Event Build status Code Coverage Code Quality HHVM status See #7
Fieldset Build status Code Coverage Code Quality HHVM status B
Filesystem Build status Code Coverage Code Quality HHVM status B
Foundation Build status Code Coverage Code Quality HHVM status A
Migration Build status Code Coverage Code Quality Needs vfs A
Orm Build status Code Coverage Code Quality HHVM status A
Routing Build status Code Coverage Code Quality HHVM status B
Security Build status Code Coverage Code Quality HHVM status A
Session Build status Code Coverage Code Quality HHVM status A
Validation Build status Code Coverage Code Quality HHVM status B
Upload Build status Code Coverage Code Quality HHVM status B
Release status code information
A Alpha Development ongoing, API likely to change.
B Beta Development ongoing, API likely not to change.
R Ready Package ready for v2 alpha release, API will not change

Alpha packages are not recomended for use.
Beta packages can be used but the developer should expect changes.

 

Updated: 13-09-2014

Planned activities

Seperate concerns by splitting the core up into feature specific packages

The current framework core is a collection of classes supporting features that actually warrant a separate package. For example Event, the Query Builder, Session, etc. These classes need to be split off the core, to make the core more compact and manageble.

Frank de Jonge (FrenkyNet) and Harro Verton (WanWizard)
80%
2.0

Refactor Tasks and Migrations

Both currently do not follow the cascading file system, which means the autoloader can not load these classes. Loading is done hardcoded in oil, app classes can not use them unless they use the same code.

This has to be changed so the normal loading mechanisms are used and the classes can be called from app controllers too.

Harro Verton (WanWizard) and Steve West (uru)
25%
2.0

Refactor the Profiler

Current profiler is pretty static, monolithic, and from a layout point of view not very handy as it overlays your webpage. We will probably offer a basic profiler in the core offering just the information, and an add-on package that provides visualization.

Harro Verton (WanWizard)
 
2.0

Refactor Unzip

Refactor the current Unzip class into a driver based archive class, so other compression and package algorithms can be used.

Nobody appointed yet
 

Refactor "oil generate"

A lot of the functionality related to generation is still hardcoded in the different oil classes. To make this as flexible as possible, the code needs to be refactored so that all variable code is in templates and generation logic in tasks that can be replaced or augmented by the user.

Nobody appointed yet
 
2.0

Rewrite Form/Validation/Fieldset classes

The current trio is one tangled mess, which needs to be sorted out.

Steve West (uru)
95%
2.0

Admin package

The ability to generate an admin section for an application, much like the Django administration module.

Nobody appointed yet
 

 

Completed tasks

Replace current Query Builder

New and more flexible query builder classes, PDO driven, and with better support for different RDBMS engines.

Frank de Jonge (FrenkyNet)
 
2.0

New package based loader that does both file & classloads

Everything in Fuel should become a package (including app & core) and modules should be allowed in every package. PSR-0 will become the default but each package can be set to use its own autoloader logic. This will also unify fileloading & classloading as those shouldn't be seperated.

Along with this the concept of Modules in FuelPHP will be simplified and no longer be tied to the Application. Modules will be a way of structuring you code and its non class files will fully cascade into its package, the package files themselves taking precedence over the module files when conflicts arise.

Harro Verton (WanWizard)
 
2.0

Reimplement Fuel init logic separating Environment and App logic

The environmental settings should be static/singleton as they should be considered such (ignoring that fact is just foolish). All non environmental logic should go into an App class that is instantiated for the app to run and sets up your application and handles the necessary bootstrapping.

Harro Verton (WanWizard)
 
2.0

Implement inversion of control throughout the core

Statics will be used way less in 2.0 and dependencies will be build and managed by the dependency package.

All other core packages will contain service provider to provide functionality to the framework.

Frank de Jonge (FrenkyNet)
 
2.0

Decentralize config & language

Config values and language will no longer be in one huge container but instead they'll be put into config/lang objects that are linked to the class that uses them. With this should also come specific validations and rewrite rules for config settings to be set with each class - thus unifying the way config parsing happens throughout Fuel.

Harro Verton (WanWizard)
 
2.0

Make FuelPHP Composer compatible

The Fuel components, like core and all packages, will be based upon the Composer/Packagist structure to be installable through Composer. This should also add support for installing non-Fuel packages from Packagist. Fuel based packages are still required to return a loader object and must be loaded in order to be available. All non-Fuel packages with PSR-0 autoloader support can be made available by adding a single Fuel-Composer loader to the stack.

Frank de Jonge (FrenkyNet)
 
2.0

Refactor Pagination

Remove all application specific code from the current Pagination class, and replace it by callbacks and app templates.

Harro Verton (WanWizard)
 
1.4

Asset and Theme refactoring

The current Asset class required you to use groups, and options. The usage should be simplified by making the groups optional. The class will be converted into an instance based model which will allow for multiple Asset instances each with their own configuration.

The usability of the Theme class is going to be improved with support for widgets and widget chrome. It will use an Asset instance to access theme specific assets.

Harro Verton (WanWizard)
 
1.4

Refactor Sessions

Session drivers are too complicated, and too much information in the session cookie that should be stored server-side.

Harro Verton (WanWizard)
 
1.5

Replace Log by the Monolog library

The current Log class allows simple logging to files only, and only in a static way. It has to be replaced by the Monolog library, which allows for multiple handlers, message preprocessors and formatters, so you will have the flexibility to log to whatever you want.

Harro Verton (WanWizard)
 
1.5

Refactor Upload

The class has to be rewritten so that in creates an upload class instance per file uploaded, and every file uploaded can be treated individually, instead of the current "batch" mode.

Harro Verton (WanWizard)
 
1.6