Category Archives: FuelPHP

A Non-Technical Introduction to FuelPHP


Temporal Models Coming To FuelPHP 1.6

One of the features that would make FuelPHP 1.6 unique is the introduction of temporal models. Temporal models enable you to determine the state of a model at a point in time rather than the current state. Think of it as a kind of versioning. If you have used a Wiki, you are probably aware of the ability to view each of the different edits, which is along the lines of walking backward through time to determine how the Wiki page came into its current state of being.

Two other features of FuelPHP’s ORM package are Entity-Attribute-Value (EAV) containers and soft-deletion. EAV containers are used to store attributes about a model when you cannot determine beforehand what those attributes may be, thus removing the rigidity of having a schema. Soft-deletion, as the name implies, is when you do not actually delete data from a table but instead mark a field that indicates that the row should not be displayed. Both the EAV container and soft deletion features are already available in FuelPHP 1.5.

Oil now generates controllers with configured prefix

If you have used oil in FuelPHP 1.5.1, you may have noticed that the controllers generated by the oil scaffolding do not use the configurer controller prefix. What this means is that if you are using namespaces or something other than the default controller prefix, the scaffolding controllers will not work.

The good news, however, is that Harro (WanWizard) commited a fix to the oil git repo last week so you will see a fix to the issue soon, perhaps in the FuelPHP 1.6 or 2.0 release. Until then, try to stick to the default prefix (fuel/app/classes/controller directory and no namespaces) or you will have to refactor the code generated by oil to get it to work with the rest of your application.

While you are learning FuelPHP, consider getting a copy of the FuelPHP Guide from the Kindle Amazon eBook store.

Migrations to Manage Database Changes

With migrations, FuelPHP provides an easy way to manage database changes. It is typically used in combination with the oil utility to make changes to the database. Migrations are PHP files that push database changes in a versioned form. The generation of migration scripts is also simplified by the oil utility, which treats the name of the migration as an indicator of the activity to be performed, such as creating or renaming database tables.

Every migration script provides the ability to move up or move down a version so you do not have to keep multiple databases running to test your app across different versions of the database, at least in theory.

Why FuelPHP – Configurable convention over configuration

If you had a go at switching to CakePHP, you are probably aware of the conventions to follow to get the framework to provide its ORM features. Sure, FuelPHP has conventions too but they are simpler, and the ability to configure what conventions you would like to use or even override those conventions are well-documented.

There still is a bit of rigidity in naming controllers but you can name your database tables and columns as you please and then define how FuelPHP should treat those columns. Having said that, I should also mention that FuelPHP does not make the configuration of the ORM as complex as Hibernate does.

There is also the ability to have FuelPHP auto-discover columns and leave most of the heavy lifting to the framework while you are prototyping.

FuelPHP Authentication and Authorization

The FuelPHP Auth package provides the ability to authenticate users and determine if the have the rights to access a particular resource using roles. Think of roles as the distinction between editors and journalists in a news agency. Journalists can create articles but they do not make it to print till editors approve the articles. Pages are the resources protected by resources and call the Auth package to authorize users.

Check the logs for Locale warnings

If you are running Linux and haven’t set your locale yet, FuelPHP may be running with the default en_US and silently logging a warning if your system doesn’t support the locale. Often, Linux systems have the locale “en_US.utf8” instead, but you can determine what is available with a “locale -a”.

The logs located in fuel/app/(year)/(month)/(date) will tell you if there are any warnings. You can run a “php oil help” from the console to generate an entry in the log file if there is a problem with the set locale.

Harro Verton, thanks for the tip on determining existing locales and on using en_US.utf8.