This post is in reply to a comment on a previous article that I thought contained some good questions:

Hi Josh,

Saw your post on the cakePHP list regarding Drake, here http://groups.google.com/group/cake-php/browse_thread/thread/4d0ad8b73a5... .

I'm hoping you won't mind answering a couple of questions.

In particular, I am concerned with the performance hit of running a framework within a framework, and all the associated redundancies. Was performance something you looked at in any detail?

How much harder is it to work with Drupal's API from within cake than it is to write a native drupal module?

Did you feel the benefits of using cake overcame the increased complexity of having to bridge using drake?

In your opinion, if one wanted to develop a (reasonably complex) module for drupal, would you recommend writing a native drupal module, or writing a cake app and bridging it with Drupal?

Thanks very much.

Hopefully you will be kind enough to reply.

Sorry for taking some time to get back to you! Been busy!!

Yes, I looked at performance issues with Cake in Drupal (Framework in a Framework as you said). For our application, we're weren't looking at really high traffic. The initial box I had for the project was an old dual P-III system running RHEL5. It performed pretty well with some unexplained pauses here and there (may have been hardware related).

We recently migrated the site to a Virtual Machine hosted on a VMWare ESX server -- the performance is excellent! Drupal itself is very snappy and the Cake applications are very responsive. All page loads are under 3 seconds (my target), with the exception being pages with a LOT of data.

You can work with Drupal's API perfectly fine as Cake is executed in the same space as Drupal. We use this fact in some of our small apps that need to know what user they're dealing with, so Cake just pulls data out of the $USER global from Drupal.

The benefits of using cake definitely outweighed the complexity increase. In fact, the complexity increase was pretty negligible as I no longer had to do much consideration of authentication and authorization against our systems (LDAP), as Drupal takes care of that for me. Also, it was easy to integrate the Cake applications with Drupal styles and have a very consistent look, which took care of a lot of the normal UI considerations we were having with other custom apps (ie: things are too ugly :) ).

I see a Drupal Module and a Cake app running inside Drupal as two different beasts. If I wanted to add functionality to Drupal, like add a new content type with custom handling, I would use a module. If I wanted to write an application that I wanted to "live" within a Drupal site, I would use Drake/CakePHP.

Now, your question was mostly about a reasonably complex application. My assumption is that a reasonably complex application's benefit to existing inside Drupal would come primarily from relying on Drupal's many charms, including authentication/authorization handling via user/role-based security, content type management, views (I love views!), exposing data in blocks, etc. Saying this, my initial answer would be to write it as a Drupal Module, because I would likely want my data to be visible to Drupal as a content type to open a world of powerful managing of the data, and CakePHP models will want to talk to the database directly. While this isn't an insurmountable problem, I'd think at first that this alone would be enough to dissuade me.

You could override AppModel and teach it to talk to Drupal's database layer, though (which might actually be a VERY interesting experiment with Drake). Or, if you weren't worried about your data being visible to other Drupal modules, this wouldn't be a consideration. In our applications, we've (so far) not been worried about exposing our data to Drupal (probably quite the opposite, both for security reasons and based on the fact that CakePHP talks with a completely different database server than Drupal), but I can foresee the day that we might want to.

