A few weeks ago, I decided that the best foundation for the site I'm working on would be Drupal. After some discussions around the scale of the site and the likely complexity of our customisations, this seemed to be the natural choice. One of the key factors in this decision was the perceived strength of Drupal's architecture. As a fairly seasoned developer, I want an architecture which enables me to customise existing functionality and develop new functionality in a consistent and predictable way, with consistent and predictable results.
My last project used OSCommerce as a foundation, and while I've been able to build a good (if fairly simple) e-commerce site with it, the architecture is somewhat inconsistent. Different parts of the system have varying coding styles and variable naming conventions (which isn't surprising, given it's open source roots), meaning that I have to adopt different coding styles and mindsets when debugging or enhancing different parts. Not insurmountable, but not a good foundation for great endeavours.
The other key reasons for choosing Drupal were
One of our requirements is to support multiple user types, each of which will have different attributes. A good analogy (although not an actual example) would be to have
My last project used OSCommerce as a foundation, and while I've been able to build a good (if fairly simple) e-commerce site with it, the architecture is somewhat inconsistent. Different parts of the system have varying coding styles and variable naming conventions (which isn't surprising, given it's open source roots), meaning that I have to adopt different coding styles and mindsets when debugging or enhancing different parts. Not insurmountable, but not a good foundation for great endeavours.
The other key reasons for choosing Drupal were
- product maturity
- rich third party module library
- very active developer community, including conferences
- large-scale implementations (like MTV UK)
- open source (i.e. debuggable, extensible, customisable and free!)
One of our requirements is to support multiple user types, each of which will have different attributes. A good analogy (although not an actual example) would be to have
- car drivers (who might want to add their car make and model to their profile)
- mechanics (who might want to add specialisms such as engine tuning to their profile)
- Advanced Profile requires Panels, CCK and Node Profile
- Node Profile requires Node Family and Subforms