Phalcon ORM and other pains

I have been working with Phalcon for a half year now and I love the concept of the framework built in C.


I recently migrated my servers to PHP56 with Phalcon 2.0 and some subtle things broke which made my clients rather unhappy. This makes me reconsider using all Phalcons features, so please don't be offended with these 3 points of criticism.

*ORM: * I have been struggling with beforeSave since apparently in the recent version of Phalcon storing arrays as JSON strings broke my application. After extensively researching I found that isset($this->field) does not work properly. This is essential if you want to optionally format and store a field... So a lot of work here to manually convert arrays to strings and store them. Also, when storing fields an empty string is interpreted as a NULL value. There is a documented workaround involving some juggling with RawValue but isn't ORM meant to take away these burdens? At this point I would not use Phalcon ORM in my next project... there are better (though perhaps not so fast) alternatives.

Template handling The Phalcon default view handling has a somewhat inflexible 3 level structure most likely related to Module/Controller/Actions level of granularity. However, this should not be imposed by the framework. When using mature template engine in stead of PHP it is more likely to use template inheritance rather then these 3 levels that are carved in the Phalcon view. Therefore I passed the View in favour of SimpleView, and have the template decide in which enclosing template it will live. But SimpleView is a stepchild.. why doesn't it offer basic functions such as templateExists()?

This all is perfectly possible with Volt, and having a template engine written in C makes a lot of sense. Unfortunately, Volt does not support nested blocks, essentially limiting template inheritance to 2 levels. So if you want more, you will need to use some more mature template engine such as ageold Smarty or Twig which do support full template inheritance.

Webservices Okay, so in todays arena you need to support REST services and the like. With the advent of Angular.js, Ember.js, Backbone.js and many more webservices make out the most part of your application. In the end, PHP frameworks need to be able to compete in the same field as for instance Meteor and PHP is a long way from there. This is not something that Phalcon can help but still one would expect Phalcon to take a stronger position to simplify rest services.

I really think that a framework today has a strong need to parse and validate JSON based requests, checking existence and types and formats of JSON entities in a json string. This is still stuff you need to build yourself into Phalcon and it is not that difficult but aren't frameworks supposed to take away the long and tedious tasks?

Another thing is the Phalcon response object that fiddles with the output buffer. It has long been a PITA with PHP to stream content to a HTTP response, but PHP rather buffers content before sending it out. That is memory consuming and makes it difficult to serve large files, but it is avoidable, and I think I would have expected Phalcon to enable this easily, rather than adopting this PHP paradigm.

Okay, that was pretty biased criticism. I do love Phalcon and if there are parts of Phalcon that do not suit my needs, well, of course I can always plug in another library. But it would be a shame for such a great project to rely on a bunch of external libs while building these in Zephir or C would offer a tremendous advantage.

Also, when storing fields an empty string is interpreted as a NULL value

This is fixed in 2.0.3

edited Jun '15

@Sven try looking at my Webird project. I did some innovative things with the views there. In particular the view DI function is defined in the base Module class and it is set in each module. When combined with custom Volt helper functions I've been able to provide a common directory for the entire system and a common directory for the module. Also I worked through compiling Volt templates through the CLI.

I just realized that I need to port some View work from my private project back into Webird (and I'll probably tag it as the next beta once I do this). My latest view related code solves a number of issues. I think that I'll work on that today so check the Webird code over the next several days. I based Webird on Vokuro.


Also I'll add that if you've been following Phalcon for a few years you would see that Phalcon is seeing an incredibly rate of bug and niggle fixing over the last few months since 2.0. Definitely half of your pain points will melt away over the next several months if you simply raise the points in a detailed manner like this. As you can see one of your issues is already fixed. Over the last few months I've noticed several times that after I complain about something Andres is putting in substantial effort to fix the issue within just several hours. Sometimes it seems like he is working for me :). Phalcon 2 is a winner and you should stick with it.

edited Jun '15

@dschissler Related to that, EXISTS in subqueries is now supported in Phalcon 2.0.3 :)


Yes I saw that. Thanks. It will probably be a month or two before I can play with that. I'm binding all of the variables with PDO but it would be great to have PHQL do that part and then I'll try disabling literals across the system. My custom search API takes literals and also binds for certain things when using 'LIKE %%' stuff. The default is to do '=' comparison. Using PHQL will help improve SQL injection protection. Off of the top of my head I think that I'll have to use the following approach.

$phql = "SELECT $Model M ..."