Introducing FuelPHP

Posted: 2011-01-04
Category: FuelPHP

It's been in development for the last two months but the new PHP 5.3 framework FuelPHP is ready to see the light of day and we're just about to roll out the v1.0.0-beta1 we've just rolled out v1.0.0-beta1.

Now I know every developer and their dog has their own framework these days and it has become the new "entry script" like phpBB clones used to be, but being built by experienced framework "connoisseurs" FuelPHP is a good way towards breaking this stereotype.

Why does the world need a new PHP framework?

I'm a CodeIgniter fan and I have been for a long time. It is a brilliant, lightweight, configuration based framework which is fairly extend-able and doesn't force users to learn much to get going. It has great documentation and a brilliant community. The downside? It was created for PHP 4 and things like $this->load will always be a core part. CodeIgniter Reactor will help us make CodeIgniter better, but it will always be of a certain pattern. For most that is fine, we're just making something with sexy new PHP 5.3 syntax.

Like CodeIgniter, FuelPHP will be keeping things simple but moving to a better PHP 5 syntax. Sounds like Kohana right? Well... kinda. Kohana got a lot of things right in 2.x but the 3.x re-write was a confusing one. Lots of their syntax and libraries are confusing and although incredibly well written they are poorly documented.. Kohana generally leaves people feeling confused unless they are ready to dive into the source and work it out for themselves. For many that is fine, we are just trying to make things easier.

Others are too simple, too complicated, badly documented, poorly thought out or just slow as hell.

So it's a fork?

Nope! CodeIgniter and Kohana are the two main frameworks FuelPHP is based around but all of the base code is original with only some small parts sourced from other places. We have taken a few ideas from Rails for parts like code generation but this will not be a huge complicated convention-based framework. The idea is if we can improve on CodeIgniter and Kohana a little then we already have a player in the world of frameworks.

Who else is working on this?

This is not just me, I'm not even in charge of the project. This project belong to Dan Horrigan who started things rolling, then invited me in soon to be followed by Jelmer Schreuder and Harro "WanWizard" Verton. Unlike other frameworks this is very community driven and we've already had contributions in planning, code and documentation from plenty of people. The FuelPHP way will be to always give feedback on pull requests with constructive feedback. Nothing will be ignored.

What features should I be excited about?

Cascading File System

We've borrowed the Cascading File System from Kohana and improved it greatly. The use of namespaces help to keep Core classes, App classes and Package classes from conflicting and we have added some path definitions to the auto-load logic to drastically speed up the Fuel Directory Structurecalling of classes.

The Cascading File System is a hierarchy of similar directory structures that cascade. The heirarchy in used when a file is loaded by Fuel::find_file() and checks core, packages / modules, application. At a very basic level this means you can have default config in the core and your own config in the application but it opens up awesome new options for things like default base controllers.

By default you have a Controller_Rest and Controller_Template which any controller can extend instead of the usual "Controller" to get extra logic.

The way autoloader works means each _ translates to being a / in the filepath. This means your controllers can do crazy stuff like:

Controller_API_Users extends Controller_API = app/classes/controller/api/users.php

Controller_API extends Controller_Rest = app/classes/controller/api.php

Controller_Rest extends Controller= core/classes/controller/rest.php

Madness? It might look it at first, but this is incredibly useful when you understand the use of base controllers and it all works out of the box. No hacking around like in CodeIgniter.

HMVC

The whole system has been written to work with HMVC so you can make requests to other controllers and module controllers within your own controllers meaning you can do things like:

Request::factory('errors/twitter')->execute()

Packages

Not like the new packages feature in CodeIgniter, packages are installable module-like directories that store classes and are added to the cascading file system. By default you are provided with two packages, ActiveRecord and Oil. Oil is a slick command line utility that (amongst many other things) can be used to install other packages.

	php oil install test-package
Downloading package: http://github.com/philsturgeon/fuel-test-package/zipball/master
Installing package "test-package"
	/Users/phil/Sites/fuel/fuel/packages/test-package/LICENSE.txt
	/Users/phil/Sites/fuel/fuel/packages/test-package/README
	/Users/phil/Sites/fuel/fuel/packages/test-package/classes/test.php
	/Users/phil/Sites/fuel/fuel/packages/test-package/classes/exception.php

