webschuur.com

I thought it to be a good idea to sum up my vision of the ten biggest mistakes made by people new to Drupal. I encountered all these issues on several occasions, and have seen them pass by, in support threads, and so on. But that does not mean that you will run into them, still I think they are very recognisable for many amongst us. Many are not even specific to Drupal.
I’ve collected the notes and solutions from several mails and conversations, selected the ones I thought can do most harm and ordered them by overall weight:

1. Blindly trusting the description on a module page. Many people write a quote, RFC, etceteras without testing the modules in several environments, and even testing them all together. Module developers are not marketing guru’s or communication experts. They make a module for their own needs. My rule of thumb: a module I don’t know (yet) will cost me just as much time to develop from scratch, as I will cost me to get used to, to implement it, and to fit into my needs.
2. Going for an unstable module, or unstable core. Eventhough developers told you that a ‘release is around the corner’ or that ‘the current head is really stable’: if you need proven technology, use proven technology. A backport of some feature is often far less work then keeping up with all the progress, and dealing with all the uncertainty. Developers might think something is stable, but that is only because they are familiar with their work. A pilot will tell you that flying a plane is dead-easy. You know better. Or should.
3. Foobar inc. has a Drupal site, we need almost the same, Drupal is ready to let us build such a site. Off course not. If someone else did it, that does not mean You+Drupal+SomeDevelopment can do it too! Without knowing all the ins and outs of that foobar inc. project, consider your project as “needing to re-invent all the wheels”, consider it like you would when developing something that has never been done yet.
4. Assuming that a module fullfills your exact needs Out Of The Box. Even if you tried the module, your actual case might not be solved with the module. Changing something is often far from the trivial task you thought it to be.
5. Assuming contribs don’t come with extras. Many contribs have nice features and extras, or dependencies. Often that is stuff you don’t need or want. The larger the module, the bigger the chance it will not be what you want it to be out of the box. I have seen developers loose many valuable hours on removing stuff. Don’t just look at what you need, also look at what you don’t need.
6. Assuming a bug will be fixed because it is reported. Contributors are people. Just like you. If they don’t have an itch to fix a bug, it won’t be fixed.
7. Theming is simply ‘changing a few thingies to alter the look’. Theming is a complete development track. Even simply changing a few colors in an existing theme, if done right, can prove to become an endless project. My rule of thumb: I count two hours theming for every three hours spent on module and site development. And that is only possible because I know my way around in the themes and in CSS.
8. Translating is easy. For every word you know you have to translate, there are ten, twenty you did not think of. Translating an average site, when using contributed, almost finished PO files, will cost you days, if not more, and certainly not hours.
9. Knowing how to make a module means its nearly done. You will, so says Murphy, encouter things you never expected. The fact Drupal development is not very hard, the fact Drupals APIs are well documented, does not mean that the development of your specific ideas or needs are easy.
10. Mambo/Joomla!/RubyonRails/Any other platform CMS is not good because of Foo, Drupal has a good solution for Foo. Drupal is better for me. Sure, probably right. But does that mean that —in contrary to that other system— Drupal has Bar done right? you probably did not know about Bar because, where you come from, Bar was never an issue, in Drupal it may very well be your killer issue.
    The fact you did not read anything about these issues in Drupals handbooks does not mean Drupal is perfect. A perfect system is just that: perfect. It would therefore require no more development (it’s perfect, remember?). Wherever you see developers, you know you are dealing with a “thing” that needs improvement, a thing that is not perfect.

Did I miss any? did you run into the same, but had other solutions, or variations on a problem?