Lavarel Archives - Page 2 of 2 - developed.be

I’m getting back at the PHP Laravel framework. I studied most of its documentation and have a decent idea what it can do.

However, I’ve reached at a point where I need a decent “imagecache” functionality, like you have in Drupal. There’s an attempt in Laravel but it doesn’t come close to the easiness of imagecache (probably one of the best Drupal modules).

Further down the road I must have some permission-system, user forms, a comment tool system, Mollom protection, Captcha’s, forgotten-password-mails, newsletter forms, node locking, search integration, OpenGraph, social media toolbars, permalinks and a zillion other features.

The thing is: do I have to reinvent the wheel? Do I even want to do that?

How much time does it take to make a light version of imagecache? If it’s done in half a day it might be worth it. The powerful thing is that I have total control about every little detail. Gone are the days that you can’t get around something because that’s the way it goes in Drupal (eg: must every node-type have a body-field?)

Can I make an opensource CRM/CMS based on Laravel? Ready for others? Is anybody waiting for that?

(for those wondering if I’m wasting someone else’s money, I spend most of my research in my spare time)

Update: I decided to go for it. Things go pretty well so far but, like any IT-project, it’s a lot of work.

To be honest, I’m a bit fed up with Drupal lately. We’re stuck with an ever-growing fat Drupal6 site, and the monster doesn’t get easier to maintain. The question isn’t if we will upgrade, but to what we will upgrade. The logical upgrade to Drupal7 will be enormous because our website has over 150.000 lines of custom php-code (not mentioning css, js, themes). So moving to Drupal 7 or creating something entirely new based on a framework… I don’t dare to say how much difference in time it will make, but I do know that the new thing must be a giant step forward to what we have now.

Why moving from Drupal to a Framework?

As much as I love Drupal, the thing is… a lot of modules do kind of what I want, but they don’t do exactly what I want. Customizing a contributed module sometimes takes me as long as I would write it myself. Especially when there’s little info in the README-file or when there are hardly any comments in the code. To give you an exampe: it’s faster to lookup the url for the admin-page in the menu-hook, than to find it in the documentation or in the navigation.

Plus, what irritates me the most. When you have +75 modules, +100.000 nodes and +10 currently logged in users, the thing gets slow.. slooowww! Even with advanced caching tools such as Memcached,  view-cache or Varnish, the thing still goes slow, even on a dedicated server. No wonder: every hook is checked for each and every request.

So I’m looking for something faster and more OO-like. I have a C#-background and the way classes are mimicked in php (including inheritance, namespaces) is simply terrible. I’d dare to say Drupal goodbye, as long as Drupal 8 isn’t released an is more decent.

My comparison of PHP Frameworks

Pfhew, long introduction, but here’s my research on PHP-Frameworks. Briefly, a framework provides a set of functions and classes to help developers write code faster and more structured. Most of them implement certain design patters, of which MVC is by far the most popular. The aim of MVC is to seperate the database-talking-code (Model) from application-specific code (Controller) from html (View). It also features a URL-mapping system to set “clean url”-rules and to separate the code-files from the actual urls (eg: /bootstrap.php shouldn’t be accessible through a browser).

Some devs use the bootstrap of a CMS as a framework-starter (like my RSS-boostrap), but it should actually be the other way around: a CMS should be build on a framework. Drupal8 will (maybe) rely on parts of Symfony2, but that won’t be out till 2014.

Continue reading “PHP Frameworks, which to choose in 2013? A comparison.”…

« Previous Page