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.
New and more flexible query builder classes, PDO driven, and with better support for different RDBMS engines.
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.
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.
All statics have been removed from the core and a DiC in combinations with setters is used to provide the context and loading mechanisms.
The old plan for this has been implemented in a separate Static package that offers a static interface to the pure OO Core: Replace multitons with a DiC. Keep the current interface using instance() & forge() but have those powered by a DiC behind the scenes. This means the front classes will lose almost all logic and none will instantiate itself anymore (much like Form/Form_Instance). All front classes extend the same basic class that handles them.
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.
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.
Refactor the current Unzip class into a driver based archive class, so other compression and package algorithms can be used.
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.
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, with Fuel 1.x autoloader included by default. 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. The concept of an "active module" will be removed.
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.
The current trio is one tangled mess, which needs to be sorted out.
Largely this is already true for the 1.x versions, which are in no way dependent on the ORM for anything. But for 2.0 this will be much more explicit with it being very clear how and when an ORM is being used as the backend or provider for a functionality. The ORM will be removed from the default 'package' and put into legacy mode (meaning we will make it 2.0 compatible, fix bugs but do no further development). Alternative solutions like Doctrine 2 will get as much support by offering connectors to Doctrine entities (or any other 3rd party ORM).
The way to do this will probably be to offer a Model interface that can be used in conjuction with any ORM and requires all the methods implemented that core drivers need to interact with the model.
The ability to generate an admin section for an application, much like the Django administration module.
Remove all application specific code from the current Pagination class, and replace it by callbacks and app templates.
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.
Session drivers are too complicated, and too much information in the session cookie that should be stored server-side.
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.
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 (Team Lead)
Subproject lead:
Depot development
Harro Verton has been programming for more than 30 years, when he got hold of a TRS80. He started his professional development career writing IBM mainframe assembler.
Via a short stint writing mainframe Cobol, he moved into writing in C, developing software to integrate the mainframe and PC world, mainly writing drivers for network operating systems like Novell Netware and Banyan Vines.
This caused a gradual carreer shift from programming into networking. WanWizard is now professionally active as infrastructure architect.
However, the programming virus has never left him. At the end of the last century he picked up programming again, and decided to go for the then upcomming language for the web, PHP. And he's been developing applications in PHP ever since.
Frank de Jonge — (Developer)
Subproject lead:
Query Builder, Email
After being the "Docs Guy" for a couple of months Frank joined the team of Core Developers in September 2011.
While having a background in design his main focus has been writing code ever since he laid his eyes on the web. Frank mainly develops sites for creative agencies. When he's not working or contributing to the framework, he works on tiny projects like Snipr.it.
Unfortunately, people move on. We would like to thank these former members of the team, without them FuelPHP wouldn't be what it is today.
Jelmer Schreuder — (Architect)
Subproject lead:
2.0 Architecture, 1.0 ORM & Auth
Jelmer was introduced to the internet early and build his very first website at age 12, years before his parents would give him internet privileges.
It would take another five years to start making some money, but ever since early 1999 he's been writing PHP. In 2006 he was introduced to CodeIgniter which became his framework of choice for the next couple of years. He developed a closed source CMS which he licences as SaaS, while at the same time contributing back parts of it to the community. In the middle of 2010 he was in search of a new framework, having tried writing his own and trying many others he settled on bugging Dan on IRC about Fuel.
Phil Sturgeon — (Developer)
Subproject lead:
Oil
Dan Horrigan — (Founder)
Subproject lead:
1.0 Core
Code Monkey Dan has been developing PHP since 2000. Over the past few years he has contributed to many open source projects such as CodeIgniter and PyroCMS.
He has released many libraries for CodeIgniter and for a brief stint, worked for EllisLab as a Support Specialist for MojoMotor and also helped fix bugs when they popped up.