This is part I of a two-part comparison of PHP frameworks: CakePHP, CodeIgniter and Yii:
- Part 0 explains my comparison criteria.
- Part I is this part. I evaluate each framework after reading nearly all their documentation and writing a Hello World application.
Part II will be the result of my experience as I use each framework to write a prototype for my real-world application.Sorry. Part II is cancelled due to lack of time (this kind of article takes a lot of time).
I have spent 4 weeks studying each framework carefully. This document is long. I tried very hard to make it as short as possible without compromising on fairness, clarity or completeness with regards to my initial criteria
Part II will also take a few weeks, as I write an application prototype with each framework.
Contents
Simplicity
It is hard to judge framework simplicity before making an application, but I can make some initial comments based on the documentation:
- CakePHP
-
Installation: I had a problem with Apache that was not documented. I had to edit three .htaccess files to add a “RewriteBase” command.
Usage: Helpers, Actions, Behaviours, Layouts, Components… Do I need to know all that to make my program? Cake seems to have a higher barrier to entry and at the moment I don’t see any special feature it provides that the others don’t.
All frameworks come with a default layout and CSS. For my benchmark I had to remove this so all frameworks are doing the same work. With CakePHP I had a very hard time finding the layout file Cake was using. It was not in a logical place (inside my app directory).
- CodeIgniter
-
Installation: Trivial. Just unzip the file and you are good to go.
Usage: CodeIgniter looks quite simple. The documentation never makes it look complex. My hello-world program was done a lot faster with CI than with Cake. Over-all, CI seems to have a low barrier to entry.
All frameworks come with a default layout and CSS. For my benchmark I had to remove this so all frameworks are doing the same work. With CI this was automatic when I made a new view. CI doesn’t insert layout unless you ask it to.
- Yii
-
Installation: Easy. You have to run yiic to create the web root directory. There is also a PHP version (yiic.php) which is good if you don’t have ssh access. Yiic is well documented.
Usage: Yii also looks simple and straight forward, though a bit less so than CodeIgniter. My hello-world program was done almost as quickly as with CI.
All frameworks come with a default layout and CSS. For my benchmark I had to remove this so all frameworks are doing the same work. With Yii this was very easy. The layout file is in a logical place and it is well documented.
I am pleased to report that none of these frameworks require you to learn a templating language like Smarty. PHP itself makes a great templating language. I have used Smarty for several years, and honestly I think it’s more trouble than it’s worth. I note that Yii and CodeIgniter both come with an optional templating language for those who like templating languages. But as I said, it is optional.
I’ll reserve a final verdict until I write the application prototypes in Part II.
Documentation
Please take the following with a grain of salt. Docs often look different when you try to actually write an application. If the docs are inaccurate, or incomplete, you won’t know until you start writing. So far the only program I’ve written with these frameworks is hello world.
- CakePHP
- My first impression was quite positive. The documentation looks complete and easy to read. The tutorials were a bit hard to find (they are under “Example Applications”). When I wrote hello-world I hit a snag (404 error) and the problem was not documented. I had to edit Cake’s .htaccess files to fix it. I would have liked to see a trouble shooting section in the manual. I also had a very hard time figuring out how to remove the extra stuff (header, footer, style) that Cake includes by default.
- CodeIgniter
- My first impression was again positive. I note that it took me a lot less time to write hello-world with CodeIgniter than with Cake. I think this is mostly because CI is simpler, but I do think that the documentation had something to do with it.
- Yii
- Again, my first impression was positive, and I wrote hello-world very quickly. When I wrote hello-world I had to remove the extra things that Yii includes in the page to make the benchmark fair. Finding out how to do this was quick and easy.
All seem to have good documentation. I had a couple of problems with Cake’s, but I can’t make a strong statement yet.
Performance
In this section I will discuss two different benchmarks. One carried out by myself, and one carried out by the Yii team. I believe that both are worth considering.
Key similarities:
- Both benchmarks try to measure the minimum overhead of each framework. They get the framework to print “Hello World” and nothing more.
Key differences:
- I use the default configuration of each framework. The Yii team tried to optimize each framework to print “Hello World” as fast as possible.
- Yii’s benchmark just runs die(). Mine uses the MVC: A controller puts “Hello World” in a variable which is passed to the view to print inside a basic HTML page.
- Yii used a dedicated server for the tests. I used the shared hosting service where I’m going to deploy my actual application.
Thus, Yii’s benchmark is more technically fair, but mine might give a better impression of real world behaviour. As always, all benchmarks should be taken with a grain of salt. The benchmarks are expressed in terms of Requests Per Second (RPS) so more is better.
| Version | Yii’s test: RPS with APC | |
| CakePHP | 1.2.0 | 41 |
| CodeIgniter | 1.7.0 | 146 |
| Yii | 1.0.1 | 331 |
| Version | Yii’s test: RPS without APC | |
| CakePHP | 1.2.0 | 31 |
| CodeIgniter | 1.7.0 | 77 |
| Yii | 1.0.1 | 98 |
| Version | My test: RPS without APC | |
| CakePHP | 1.2.0 | 32 |
| CodeIgniter | 1.7.0 | 52 |
| Yii | 1.0.1 | 50 |
Benchmark details:
Yii’s page describes their benchmark. For my benchmark, each framework had to run the following PHP code in a view:
<html> <head> <title>Greetings</title> </head> <body> <h1>Greetings from XYZ</h1> <p>The greeting message is: "<?= $message ?>"</p> </body> </html>
Where $message is provided by the controller and its value is “Hello World”. The requests per second were obtained using the ApacheBench tool with the command “ab -t 30 -c 10 URL”. My testing environment is a shared hosting account running on:
- CentOS 4 Enterprise Linux.
- Apache 2
- PHP 5.2.6
- CPU: Quad-Core AMD Opteron(tm) Processor 2350
- Memory: 8GB
Flexibility
- CakePHP
- CakePHP is very focused on conventions. It has a lot of expectations as to how you name your files, your classes, your database, your methods, etc. I can’t yet say whether this will present a problem for me, but I worry that it might.
- CodeIgniter and Yii
- CodeIgniter and Yii both look quite flexible. It is difficult to look at the documentation and say that one is definitely more flexible than the other. Both follow the MVC pattern, but they don’t feel rigid. CakePHP relies more heavily on conventions than Yii and CI.
Some examples of similarities and differences:
- All frameworks expect you to follow certain naming conventions for your controller.
- CakePHP requires that you create a model, a database and a table even if your program doesn’t require one.
- Cake calls a view automatically, based on the name of the controller. With CI and Yii you call the view explicitly. So Cake has a little more “convention over configuration”. But in turn, with CI and Yii you can call multiple view files.
Here is a code example:
/* CakePHP */
class GreetingsController extends AppController {
var $name = 'Greetings';
function index()
{
$this->set('message', 'Hello world');
}
}
/* CodeIgniter */
class Greeting extends Controller {
function index()
{
$data = array('message' => 'Hello world');
$this->load->view('greeting', $data);
}
}
/* Yii */
class GreetingController extends CController {
public function actionIndex()
{
$data = array('message' => 'Hello world');
$this->render('greeting', $data);
}
}
As you can see, the CI and Yii versions don’t really look more complicated than the CakePHP version, but they give you an extra feature: you can load more than one view file. For example, you can load a special header, insert a widget, etc.
At the moment I cannot judge which is more flexible.
Security
Security is complex because there are many possible attacks. This section is a bit long. I’ll try to stick to the point. This section is divided according to features or attacks.
- Access control
-
For background, see Authentication and Authorization.
- CakePHP
-
I found CakePHP’s access control complicated. You use a code generator (“cake bake”) to generate schema files and ACLs. The process generally felt complicated. Some of the terms (ACOs, AROs, Requester) threw me off initially.
I expect access control to be somewhat complex, but Cake’s was more complicated than I expected. It looks powerful, but hard to use. I felt I didn’t know what was going on and didn’t have control. And security is a place where I want to know what’s going on and want control.
Quick Test: I didn’t see an obvious way to add password strengthening. The tutorial says that if you hash passwords yourself the system won’t work.
- CodeIgniter
- As far as I can tell, CI does not offer access control features. Access control can be complex (groups, roles, etc) and it’s nice if the framework can help you.
- Yii
-
I had a much easier time understanding Yii’s access control system. I won’t call it “simple”, but that’s because access control is not simple. I’d say that Yii’s access control is as simple as possible – but not simpler. As I read through the docs, I felt I knew what was going on and I felt I could modify it to fit my needs.
Quick Test: I could immediately see how to add password strengthening.
Some Yii features that I like
- Flexible: You can have access rules based on user IP or request type (GET vs POST) or rules that match anonymous or authenticated users.
- Return Url: You click on a link but the session has expired. You are sent to the login page. You login, and the system automatically takes you to the page you were trying to access. For me, this is very useful.
- Role Based Access Control: RBAC is more flexible and powerful than the traditional ACL. With Yii you can write your whole application ignoring RBAC and only use it when it solves a specific problem. So the system is as flexible as it needs to be, but your access rules are never more complex than they need to be.
- Dictionary attacks
-
A dictionary attack consists of trying a large number of common passwords from a password dictionary. For a web app, this attack can be very effective. The recent attack on Twitter was a dictionary attack.
There are many ways to block dictionary attacks: Lock the account after X failed logins, time delays, CAPTCHAs. Each has its pros and cons. Locking accounts is easy and effective, but it opens a denial of service attack: Someone can try many logins, not to gain access, but to lock out users. Here is one I like: After 5 failed logins, you must solve a CAPTCHA to attempt additional logins. It balances dictionary attacks, DoS and user convenience.
None of the frameworks have features specific to dictionary or DoS attacks, nor do I expect them to. The real issue is, Can you implement your preferred login method with this framework? So it’s a question of control and flexibility. With CI and Yii I’m confident I can do it, but I’m not so confident I can do it with CakePHP.
- Cross-site scripting attacks (XSS)
-
XSS has overtaken buffer overflows as the most common security hole. It works like this: Someone posts a comment on your blog and that post includes malicious JavaScript. When you view the blog, the JS code is executed. Since the JS code is coming from your domain it is “trusted” by the browser. It can read your cookies, or manipulate the page contents (e.g. “Session expired. Please enter your password”).
CodeIgniter and Yii both come with HTML filters that can remove JavaScript code from the user input. I am sad to report that CakePHP does not seem to include an XSS filter.
- SQL injection attacks
-
SQL injection is one of the most common security flaws on web apps (funny comic). It happens when user input is interpreted as executable SQL code. For example:
$q = "SELECT * FROM users WHERE l = '$user' AND p = '$pass'"; $result = mysql_query($q);Suppose the user enters the password foo' OR 1='1 Then the query becomes:
SELECT * FROM users WHERE u = 'foo' AND p = 'foo' OR 1='1'
Since 1='1' is always true, this query returns all users. The most common (and wrong) solution is to escape strings using a function like addslashes() or mysql_real_escape_string():
$pass = mysql_real_escape_string($pass); $user = mysql_real_escape_string($user);
What’s wrong with this solution?
- It is error-prone, since you have to remember to escape every parameter.
- It depends on someone being able to find every possible character that can be exploited. The good guys have to find every attack, while the bad guys only have to find one. This is a losers game.
Chris Shiflett shows how to use a Chinese character to get an SQL injection through addslashes. How do we know that there isn’t some Tamil character that will get through mysql_real_escape_string?
The right solution: prepared statements
The right solution is to circumvent the problem entirely by compiling the SQL query separately from the user input. That is, to use prepared statements (aka parametrized statements, aka bound parameters). Prepared statements separate the SQL logic from user data (see here and here).
Does the PHP framework support prepared statements?
Unfortunately, of the three frameworks, only Yii offers prepared statements. I think that the lack of prepared statements is a major problem for CakePHP and CodeIgniter.
- Cross-site request forgery attacks (CSRF)
-
Cross-site request forgery (CSRF) attacks are in some ways complementary to cross-site scripting (XSS) attacks. XSS abuses the client’s trust on the server. CSRF abuses the server’s trust on the client. Imagine that Bob visits a malicious website with the following image tag:
<img src="http://mybank.com/transfer?from=Bob&to=Eva&USD=10000">If Bob is currently logged in to his bank the bank’s server will receive a request from Bob to transfer $10,000 to Eva’s account.
What can you do to protect against CSRF? Other than expiring cookies sooner, the main solution is to use a secret token to authenticate any GET and POST parameters that can modify server data.
CakePHP and CodeIgniter do not seem to have any features for CSRF. Yii offers CSRF protection for POST requests using secret tokens (you have to enable this feature). To complete the CSRF protection you must make sure that GET requests cannot modify server data.
- Cookie hijacking attacks
-
Cookies are routinely used to store sensitive information such as session IDs, user name or a password hash. Cookie hijacking is when a third party gets access to your cookie. This might be through cross site scripting (XSS) or through a packet sniffer.
How do you protect against cookie hijacking? SSL will protect you against packet sniffers. And you should take measures to prevent XSS. You can make the cookie data less useful by not storing long-term sensitive data in it. For example, instead of storing md5(passwd), use a hash that expires like HMAC(date,md5(passwd)).
To my knowledge, CakePHP and CI don’t offer any features against cookie hijacks. Yii has a cookie validation feature that uses HMAC to authenticate cookie data, so an attacker can’t modify an old cookie (e.g. change the expiration date) without detection.
Of course, this won’t help you if you do something dumb like store the plain text password in the cookie.
Yii has a strong edge in security, with better access control and protection against XSS, SQL injection, cross-site forgery and cookie hijacking.
CakePHP and CodeIgniter are a bit disappointing in this area. CI gets a point for being flexible, so it’s easier to add security features yourself.
Other Notes
These are some things which are not part of my core criteria, but I feel are worth mentioning.
- Prototype
- CakePHP uses the Prototype library. I have concerns with Prototype. Basically it pollutes the global name space and it can break valid JavaScript code. So Prototype doesn’t play well with your code or other libraries.
- Scheduled Releases
- Yii has scheduled releases. I wish all open source projects would do that.
- Filtered Input
- CodeIgniter has a very nice Input Class that sanitizes some of the input. It destroys the GET array, and all global variables except POST and COOKIE. This feature doesn’t fit exactly into any of my criteria, but it promotes good code and I think it deserves mentioning. I mentioned XSS filtering in the security section.
Summary So Far
My experience with CakePHP was distinctly worse than with CI and Yii. The docs are generally good, but not better than CI or Yii. I can’t see any area where Cake clearly stands out above CI or Yii. It might be better for simple apps that do everything the way Cake expects. But generally Cake is more complex than CI or Yii and you don’t seem to get much in return.
Yii and CodeIgniter are a closer match. They are about equal on performance, documentation and flexibility. They are both fast, clearly documented and quite flexible. CodeIgniter seems somewhat simpler, but Yii has a strong edge in security features. I’ll have to wait until I write an application prototype with each before I form a strong opinion.
Generally I don’t like comparison tables because they over-simplify things, but I realize that people often want a quick summary table, so here is a rough one:
| CakePHP | CodeIgniter | Yii | |
|---|---|---|---|
| Simplicity | Not great | Excellent | Very good |
| Documentation | Good [1] | Very good [1] | Very good [1] |
| Performance |  |
|
|
| Flexibility | Poor | Very good | Very good |
| Security features | Not great | So so [2] | Excellent |
[1] Take this with a grain of salt. It’s hard to judge docs until you actually write your app.
[2] CodeIgniter gets a point for filtering XSS and for over-all flexibility.
Hello
First, please excuse my English. But I would to say, that this is in fact that much founded article (to get to this topic) that i have found in the network – supper job – thank you.
apropoz… spricht hier jemand auch besser deutsch als englisch?
Thanks. Glad it was helpful. Sorry I didn’t approve your post earlier. I think my spam filter is eating the post notification messages.
apropoz… ich spreche etwas Deutsch, aber mein Englisch ist besser.
You write ‘CakePHP requires that you create a model, a database and a table even if your program doesn’t require one.’
This is not true as you can type:
$var uses = array(”);
into your code and specify which tables you want to use.
Thank you for your comment, and sorry for the long delay in approving your post (it’s my stupid spam filter). Please see my response to henrikbjorn who raises the same issue as you do.
hi, great comparison, but maybe a better one would be between Yii and Kohana (and maybe Fuse) … those are the new kids on the block and very promising…
Thanks. I’ve heard of Kohana. I have no heard of Fuse. I would be happy to discuss them in a future post (not right now, not soon, I have a lot on my plate right now).
“All frameworks come with a default layout and CSS. For my benchmark I had to remove this so all frameworks are doing the same work. With CakePHP I had a very hard time finding the layout file Cake was using. It was not in a logical place (inside my app directory).” The first congratulations page states where this file can be found in the cake directory.
“CakePHP requires that you create a model, a database and a table even if your program doesn’t require one.” False in a controller set the variable $uses = null; and you dont need a model nor a database.
“I am sad to report that CakePHP does not seem to include an XSS filter” False, look at the Sanitize class.
“Unfortunately, of the three frameworks, only Yii offers prepared statements. I think that the lack of prepared statements is a major problem for CakePHP and CodeIgniter.” when using cake models the data inserted are auto escaped.
“CakePHP and CodeIgniter do not seem to have any features for CSRF. Yii offers CSRF protection for POST requests using secret tokens (you have to enable this feature). To complete the CSRF protection you must make sure that GET requests cannot modify server data.” just enable the Security component.
Maybe you should really read the manuals before making assumptions.
Hello henrikbjorn, thank you for your post. Sorry for the delay in approving it (my spam filer eats all the post notifications). Yes, I definitely read the manual. I spent a lot of time reading the documentation, especially for CakePHP. Reading the documentation throughly was an important part of my review. That’s why the view took over a month to write.
If I missed something that is documented somewhere, the likely reason is not lack of effort on my part, but rather poor documentation. I never saw $uses = null, or the Sanitize class mentioned. If after a month reading documentation for the three frameworks I still can’t find the features, I am inclined to conclude that either the framework is complex or the documentation is poor. In Cake’s case, the framework felt complex and difficult.
Very useful comparison. I hope you’ll get around to making part II, too.
I’m currently trying Yii myself, but after this post I may take a look at CodeIgnite or Kohana, too. Yii may have a good documentation for people who are not new with MVC and frameworks, but for me there is too little explanation of what is what. Too many “explanations” looks like “a controller is an instance of CController or its child class” – which actually doesn’t tell anything about what it really is.
Hi Janis,
I didn’t know much about MVC when I started using Yii. Certainly not more than what you would get on a Wikipedia article.
In brief, the Model means your data. That is, the database and the methods that talk to the database directly (create, read, update and delete records). The View is the user interface. It’s the HTML, the menus, links, etc. The Controller is the layer in between. The Controller is the brains of the application. This is where the application logic lives. The Controller tells the Model to fetch some data, and chooses the correct view to display that data.
Hope that helps.
Thanks for the brief explanation. In general, I somewhat know what those three are but in practice I got confused. For example, if there is some chunk of code that does extended input data processing prior to saving it, or does some extensive data calculation along with decisions on what kind of data select from the DB (may be with several different queries) before displaying it – where this code should go? Directly in the controller’s method who’s responsible for a particular page, in a subfunction or in some component, or maybe some model should deal with all that? And when should the properties of a controller be used and when they should be passed to the view with render function?
Another problem I have with Yii is that I need to learn many news things which I would know how to do in plain PHP or HTML, but which are supposed to be done by the countless Yii’s built-in helper classes and functions. For example, the form labels and input fields are generated by some CHtml methods. And even when I’ve found what parameters must be passed, it can turn out that it does not fit my needs, for example, the generation of label does not allow a colon be added after the label itself.
Also I like Smarty very much (it offers an easier to use mark-up than PHP and deals with all the undefined variables silently), and Yii doesn’t support it.
A thing I like about it is that it supports several internalization techniques, in particular it supports GNU Gettext (po/mo files) which I decided to use and which, as I see, are not supported by Kohana.
Well, anyway, I’m looking forward to your comparison part II. Isn’t there a way to subscribe to comments here, as I won’t remember to come back otherwise.
There is never an absolute rule. At some pointt you have to use your own judgement. But I can give you two guidelines: (1) The model should be “fat” and the controller “thin”. (2) Try to keep the separation: data stuff -> model; application logic -> controller.
In your specific example, I would put the things you said in the model. The idea is that the model takes care of all the nasty data mangling, many-query details, and presents your controller with a simple view of the data. This way the controller can focus on application logic. The controller gives a high-level command like “create user”, even if behind the scenes this might require touching several tables and some data mangling.
For your second comment: Learning new things is a good thing, and you should try to view it in a positive way. If all you know is PHP and HTML, you are very limited. That said, you don’t have to use the CHtml class or any particular class in Yii. On of the things I like about Yii is very little is mandatory. Yii offers easy ways to do most things, but if Yii’s solution doesn’t do what you want, you are free to ignore it and do things by hand. No problem. In my own work, there are some things I do by hand rather than use Yii’s methods.
I do not like Smarty. PHP itself was designed to be a templating language more than a programming language. So it seems strange that now PHP be used for programming and something else be used for templating. I find Smarty inflexible, and I don’t actually want my program to deal with bad data silently. If the data is bad, I’d like to find out sooner than later.
About part II: It will be a long time, I’m afraid. I have a big project at work, I’m getting married, and later I’m going on a honey moon. So I will not have time to do part II for several months.
Subscribing for comments: I am using WordPress. If you know how to configure it so you can configure to comments, let me know. I would love to make that feature available. There must be a way. I just don’t have time to go look for it. Maybe with a plugin…
Alternatively, you can just send me an email: daniel [at] carrera [d.o.t] bz
Cheers.
good job … thanks for sharing
so I guess I should use Yii for my next project … can you also add Symfony to the list of frameworks for comparison
I always use prepared SQL statements in Code Igniter.
Correct me if I am wrong, but Code Igniter does support prepared statements:
$this->db->query(“SELECT * FROM foo WHERE bar=?”, array($baz));
How about DooPHP? It’s a high performance PHP framework and it’s quite easy/flexible to learn & use.
great articles to compare CI and YII …
I was using CI for a year and i found it really usefull . but when I look at rails I got jealously why CI has no ActiveRecord (real one .. not the one that belongs to CI at the moment)…
so I did research and found YII … it seems YII looks better than CI.
Codeigniter does provide prepared statements / binding to handle SQl injection.
Great article buddy. I am a novice in PHP myself and am planning to go for a PHP framework and hence was confused. Was searching for exactly this and found it after a long search. But I can say the search was worth it.
Thanks!
Excellent set of articles. Did you ever write Part II? (If you did, for the life of me I can’t find it
) What framework did you end up going with?
I’m leaning heavily towards CodeIgniter at the moment for my project because it seems flexible, has good documentation, and doesn’t require command-line access. (I’m using a shared host)
Thanks!
Thank you for your article. I am currently working with Zend framework ,but it is way too slow even with APC turned on. Just not confident if my shared hosting account handle two or more concurrent connection. So I searched for faster framework and found your article. Very helpful. I would start looking the Yii documents now.
I did some comprehensive performance benchmarks of all the latest PHP MVC Frameworks including Yii 1.1.1, Kohana 2.3.4 and Code Igniter 1.7.2 as well as others. The results and analysis of results is here: Comparing PHP MVC Framework Performance
The criteria that I got is same with you. Your comparison is quite fair, I think. Its great to found this article for my reference. In the future I might use CodeIgniter for my first php project using a (php) framework. Thank you man
I feel the author is heavily partial to Yii. I code in CakePHP and I think he was in a real bad mood when trying it, because the let downs he pointed just make no sense to me. Specially about “how complicated” it looks and “how bad” the security is.
(in fact the author activated my trolling detector)
I’ve trained a lot of green php programmers (some of them were not even php programmers) in CakePHP, and after crossing the OO barrier, everything’s went smoothly.
I hope the author check out the vaste documentation and try CakePHP again, in a better mood. right?
Regarding your comment “CakePHP requires that you create a model, a database and a table even if your program doesn’t require one.” — it isn’t hidden or tucked away in the documentation. You said you read it but, it’s actually right there in the open:
“If you do not wish to use a Model in your controller, set var $uses = array(). This will allow you to use a controller without a need for a corresponding Model file.” – http://book.cakephp.org/view/51/Controller-Attributes
Regarding password strengthening, you could always perform your actions to the raw password prior to the authentication system investigating it.
Finally addressing the “Cake calls a view automatically” it would seem you again didn’t actually read it documentation very carefully:
“Although CakePHP will automatically call it (unless you’ve set $this->autoRender to false) after every action’s logic, you can use it to specify an alternate view file by specifying an action name in the controller using $action.” – http://book.cakephp.org/view/428/render
Hi Daniel,
Thanks for your great article.
Any idea when you are going to publish the 2nd part?
Thanks
I would like to read Part II as well… looking at your archives, the last post on your site was August 2009 … my guess is that you must of got married July/August 2009 which explains why you have no time to blog anymore!
Thanks for article
Yeah, I got married in summer 2009 and I’ve been busy with other things. Life has changed quite a bit since I wrote this article. My wife and I moved twice, we now live in Sweden, I’ve quit my job to go back to school and do a masters in astrophysics.
I have updated the two pages to make it clear that Part II will not be coming. I feel bad that I will not write Part II, but this type of article requires a lot of time and the last thing I want is to do is slap together a poorly done Part II that doesn’t do justice to the subject.
Thanks ! great article!
Other people have mentioned this, but you really did not offer a fair comparison for CakePHP. I wonder how you can say that the things you missed are hard to find. Three examples above all.
1) You say you could not find the basic layout. First, it is a file called ‘default.ctp’ inside a folder called ‘layout’ in the views. In any case it is stated when you open the greetings page for succesful installation.
2) You say you could not find information about CSRF. You just need to activate the Security component. Are you telling me that you were looking for a security feature and you missed a component called ‘Security’ which has its own chapter in the Cookbook?
3) You claim that CakePHP is tied to convention. Indeed this is not the case: you can configure it otherwise if you do not like the conventions. Where is this information? In the section called ‘Cake conventions’.
This comparison is still high in Google and you should really update it to tell that it turned out not to be fair.
Cake has all the features that you asked for, except PDO.
Excellent article – it may not have been as extensive as some people would have liked, but it was a good basis for me to help determine which framework to work on for our next project.
Great article, I just started learning Yii and I’m very excited about it, it’s really flexible
Excellent article! It puts much light on the ‘obscure’ and almost religious world of frameworks’ comparisons!
Thanks a lot.
Congratulations, Daniel, on a fantastic article!
I’d like to respond to the Cake supporters who are insisting that Cake does do X, Y and Z and have included quotes from the documentation.
I have looked carefully at those quotes and I think they’re very poorly written. I have a degree in English Literature and I reckon I would have came to the same conclusions as Daniel, had I read that documentation.
If you write,
“all terrorists are Muslims (except the Irish ones)”
then you’re guilty of having constructed a poorly structured sentence. That kind of writing is, at the very least, unclear. It does not belong in a manual.
Anyway, great article. I’m a CI user but I’m now thinking about trying Yii. Thank you and please, give up physics and come back to the world of PHP!