Could you write an effective, reasonably complex application with CakePHP in Drupal via Drake? Absolutely. But you might have to invest some time on integration between the frameworks if that's a concern of yours. All in all, that's a question best answered in your context, not broadly.

  1. Anonymous (not verified) on September 10, 2007 - 11:12am

    Hey Guys,

    i was figuring out which one will be best for my Ecommerce project CakePHP, Drupal, Joomla or PHP Nuke.

    I have a learn any one of it can't learn all. Anyway, i would love to hear comments from you guys.

    Thanks.

  2. Josh on September 17, 2007 - 2:15pm
    First let me say that any of those solutions can be used to build an E-Commerce site. I'll take a moment to comment on each:

    PHP-Nuke: A good system that is mature. However, writing modules for it is not always easy. I've not done much beyond pretty standard systems with PHP-Nuke (and its cousins), so there may even be an E-Commerce module available for it.

    Joomla: I've worked quite a bit with Joomla. As a CMS, I like it... but as an application platform, the new version of Joomla will make a much better environment -- but I've not worked with the new version myself.

    Drupal: Drupal is very much a powerful CMS and an excellent way to deliver an application. There are a lot of tools and documentation on how to do this -- I've often considered writing applications based on Drupal myself.

    CakePHP: Understand that CakePHP is a framework, not a CMS in itself. While CMS software often provides a sort of framework as well, with Cake you will be writing your interfaces and back end logic mostly from the ground up, albeit more quickly (once you learn Cake) and with better programming practices (as long as you follow Cake conventions). Personally, I use Cake inside of Drupal using Drake.

    So you see, you could use any of the above... but I would personally not make PHP-Nuke or Joomla my first choice. CakePHP is my framework of choice, and Drupal is my CMS of choice -- and together, they make a lovely pair. Drupal even has an E-Commerce module available for it (though it's not a one-size-fits-all ordeal... you've been warned).

    I like to encourage people not to reinvent the wheel, but sometimes it really is better to write an application from the ground up. Be sure to plan things well and do your homework before you start laying down code!
  3. Conficio (not verified) on October 5, 2007 - 4:17pm

    If you want to build a typical e-commerce site some sort of catalog, think of OSCommerce the most mature catalog content management and also in PHP.

    You should easily be able to combine that with some of the more popular CMS systems. I know there are many pieces available for Joomla to show most popular products or specials of the month from OSCommerce in the CMS.

    K<o>

  4. EWoods (not verified) on February 10, 2008 - 8:50pm

    www.magentocommerce.com looks great. Not quite at 1.0, but due by end of March. I would call it the heir apparent to osCommerce for PHP-based commerce. But if you already have Drupal installed, the ecommerce module is worth a try.

  5. Tom (not verified) on February 14, 2008 - 11:12pm

    Unfortunately Drupal isn't really a "framework" ... at least no more than Joomla! or Wordpress. It has a paradigm, it has rules...but it's not anywhere near the same as something like CakePHP or Zend or Symfony.

    I know under wikipedia it's somehow listed as a framework - but that's incorrect and I believe a marketing ploy by some Drupal fan.

    Drupal in it's own right is good. It's very fast and good for blogging and such. If you keep it under control it's a great CMS.

    However, if you REALLY need the flexibility, scalability, development speed, and efficiency for something that is more complex...you really need to turn to CakePHP or something.

    You need to know the requirements of your project up front and really choose the best solution. In many cases, I've found making your own CMS or eCommerce solution from scratch with something like CakePHP is actually FASTER than modifying and hacking a pre-existing solution like Drupal or eCommerce. Again, this depends on the scope of the project...but I think the biggest mistake people make is not being able to see all the subtle differences and make the proper decisions for the project.

    If you take several hours just to brain storm and check out various options...it could save you a TON of time in the end.

    Now the other really cool thing about CakePHP (aside from development speed) is the fact that it actually can live and work with things like Drupal, Joomla, Wordpress, phpBB, etc. Very cool.

  6. Richard Bottoms (not verified) on December 10, 2009 - 6:10pm

    Could you compare and contrast WordPress/Cake vs. Drupal/Cake?

  7. Josh on December 10, 2009 - 10:53pm

    I'd see housing a cake app inside either as a similar scenario. WordPress and Drupal are both web applications, and Cake is a framework for applications. This was essentially a means of plugging in a bit of Cake in the context of Drupal -- I suppose something similar could be done with WordPress with similar results. I wouldn't claim one is superior to the other.

  8. Post new comment

    The content of this field is kept private and will not be shown publicly.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <blockquote>
    • Lines and paragraphs break automatically.
    • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <geshi>, <bash>, <c>, <cpp>, <csharp>, <css>, <drupal5>, <drupal6>, <html>, <js>, <mysql>, <php>, <python>, <rails>, <ruby>, <sql>, <text>, <mssql>, <xml>. Beside the tag style "<foo>" it is also possible to use "[foo]". PHP source code can also be enclosed in <?php ... ?> or <% ... %>.

    More information about formatting options