More on this kick-ass command line tool later.

Lightweight ActiveRecord

FuelPHP contains a very simple, lightweight and powerful ActiveRecord/ORM implementation based on the old but rather tastey ActiveRecord-in-PHP.

$slug = Model_Slug::find('first'); # SQL query to grab first slug
$slug->post; # an SQL query occurs behind the scenes to find the slug’s post

$p = Model_Post::find('first', array('include' => 'slug')); # SQL join
$p->slug; # no SQL query here because we already got this post’s slug in the SQL join in the previous line

$p = Model_Post::find('first');

$s = new Model_Slug(array('slug' => 'super-slug'));
$p->slug = $s; # assign a slug to this post

$p->slug->slug = 'foobar';
$p->save(); # cascading save (post and slug are saved)

Why do you have to add Model_ at the start? Because models are in the /classes/model/ folder just the same as controllers and any other classes.

Oil command line utiity

Oil is the name of the command line utility in Fuel. Unlike some other frameworks you do not, ever, have to use this. It is an optional utility that speeds up things like package installation, MVC code generation, runs tasks and various other things.

If you are not interested in using a command line utility with your application, do not run it. Nothing will ever be loaded and it will never slow your application down.

Fuel RobotsSo what can it do?

Run tasks which are similar to controllers but command line only. Controllers run on the command line too, but this is a more direct an "native" approach. Tasks are a neat way to create structured cron jobs that you don't want to be publicly accessable, or if you want to accept some basic input to your application over SSH. Why? Who knows, but you can!

One task included in the core you may well use a lot is Migrate.

$ php oil refine migrate --version=5

Guess what that does? Migrations rock.

You can create and run unit tests with php oil test testname, test your code interactively via the php oil console and talk to models, and plenty more will come soon.

Summary

We already have our documentation in place with not much left to go. I have a joke website amiafucktard.com up and running to test the Fuel codebase which covers HMVC, Models, ActiveRecord, Caching, Session, Cookies, Forms, Templating and plenty more. If you want to have a look at the code it's all freely available on GitHub and another example site is ScrapYrd.com by Dan Horrigan, which will also be available on GitHub soon.

It is still early says and you will most likely find bugs. Hell, it's not BETA yet but on the whole this framework is nearly there and it's pretty damn quick.

Download it, give it a try and let me, Dan and the team know what you think! Swing by the IRC channel #fuelphp to have a chat and if you find bugs you can put them on GitHub.

Note: Please do not take any of this article as me expressing any concern, issue or negative points about CodeIgniter. I still love the framework and use it every day. I am a man with many mistresses, hell I use Rails and still write in PHP. This is another new option, not a replacement. I'm not stopping working with CodeIgniter and am still contributing to CodeIgniter Reactor.

 

Comments

Gravatar
Johan André

2011-01-04

Awesome job!
I'll dig into it right away! :)

Gravatar
Ben Corlett

2011-01-04

"CodeIgniter and Konhana" lol

Gravatar
Michael Grech

2011-01-05

Sweet man, I've been eyeing on this project on Github.

Gravatar
Mahen23

2011-01-05

All this sounds great, but i have been reading this: http://codeigniter.com/forums/viewthread/177221/ and i have been asking what Framework is better for me? Most of the times, my websites does simple CRUD things. So i go with Reactor, CI 2.0 or FuelPHP?

Gravatar
Backslasher

2011-01-05

Needs more namespaces. Seriously, this is a PHP 5.3 framework, so what's with all those underscores in class names?

Gravatar

2011-01-05

Backslasher: We experimented with this but it was a mess and ultimately pointless. As I explained in the article the underscores are part of the autoloader and map through as _ = /. Throwing more namespaces at it would not change that.

Mahen23: When Reactor is rlease it will be pushed as the main project. It will become very rare for anyone to actually use CI 2.0 and Reactor will be the tool of choice. Fuel will be less stable that CodeIgniter for a while and will remain usable on PHP 5.1.x servers so for many reasons that may remain your choice.

Gravatar
John

2011-01-05

