Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'll admit right away I'm a big fan of Drupal and I have never used Kohana, so this post will be one-sided. </p> <p>In the company I work for they use Drupal or Zend Framework for pretty much all projects (Drupal being in the majority). Many ZF-oriented people dislike Drupal as it's structure is so far from the object oriented ZF-stuff, and Drupal is "just an CMS". As I see it Drupal is more of a Framework than "just" a CMS, and the best part being that it is incredibly flexible: everything is possible. </p> <p>And yes there is indeed a module for everything. To be more specific:</p> <blockquote> <p>On the other hand, based on my limited Drupal experience, I doubt building rapid custom >"features" and allowing users to create "groups" and to manage their own roles within >those groups is something Drupal can easily accomplish.</p> </blockquote> <p>I can only guess what you mean with rapid custom features, but imo it's easy to expand Drupal with your own modules. Most features are available as (free, community contributed) modules, and many advanced looking features can be easily created for example with the "views" and "cck"-modules. <a href="http://drupal.org/project/cck" rel="nofollow noreferrer">http://drupal.org/project/cck</a> <a href="http://drupal.org/project/views" rel="nofollow noreferrer">http://drupal.org/project/views</a></p> <p>Creating groups: "organic_groups" ( <a href="http://drupal.org/project/og" rel="nofollow noreferrer">http://drupal.org/project/og</a>)<br> "og_user_roles" ( <a href="http://drupal.org/project/og_user_roles" rel="nofollow noreferrer">http://drupal.org/project/og_user_roles</a> )</p> <p>These modules together are what you need to create groups that have group spefic roles (and roles having specific rights). There are probably other ways than using "og_user_roles", but I'm advertising it because I've made a few patches for it a few years ago. The problem is usually a bit too many options. </p> <p>If you want to extend group specific options you could code your own module, but most likely you don't need to because there already is a module for it. For example, there are at least 120 modules that integrate somehow with the "organic_groups"-module: <a href="http://drupal.org/taxonomy/term/90?page=19" rel="nofollow noreferrer">http://drupal.org/taxonomy/term/90?page=19</a></p> <blockquote> <p>To simplify, is Drupal capable of true Web Applications; where the application is a >service and provides custom results to each user? Can it provide a dashboard-like >interface for users to change their settings or preferences? Can it aggregate data from >particular users to provide better results/info to others?</p> </blockquote> <p>In short, yes. There are so many ways to achieve something you described. But probably they would involve at least the excellent "views"-module. I think of views as some kind of ultimate abstraction SQL layer and UI for anyone. And there are over 300 modules that somehow integrate with Views... ( <a href="http://drupal.org/taxonomy/term/89?page=55" rel="nofollow noreferrer">http://drupal.org/taxonomy/term/89?page=55</a> )</p> <p>This sounds that Drupal is all about the modules.. and I know some of my collegues even dislike it for that, because you never get to code fun stuff because it's already been done. At least you can look at the module code and learn from that. Or laugh at it, there's lots of badly programmed modules around too.</p> <p>When you get to coding modules, you'll probably need lots of time to get used to the Drupal API, Forms API, Module hooks, the Theme override system, and the endless options from contrib modules. But it's worth the trouble.</p> <p>I find this site very usefull to find a module for some specific need. The site shows the same module info as Drupal.org, but also user feedback/ratings, to find the best option: <a href="http://drupalmodules.com/" rel="nofollow noreferrer">http://drupalmodules.com/</a></p> <p>If it's unclear, my answer would be go with Drupal :)</p> <p>PS: D7 should be out very soon. Some might wait for it instead of starting with D6. During D5 people would wait a long time before upgrading to D6 because of missing modules. I believe for D7 the most important modules will be available for D7 very fast. Some research at the moment (04.12.2010):</p> <p>About 190 modules promise to have a Drupal 7 version the day D7 is released: <a href="http://drupal.org/project/modules?solrsort=sort_title%20asc&amp;text=d7cx&amp;display=table" rel="nofollow noreferrer">http://drupal.org/project/modules?solrsort=sort_title%20asc&amp;text=d7cx&amp;display=table</a></p> <p>About 130 modules are already available for D7 (most are included in the previous link): <a href="http://drupal.org/project/modules?filters=drupal_core:103&amp;solrsort=sort_title%20asc&amp;text=d7cx&amp;display=table" rel="nofollow noreferrer">http://drupal.org/project/modules?filters=drupal_core:103&amp;solrsort=sort_title%20asc&amp;text=d7cx&amp;display=table</a></p> <p>EDIT: As a newbie I'm only allowed to post one link, so, I removed http:// from the drupal.org-links</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COI have to admit the link about "organic groups" is compelling. But I also wonder if there is a severe impact with Drupal module's running out-of-date when drupal core upgrades, leaving "custom" fixes incompatible with upgrades.
      singulars
    2. COPatching can cause problems yes, and most feature-rich Drupal projects tend to need a patch or two. However, you most likely will never have to patch the core modules (than come with the D6.x installation). While using the previous Drupal 5-version I sometimes even had to patch core (a big no-no) to get through some issues. But D6 is more evolved and so extensible and thus I haven't had to hack any core module ever after D5, in over a dozen D6 projects. Minor core version upgrades, like 6.15 -> 6.16 are smooth: they're just bug/security fixes and modules still work. However...[text limit]
      singulars
    3. CO... Major releases like 5->6 are however not compatible: all modules need an upgrade-version, and sometimes there is none (or you have to switch to an alternative). Patched modules will need to be re-patched. The upgrade used to be a pain in the ass, for example one D4 to D5 upgrade took me months of planning (a popular site that was live, and I was Drupal-noob back then.. excuses). But that was because it had lots of custom modules and patches. And Drupal wasn't as popular back then (less modules). D5->D6 upgrade is very easy compared to that, and D6->D7 should be even easier. [text limit]
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload