A few weeks ago I decided to rebuild this portfolio/blog site. The old site was running on Drupal 7, and I had long tired of the design; it was somewhat slow, too. Add to the mix a bit of boredom with the status quo and a desire to try something new and "lightweight," I downloaded the Laravel (v3) framework I'd been hearing so much about.
After flipping through a few tutorials and going through a large chunk of the documentation I had a pretty good idea of how things worked, as the setup & general ideas are fairly similar to a few MVC frameworks I've used before. I should mention that the documentation is quite good, however it's certainly aimed at experienced programmers. There are times when you need to read between the lines and put two and two together.
I structured the app in a way that resembled Drupal:
- controllers all extend a base which provides a default layout
- base controller provides default variables for common elements
- controller actions override defaults as needed
- layout is assembled from a series of views for the page, regions, entities, and individual components (think: blocks)
It's important to note that Laravel doesn't force you to structure your app in any specific way. For the most part, you can do whatever you want, which can be both a blessing if you know what you're doing, and a curse if you don't.
By this point I've come to appreciate the flexibility of the routing system & restful controllers, and the intelligent class autoloading - nice! Route filters and Events function similar to Drupal's hooks, allowing you to tie into the processing at key points. Everything is simple, clean and flexible - so far, so good.
On the front-end, I'd put together a simple design in Photoshop, implemented it with the Twitter Bootstrap CSS framework (Laravel has a nice Bootstrapper bundle), accounted for a simple responsive design, integrated Font Awesome, and got myself a TypeKit subscription (fantastic service) to get access to some nice fonts.
With the look and feel in place I dug into the actual data: blog entries, projects and a few static pages. I really enjoyed working with Laravel's Migrations and Eloquent ORM. So simple, yet so powerful. Rolling database changes (forwards & back)? Sure. Want a model to access your content's database table? Just extend the Eloquent class. Need to create a relationship to another table and get full ORM support? One line of code. I could get used to this.
Laravel also comes out of the box with a great CLI called "Artisan." Similar to Drush, this allows you to manage bundles (modules) and perform various administrative tasks. Very handy.
Proceeding on with dev I set up image scaling/cropping (simplified version of Imagecache's functionality), DISQUS commenting, path aliasing, and basic taxonomy functionality. I have to admit that by this point the novelty of the framework had worn off, and the "why am I reinventing the wheel?" thoughts had firmly planted themselves in my head. I still had no admin backend, and the idea of building all those forms, permissions, and handling CRUD operations was daunting, to say the least.
After some serious deliberation at such a late point in dev (I'd say I was close to 90% done), I cloned Drupal's 8.x branch and installed a local copy. I had gotten what I wanted out of Laravel (exposure to something new and upcoming, learning a few new tools and ways of approaching dev) and it was time to get back to what was a better option for my site: a proper CMS. (Sidenote: there are several CMS options built on Laravel which I didn't explore).
This change in direction is not a negative for Laravel - it's a great framework, just not well suited to what I was building at the time. Much like most other frameworks, a lot of grunt work is necessary to get what Drupal provides out of the box (some of which can likely be alleviated with existing bundles). On the other hand, if those out of the box tools are not necessary (which would be the case for many web applications), Laravel would be a solid option.
Back to Drupal: D8 is obviously in heavy development, but I've found it to be stable enough for a small, personal site and a pair of hands that aren't afraid to get dirty. Obviously there aren't any contributed modules which are ready for D8, but with Views in core, there's not much else that I'd want. In fact, the only thing I'm missing is Pathauto, but a basic custom solution can take care of that problem in half an hour.
General development of content types, image presents, views, etc. was pretty straight forward. I quickly grew to like the new content editing UI, form validation helpers, and the admin menu. Submitting pieces of content does trigger an error, but everything still works, so nothing to worry about there.
The first thing I noticed about my D8 install was how many fewer database tables there are. Wonderful cleanup from the bloat of D7, as many of those tables have "migrated" into configuration files located in sites/default/files/config_[hash].
Something to note: don't exclude this directory from your version control, as it's required, and will result in severe frustration and dents in your desk between the hours of 12am and 4am (because launching your newly completed site at 12am is a great idea). Additionally, the [hash] mentioned above is referenced in sites/default/settings.php, so make sure there's a match. On the other hand, the sites/default/files/php folder contains code which is environment specific and references absolute paths to various classes.
After figuring out these little quirks, disabling the royal pain that is CKEditor (hoping that'll improve as D8 comes closer to full release), and setting up Varnish to speed up anonymous requests, the site has shown to be quite stable and useable. Plus, brownie points for using the latest and greatest, right?