Looks very interesting. I will be comparing FuelPHP & CI Reactor to pick one for my next project. Any plans on doing any videos similar to the blog in 20 minutes from CI? I found that video very helpful as a introduction to the framework.

Gravatar

2011-01-05

I plan to do a series of screencasts for this yes, from basic to crazy.

Gravatar
Niklas

2011-01-05

Been following this on twitter for the last months. All excited now! Great work.

Gravatar
Abdullah Al Mamun

2011-01-05

"I plan to do a series of screencasts for this yes, from basic to crazy."
Hey Phil,
That would be awesome for the newbies to get started.
Will wait for it.

Gravatar
Dfb

2011-01-05

rbedrb

Gravatar
Chris Cornutt

2011-01-05

What, no mention of my pre-release tutorials? ;) Yeah, so they're a little out of date...so? :)

Gravatar
Steelaz

2011-01-05

Any plans to have native Auth package?

Gravatar
Malachi

2011-01-05

Hey,

Cheers for this updater post - my friend showed me FUEL a few months ago and it's come along so much - with CodeIgniter being the only PHP framework I've really properly used I'll be eager to try FUEL out.

Regards,

Malachi

Gravatar
Adam Leonard

2011-01-05

Looks to an interesting framework. I know you stated your reasoning behind the need for Model_ before the name of a model, but I'm still not a fan.

May be it's due to the fact that I've done Rails for a while, but being able to just do Post->find($id)->first. To me would be a better syntax. Why not make use of method chaining instead of throwing arrays at the methods?

Gravatar
Marcus

2011-01-05

i will definitely try it.

Gravatar
Irfan Suleman

2011-01-05

seems intresting, will dig in soon and all the best guys

Gravatar

2011-01-06

@Adam Leonard: I understand what you mean but you have to understand that Model_ is purely a semantic prefix that separates your models from other classes. You can put all of your models into the app/classes/ directory and call them via their model/class name, but then they would conflict with other classes!

Beyond the class name, your syntax would be impractical in a PHP world.

Post->find($id)->first

Firstly, you have to instantiate a object before you can method chain in this way. Secondly, with your syntax you would be calling all items with the record, then selecting $results[0] with the first() method. This would be ridiculous on a performance level.

You do not have to instantiate models at all, static methods work just as well.

$post = Model_Post::find(4);

is the same as

$posts = new Model_Post;
$post = $posts->find(4);

We give you options, you use them as you see fit.

Gravatar
Anil

2011-01-06

Hi Phil,

Good work keep it up :)

Are there any plans to introduce Springs MVC like Annotations.. it works really well in many situations.. and it helps in Rest Applications as well instead of adding _get,_post.. we can add @Get annotation..

Gravatar
Chris Cornutt

2011-01-06

@phil personally, I liked it how you had it just before with models just in the \Fuel\App\Model namespace. Then I could do simple things like \Fuel\App\Model\News::find('all'); I suppose that namespacing scheme had to be changed for other parts of the framework, though.

Gravatar

2011-01-06

We removed that as it massively overcomplicated internal code along with requiring extra code in all of your models. All this extra work provided nothing more than a slight syntax difference of Model\Post() instead of Model_Post().

It was nicer, but it had to be done. We experimented a lot with the use of namespaces and decided in the end that minimal implementations were best. We don't want to end up like some over namespaced frameworks: Framework\App\Controller\Request\Output\View::build('view'); xD

Gravatar

2011-01-06

Great, backslashes are being removed.

Gravatar
Shawn Mccool

2011-01-07

Hey, Phil.. I've hacked up CI2.0 and implemented Phamlp, Luke Baker's AR, Modular Extensions, and a few of my own libraries. I'm pretty excited about being able to have a lot of that out of the box with FuelPHP.

I must ask, though. Why would you be working on FuelPHP while working on Reactor. Alternatively, why would you work on Reactor if you're making your own framework that is based on your own vision?

Gravatar
Sören

2011-01-08

You are saying Kohana is incredibly well written, just the documentation is lacking behind. So why don't you just write a good documentation for kohana, instead of writing a whole new framework plus a documentation anyway which is in the end almost the same?

Gravatar

2011-01-08

Shawn Mccool: That sounds like an impressive piece of work but I can see it being a whole pile of hack. Glad you'll be trying it out! :)

