We all use Drupal, build with it, code for it, sometimes even code it. But what is Drupal, really? What gives it its distinct identity? This page tries to gather the defining choices the project team has been focusing on over the course of years.
[Editor's note: If this is going to go into the Handbook, it needs more editing. See the style guide at http://drupal.org/node/338208 ]
Community experience
- The people on IRC channels #drupal, #drupal-contribute, and topical/regional channels
- Twice-yearly DrupalCons, which are the premiere community events, with one in North America every spring, and another in Europe every fall
- Regional Drupal camps, conferences, summits, and organized sprints
- Smaller regional Drupal groups (http://groups.drupal.org/), many with regular meetings and informal events
Drupal developer experience
- The hook mechanism. Refined from its inception to the generalizing categories of accumulators (hooks invokable via module_invoke_all) and alterators (hook_*_alter) while still retaining some of the early/historical pseudo-hooks (hook_insert/update/delete…)
- The theme() mechanism, with its overrides, theme functions, and templates
- Render arrays, with their properties (#) and elements (no #)
- The menu system with object loaders, as opposed to a list of regular expressions à la Django
- Replacing basic PHP practices (forms, superglobals, sessions…) with the Drupal API
- Refusal to give in to MVC just for the benefit of practitioners with more academic training than actual experience
- Storage
- No ORM, but DB API virtualization
- SQL mandatory (until D7), NoSQL available (D6 and later) in addition to SQL
- File management
- No mandatory content relationships (like Chapter/Section/page)
- Taxonomy: flat content space, made multidimensional from adding as many dimensions of analysis as one wants
- 9-level deep book structure
- Content (until D6)
- Everything rich is either a node, comment, or user account (until D6)
- Every piece of rich content has a unique owner [Editor note: really? It has a creator, but the permission system is a lot more flexible than "a unique owner"]
- Fieldable nodes (CCK) and accounts (Profile)
- Terms and vocabularies are plain text
- Content (D7 and later)
- Everything is a fieldable entity
- Yes, even fields, although it may not be implemented yet
- Including user accounts
- Simpletest testing framework
- http://api.drupal.org: an always-up-to-date public API reference for anyone to use without having to set it up on their server
Front-end developers experience
- Multiple themes
- Hierarchical templates
- No custom templating language to learn, just PHP/HTML/CSS
- RTL support
- Presupposed XHTML (until D7)
- Blue :-)
Site admin experience
- Online configuration, without a separate command line interface (CLI) installer/manager (à la Django or Rails)
- Drush as a CLI for actual use of the CMS instead of being just a builder tools like the Rails/Django scripts
- Themable and extensible query/report builder (Views)
- IRC #drupal-support: possibly the single most important site administrator feature
- Flexible permission system
Historical note: this derives from a discussion at DC Copenhagen about "what would be Drupal like if it had not been coded in PHP, but Ruby or Python?"
This is a wiki page, so if you feel I have missed something, feel free to edit it.