4 ms·

Yes Drupal is not for creating custom apps, but it is not really that bad, for specific systems (ex: where you have anonymous traffic) or publishing systems, Dr

by level09 14y ago

Yes Drupal is not for creating custom apps, but it is not really that bad, for specific systems (ex: where you have anonymous traffic) or publishing systems, Drupal really excels. the huge amount of queries (200+) executed on each request can be easily cached and scaled using a bunch of layers (APC,static files, varnish) and it scales very well. on the other hand, if you try to build the CMS features you get (out of the box) in other framework like Django or rails, it will take you really a longer period of time.

donw 14y ago
I can speak from some experience here, as a few years ago I led a team in moving a client's custom-built application off of Drupal. You could probably set up a blog and a storefront easily within a day, and then hand that off to a non-technical client with a very limited budget. Outside of that use case, you're better off using something else, for several reasons: Configuration is entirely stored in the database, which means setting up multiple environments for testing changes is effectively impossible. You also have no real way to use source control to track changes in your configuration. The Drupal database schema is surprisingly hard to extract data out of, which means transitioning to another CMS, or to a custom-written app, is also very difficult. Bugs are nasty, many, and often undocumented. In our case, we got bitten by a nasty bug regarding null fields when exporting XML -- it simply kept the last non-null value. Which was pretty problematic when that altered the nature of purchased items for thousands of customers (that was fun to fix). This also makes transitioning data very difficult. Drupal module behavior is highly non-deterministic; you can add hooks in to, say, modify SQL queries before they get to the database, with no logging or other indication that this is happening. Debugging interactions between modules is very unpleasant. There is no backwards compatibility between releases, which makes upgrading incredibly painful, especially if you depend on custom modules.
- fungi 14y ago
  > Configuration is entirely stored in the database that is generally what the features module is used for http://drupal.org/project/features http://drupal.org/project/features > which makes upgrading incredibly painful yup, this is a real problem with small community sites that drupal is other wiser awesome for. the work involved can be rather arduous (and impossible if you are using a module that lacks an upgrade path). that said, the drupal community is huge and in my 8+ years of building and running sites i have always been able to work out an upgrade solution, finding the time to implement it is the bigger problem.
  - hilko 14y ago
    Last I used it, there was still too much that the Features module didn't 'cover', making it less useful and sometimes even counter-productive for me. Has this improved greatly in the past year?
    - mfer 14y ago
      Configuration management can be a real issue. For Drupal 8 there is the Configuration Management Initiative meant to solve just this problem. It will be there in Drupal 8. Features has some very rough edges. It's a bolt on after the fact solution. Through it Drupal developers learned about the rough edges, what people want here, and so forth. What comes in Drupal 8 is meant to be a proper solution at the core from experience.
      - hilko 14y ago
        Yeah, I read about that. Could definitely influence my choice of framework/CMS down the line!
- jasey 14y ago
  Having just migrated a big Drupal 6 site I attest that the Drupal db schema is really quite complex. Also one of the project advisers has also said that going between different versions of Drupal is comparitable with going to a totally new Cms (meaning its no simple task).

by level09 14y ago

donw 14y ago

I can speak from some experience here, as a few years ago I led a team in moving a client's custom-built application off of Drupal. You could probably set up a blog and a storefront easily within a day, and then hand that off to a non-technical client with a very limited budget. Outside of that use case, you're better off using something else, for several reasons: Configuration is entirely stored in the database, which means setting up multiple environments for testing changes is effectively impossible. You also have no real way to use source control to track changes in your configuration. The Drupal database schema is surprisingly hard to extract data out of, which means transitioning to another CMS, or to a custom-written app, is also very difficult. Bugs are nasty, many, and often undocumented. In our case, we got bitten by a nasty bug regarding null fields when exporting XML -- it simply kept the last non-null value. Which was pretty problematic when that altered the nature of purchased items for thousands of customers (that was fun to fix). This also makes transitioning data very difficult. Drupal module behavior is highly non-deterministic; you can add hooks in to, say, modify SQL queries before they get to the database, with no logging or other indication that this is happening. Debugging interactions between modules is very unpleasant. There is no backwards compatibility between releases, which makes upgrading incredibly painful, especially if you depend on custom modules.

fungi 14y ago
> Configuration is entirely stored in the database that is generally what the features module is used for http://drupal.org/project/features http://drupal.org/project/features > which makes upgrading incredibly painful yup, this is a real problem with small community sites that drupal is other wiser awesome for. the work involved can be rather arduous (and impossible if you are using a module that lacks an upgrade path). that said, the drupal community is huge and in my 8+ years of building and running sites i have always been able to work out an upgrade solution, finding the time to implement it is the bigger problem.
- hilko 14y ago
  Last I used it, there was still too much that the Features module didn't 'cover', making it less useful and sometimes even counter-productive for me. Has this improved greatly in the past year?
  - mfer 14y ago
    Configuration management can be a real issue. For Drupal 8 there is the Configuration Management Initiative meant to solve just this problem. It will be there in Drupal 8. Features has some very rough edges. It's a bolt on after the fact solution. Through it Drupal developers learned about the rough edges, what people want here, and so forth. What comes in Drupal 8 is meant to be a proper solution at the core from experience.
    - hilko 14y ago
      Yeah, I read about that. Could definitely influence my choice of framework/CMS down the line!
jasey 14y ago
Having just migrated a big Drupal 6 site I attest that the Drupal db schema is really quite complex. Also one of the project advisers has also said that going between different versions of Drupal is comparitable with going to a totally new Cms (meaning its no simple task).