I'm working on both as I do lots of different kind of work. I work with CodeIgniter every day at the day job building applications and websites of all kinds. During this time I have discovered lots of bugs and lacking features. Reactor is not about changing everything, that is what FuelPHP is for. As an example, my last commit to Reactor was to let $this->user_agent->is_mobile() accept 'iphone' to check specifics, which is something I needed at work.

Sören: That's not exactly what I said. I said that lots of their libraries are written incredibly well. I am talking here about technical skills as people like shadowhand leave me miles behind in technical skill. That said, very technical code does not make for a great framework as new users can get confused as hell. FuelPHP is not all about "low entry barriers" like CodeIgniter, but it still does not need to be so complicated. I want to look at my code and feel proud, not think "why the hell am I doing all that?".

Basically there's lots of room for frameworks. Reactor is to make a stable brilliant framework better, FuelPHP is to try something new. Oil especially is a part of that that beats anything Kohana has. Rails style scaffolding, Git package installation, etc. It will kick some ass!

Gravatar
Dominic

2011-01-09

set it up and played around adding new controllers and views and a browse of the docs. looks good, No bloat!

Gravatar
Brett Alton

2011-01-09

Oh man. I wrote a project in CI 1.7 in September, am finishing up a project this month in Kohana 3.0... and now this!? At least I'll get an excellent perspective of all three frameworks.

Keep us updated and please keep the DOCS updated. #1 con for Kohana: Documentation.

Gravatar

2011-01-10

Well good news, it's released as BETA and the documentation is basically complete:

http://fuelphp.com/docs/

Gravatar
Andreas

2011-01-10

I got a tip from a friend about Fuel and decided to check it out, but I'm a bit disappointed in the lack of unit testing support, seeing not only frequently use of singletons but mainly controllers executing their intentions. Have you looked at how ASP.NET MVC 2/3 handles the controller execution? By returning an (in their case) ActionResult from the controller actions you completely separate the intention from the execution, making the controller much more testable.

Gravatar
Alfredo

2011-01-10

@Andreas: The fuel framework has unit testing out of the box, also you might want to keep things on their place ASP.NET is a totally different framework, based in a totally different tecnology, even thou some logic can be applied to php, it makes no sense.

Gravatar
Andreas

2011-01-10

@Alfredo, I'm not talking about having a unit test library in the framework, I'm talking about a design that makes unit testing easier. Of course you can adopt the command pattern from ASP.NET MVC for any PHP framework, it has nothing to do with technology and makes very much sense.

For example: Instead of sending data to $this->output in a controller, you should return your intentions encapsulated in a class. When testing a controller, I want to:

- Mock as little as possible of it, getting user input binded as method parameters (not $_POST)
- Not having to hope that SomeStatic::ImpossibleToChangeClass() or other singleton does what I want in a testing environment
- Have things dependency injected in the controller constructor
- Test what the controller returns, not having to know the inner works of it to find out if my request was redirected or displayed in a given set of circumstances.

The above points are something that basically all PHP frameworks are missing, and I'm surprised why not even a new framework consider those great productive ideas.

Gravatar

2011-01-10

Andreas: Everything you have described is possible through the Octane package by running php oil octane testname, but sadly our Lead Developer Dan Horrigan is in hospital and has been for the last week. He is responsible for that package and it has a bug or two so we left it out of the announcement.

You will love the ease and separation provided by the testing system, but it won't be available for a few days.

Gravatar
Andreas

2011-01-10

Oh, that's nice to hear! I'll be looking forward to that, and hope that Dan gets a speedy recovery. Not just for the bug fixes of course. :) Thanks for your reply!

Gravatar
Nemanja

2011-01-11

This is looking cool. But I'd also like (like someone already mentioned) a (set of) screencast(s) to start with... that's why I started using CI in the past, so I bet many ppl will like it also! :)

Gravatar
Dave

2011-01-12

This is probably the wrong place for this post :) I have been stalking you guys for awhile as I have a CI project that I have been working on. I am an old school programmer who is not OOP oriented and not PHP strong. I come from the database world, assembly language and basic. So I have been looking hard and heavy for a framework that is relatively easy to use and full of features.

