It’s commonly called “CMS” but as deeper you’re digging into it, it’s getting clear that it is something greater than the “Content Management System”. Or perhaps, that the “Content Management” is something greater than we used to think. Actually, Drupal’s darned flexibility allows to do a lot of things which would need the application servers and all that stuff. And in the simplest case, it will need no programming – you can build for instance, a simple database application (like a products directory etc) or even a light CRM/ERP for your intranet as just a specialized Drupal configuration.
There is a case study: our RUSMECO project, among many other things, includes development of so-called “Brokerage Area” – an open-access database of the people, organizations, products and services which are related together by many ways. Our main collaboration portal is based on Drupal so it was obvious that reusing the same platform for BA development advantages in all senses. We have investigating which Drupal features might fit our solution – and found all what we needed.
All content objects in Drupal are treated as an abstraction of the “nodes”. There are various types of nodes (pages, stories, forum posts, blog posts etc) which differ by their fields and provided by the core or additional modules. But there is also a mechanism of creating new custom types of nodes (so-called “flexinode”) with arbitrary sets of the data fields. So, you can define your own structured data types right into the Drupal administrative interface without writing any PHP code and creating new database tables. The user interface (the forms) for nodes will be built automatically and can be adjusted later (for instance, the fields order and grouping). These new types will be fully integrated into the core content framework – in fact, they will be the same content objects as the core types and all Drupal functions (the search, categorization, multilingual translation, workflow, access management and so on) will work with them.
In our case, we needed four content types: Member, Company, Product and Service profiles. It is only pity that the built-in system user profile is not a node (though it have a customizable set of the fields), so we left there only a bare minimum of fields (only username, email and password, in fact) and defined a separate Member profile (CV) node type for those who wants to tell more about herself.
Taxonomies (or, controlled vocabularies) is a standard Drupal way for nodes classification and organization. They are the sets of categories or terms which can be organized hierarchically, related each other and grouped into the vocabularies. Depending on your IA, they can serve as traditional content sections, the “tags” or “labels” in faceted classification system or as thesauri of interrelated terms. The categories can be also related with the content types, so that the nodes of a specific type can be qualified as the members by specific categories only, or be included in a category by default.
Along with predefined categories, it is possible to define new ones (in selected vocabularies) on-the-fly, together with creation of new nodes. For instance, an user who is filling her product profile out, is able to create the new product category at one time.
Our solution had to be bilingual (en/ru) – it was a principal requirement. It concerns not only an interface, but also that it should be possible to create the translations of the nodes in alternate language. For instance, an user should be able to create two versions of a profile and when another user coming to see it, she would get a variant for her current language (selected in the top panel).
The features of Drupal i18n module enable to do so. What’s more, it is possible also for categories to be translated, so that the user sees all categories in her current language and when she is in a category, all nodes there are in that language too.
And after all, if you’re well sure Drupal lacks some functionality, you can remember your own PHP and SQL experience and write some code. For instance, you would be needed for a custom sophisticated query iinterface for your database. But you probably will not have to write a lot – as all infrastructural aspects (such as templating etc) are already implemented in Drupal API, you’ll need to implement only your specific functions.
The specific pieces of Drupal functionality are called “the modules”. In fact, the Drupal core is only the component framework and almost all its functions are implemented as the pluggable modules. So, to extend it with your custom functions there is no a better way than develop your own module. It’s pretty easy – a module is simply a PHP file containing the conventionally named functions (aka “hooks”). These functions may define what should be displayed in a module page, module blocks (in left and right columns), module settings page, how the module will be integrated into the navigation menus and configuration interface and so on.
For to start with modules development, consider to read this tutorial.
Reading on subject
- Is Drupal right for you?
- Rolling your own system vs. using Drupal
- Drupal for Information Architects: an overview of configurability
- The Road to Drupal Hell
… more on the Drupal site.