Progress with Eloquent, and Laravel
posted 2013-02-27 by Phil Sturgeon
Update: The list of converted modules below is usually out of date as we progress. As of April 2nd 2013 the Users moodule has also been converted to use Eloquent and is currently having Groups and Permissions merged in. Maintenance module is using the Laravel Query Builder and Settings is half done.
We tried to make it pretty clear that we would not be using any of Laravel in 2.2.0 (which is now at RC2 and approaching final in the next week or so), nor would 2.3.0 be a good time for a re-write if we want to get you new features any time soon. Still, people have been asking a lot about when the "Laravel version" of PyroCMS is going to be out. It's great to see so many people excited about the switch (we knew you would be), but it is going to take some time.
The approach we are taking for the conversion is the path of least resistance. Rewriting overnight would suck for everyone. Not just for us, but also for all of our module developers, and that in turn would be detrimenrtal to every single user - even end-users.
Instead we've started by converting all of our database interaction to use Laravel's Database tools: Query Builder, Schema Builder, and Eloquent ORM. This is easily the largest part of the move, and also gives us a chance to implement a PSR-0 autoloading area in each module.
The converted modules so far include:
- Email Templates
The remaining modules are:
- Permissions (Probably getting merged with Groups)
So, we're about half way along with out Eloquent conversion. This has been nice, quick and easy thanks to all of the help we've been getting from the community. Switching from MY_Model based models to using PSR-2 style Eloquent models has been a dream, and its actually fun to work on!
If you'd like to have a crack at converting a module (Settings should be pretty easy) then hop on the 2.3/develop branch and have a go. Look at the completed modules and send a PR early, then we can help you get it right even if you're not confident about it. Pull Requests are amazing for this.
Farewell Ion Auth, Hello Sentry 2.0
As part of moving to 2.3.0 we've been replacing as many of our libraries with their Composer counter-parts. Things like SimplePie and Lex we're all Composer-ready, so we could just delete the CodeIgniter library and across. This makes the change to Laravel 4 in PyroCMS 3.0 considerably easier as Composer will handle the depdencies, and we don't need to convert CodeIgniter libraries too.
One library that we've had to ditch is Ion Auth. It has served us extremely well for years, but it is time for a spring clean with our user authentication. Switching from Ion Auth to Sentry was an interesting project, but it has mostly been completed in the feature/sentry branch.
Right now installation with new users works, migrating from 2.2 based branches works, and it will still let your users log in - even though we've upgraded to a super-duper-new password hashing algorithm. That was hard work, because we didn't want to lock all of your old users out. You're welcome!
Switching to Sentry 2.0 provided the following awesome new features:
Support for the PHP Password Hashing API
The PHP Password Hashing API has been implemented for PHP 5.5 which is not actually out yet, but thanks to the password_compat package (made by the same guy: Anthony Ferrera) we can use this same functionality.
PyroCMS is now future-proof.
The BEST thing about this, is that as new versions of PHP or this compatibility package are released, PyroCMS will always use the most secure hashing algorithm available. By default that is Bcrypt (which is crazy-secure) but over time it will seamlessly switch over to using new passwords without ever effecting your users or installation. Magic.
It will just happen now. If somebody tries to log in way to many times and fail they'll have to take a walk and try to remember their password, or use the lost password system. This ensures bots can't just try to guess passwords by trying over and over again. Right now we're pretty secure against that and it would take a bot months of constant spamming on your server to get lucky (if not years), and of course your server should have mod_security enabled to protect against this, but with this feature it would take a few million years to get in.
Users can be in multiple groups
Users can have their own permissions
Slick Permission Checking
So instead of $this->current_user just being a stdObject this is now going to be an instance of Pyro\Modules\Users\Model\User, which has all sorts of cool methods, including hasAccess('foo') which will drastically improve the usual permission checking system.
This is the bit thats holding us up at the moment, as the permissions are stored in a single array, where as we need them to be a multi-dimensional array of module.permission. We're talking with the author of Sentry about this, so we'll see what happens in the next few days.
This has been a quick "Where we're at". The "Laravel-version" 3.0 does not exist in even its early stages and it won't for another month, but the "Composer-based" 2.3 version is ticking along nicely.
We've also picked up a slick little Roadmap plugin for the GitHub API, so we can get that up on the site shortly to make it painfully obvious on the progress we're making.
Be excited guys, 2.3 is looking amazing already, and 2.2 is going to be out any day now.
Also, buy my book: Catapult into PyroCMS.