From a feature set, here is what I am looking for:
a Auth library
a billing library - support for paypal, amazon fps, google checkouts
a image library - ability to watermark, rotate, resize
a video library - ability to convert, etc. (like ffmpeg-php)
a amazon library - support for s3, ec2, sqs, rds
a transparent database driver - support for mysql, postgres, Mongo, etc.
a pdf library - the ability to create pdfs, modify pdfs, etc.
a qr library - the ability to create qr images.

Currently there is a framework that does a lot of these - vork.us - the issue is that it suffers from is no community at all. The documentation is poor to say the least.

So my question - are you guys looking at adding any of these type of libraries to Fuel?

Thanks.




Gravatar

2011-01-12

Dave: Auth, Image and "transparent DB layer" yes but to the rest of them... not directly.

Billing, Amazon and PDF all have would all be a large amount of code and only relevant to a very small group of people. Look at projects like DOMPDF, there's quite a few files in there!

The idea of the package manager in Oil is that we make it crazy-easy to support extra packages. You just type "php oil package install amazon" and that will install the package for use in your application. Those packages come from Git so are either written by us or officially supported (forked) onto a Fuel account.

I believe a framework should not try to do everything, but it should make it bloody easy for others to get their work to other users. Sound good? :)

Gravatar
Dave

2011-01-12

Phil it sounds good and I understand. Seriously man, I do. I feel sorry for the devs because what I want in the framework is 100% useful for me, but it maybe useless for others. What others want in the framework is 100% useful to them but maybe useless to me.

It sounds as if right now you guys are taking the Drupal model. Have a very strong core, well documented API and allow modules.

Are you guys going to centralize the packages or are they going to be decentralized all over the internet?

As an ENDUSER :) central locations make life much easier. In my opinion, the ability to see all the modules, libraries, addons, et al in a central location makes choosing and finding them significantly easier. It also helps the community as the community sees all of the addons and can assist in some that need it, comment on those that work/don't work.

Gravatar
Montreal Web Design

2011-01-13

I looked at the code, and it looks pretty clean, but it needs more docs.

Gravatar

2011-01-13

Dave: There will be a "fuel-community" source and a "fuel" source, which are essentially just GitHub profiles. Anyone can host a package but it will only work if their profile is in your packages file.

Montreal Web Design: Was that an offer? We accept pull requests! ;)

Gravatar
Liam

2011-01-13

Great Job Phil and Team, I think am going to love this alternative PHP-FW you've created! Hope to grow older and evolve with it too! :)

Godspeed and Keep the FUEL pumping and rockin!!

Btw Phil, I can have one of your mistresses if you want to? haha! =)) *KIDDIN*

Gravatar
Dwayne

2011-01-14

I was anticipating this framework long before Reactor was announced, however after looking at Fuel and playing with it, it seems to require a hell of a lot more typing and in my opinion the name-spacing, etc just makes files seem more cluttered.

Good on you guys for creating it though, but I think the simplicity of Codeigniter will never be beaten in terms of ease of use and documentation. I don't mind using $this->load instead of using Request::factory('errors/twitter')->execute() which is twice as longer, ugly and annoying. When I have a tight deadline and budget, I don't want to waste development time writing out long lines of code Codeigniter can do in less the characters.

Gravatar
Demogar

2011-01-16

Great post and the project seems to be very interesting. You're right about Kohana, Kohana 2.x was great, but 3.x is simply hard to understand (using just the documentation). You have to dig into the code too much.

I've been playing a little with the framework and it feels great to work with, it's a great work, congrats! :]

I'm curious: why don't you just support natively Doctrine or Propel as main ORM (just like symfony) instead of building another ORM?

Gravatar
Jelmer Schreuder

2011-01-16

@Dwayne
how can you compare $this->load with Request::factory()? The first is used for loading in CI, which is much shorter in Fuel as you don't need to load (that's what autoloading is for). And Request::factory() is used for HMVC requests, something CI doesn't support. So this whole aruement seems kinda void.

Also your point of using namespaces makes no sense to me, all Core classes may be in Fuel\Core but that's only to allow you to extend them in the app. If you don't extend them they're aliased. So You'll never use Fuel\Core\Uri::segment() but Uri::segment() - which is shorter than $this->uri->segment().

@Demogar
We don't want to replace Doctrine or Propel, those are massive and incredibly complete ORMs. We do include a lightweight ORM in the form of a true Rails-like ActiveRecord implementation. (nothing like what CI calls AR) It's up to you if you want to use either of those, we may even include some documentation on how best to achieve that.

Gravatar
Emmanuel Okorie

2011-01-19

Time to get my feet wet with something new... This should be interesting!

Gravatar
Peter

2011-01-21

I've been building my new application on FUEL for a few days now (great timing on the release, as it turns out). I only wish it had a little more documentation (at least, the empty sections of the current documentation could be filled).

I know you guys are working hard... and the result is great. Keep it up!

Gravatar
William

2011-01-28

So far I am loving what PHPFuel and I think I'm gonna stick with it. Keep up the good work guys! :)

Question, when is the stable version to be release? and when is the documentation for active records be completed?

Many Thanks!

Gravatar
Dagrevis

2011-03-12

Thanks for great introduction! Looks kinda awesome! =]

Gravatar
Burton Kent

2011-06-23

Hey Phil,

I develop in both CodeIgniter and Kohana, and I also outsource projects in CI. CI is great for outsourced stuff because it's EASY to see in the code what's going on. Coders can find what they need to know, and debugging goes quickly.

I would never, ever outsource something done in Kohana, unless I had a really, really good developer. It wouldn't be cheap at all. Kohana is extremely well engineered, but that actually causes a steep learning curve and makes it harder to debug. (Their error messages rock though).

I'm hoping Fuel keeps the simplicity / straightforwardness of CodeIgniter but has the power and OO features of Kohana. I >hope< that's your goal - it would be awesome.

Gravatar
Contru Budlll

2011-08-24

common guys - it ends all up like always in php world - you will be sticking together components / scripts / code pieces from different sources because there is no consistent code sharing paradigm in php, so it will always feel like a patch work. BTW the backslashes are so extremely awkward, feels like building your daily work on a fail.
I am an oldschool php dev and I can only give you one advise - do not dig deeper into this, you will never get accomplished what you want to get, because of what I wrote above - no consistent code sharing idea in php, all just islands. If you want to be truly productive take a look at django, after a short while you will not understand why you tortured yourself with php short-sightedness that makes you feel like a little boy not knowing about the world.

Gravatar
Phil Sturgeon

2011-08-24

Totured with PHP short sightedness? Really? You assume I have never written anything in any other language? You act like I'm just a stupid little PHP developer who is desperately clinging to PHP because he doesn't know anything else, and that is ridiculously far from the truth.

I've built sites for clients using Rails and dabbled with Django and sure some of it's nice, but PHP is still king and will be for a long time to come.

None of Fuel is hacked together and a lack of sharing is nothing to do with pros and cons of this framework. Hell we're improving sharing thanks to package management which works a hell of a lot like Gems without being "system level" which fucks up so much.

If you don't like PHP then don't use a PHP framework. We love it, so we use it.

Gravatar
Boabramah Ernest

2011-09-15

For all those criticizing PHP and FUEL, go to hell. Every language and framework serve different purposes. There are projects you will want to use django or rails and i love those framework. And to all those requesting features and documentation, Please let us all invest our precious time to support fuel. suggesting and requesting is not enough. Phil I am not all that a Guru in php. But I would like to help with the documentation. where do I start?

Gravatar
Diego

2011-10-08

Hello Phil, I have one question for you, I have uploaded fuelphp to my server( it is running php 5.3) but i got an error, could you please help me?

I am new in the framework. Thanks a lot and greetings from Mexico.

Warning!

ErrorException [ Warning ]: include(/home/cloudmed/public_html/test/fuel/packages/oauth/bootstrap.php) [function.include]: failed to open stream: No such file or directory

COREPATH/classes/fuel.php @ line 395:

394: { 395: return include $file; 396: }

Gravatar
Sven Walter

2011-12-02

i think fuelphp is great! you guys should have a look at http://www.phpactiverecord.org/

it is a nice orm implementation in ruby on rails style and i really like that. is it possible to get this as a orm package for fuelphp?

Posting comments after three months has been disabled.