TOP 20 DRUPAL MISTAKES NEWBIES MAKE

Iztok Smolič, Drupal Camp London, Mar 2013

Thursday, August 29, 13

WHO IS

• Web architect, Drupal site builder, themer

• Drupal consultant (iztoksmolic.com)

• Drupal studio owner (agiledrop.com)

• Local meetups organizer, Drupal evangelist,Drupal Slovenia Association

Thursday, August 29, 13

THE COUNTDOWN

Thursday, August 29, 13

20. NOT ATTENDING YOUR NEAREST DRUPAL CAMPS

• I find hard to trust developers/themers that are not active in Drupal community

• Find local user groups, attend meetups

• Attend camp and conferences world wide

• Engaging on groups.drupal.org or drupal.org/forum

• Just putting your self into your work I guess

Thursday, August 29, 13

19. TRYING TO BEND DRUPAL TO BEHAVE LIKE...

• Can we make it work/look/behave like Joomla, Wordpress, Typo3 etc.

Thursday, August 29, 13

18. BAD CONTENT ARCHITECTURE DECISIONS

• Using too much content types(e.g. is Article really so different from Public release? Maybe we can use category to separate them?)

• Not using content types(e.g. instead of listing staff as a table in a page’s body, better to build the page with Views and list content type Staff member)

• Not using Taxonomy, Organic Groups, Entity Reference to link together entities.

• Be consistent - have a concept that does not duplicate your code. No real formula, just practice and experiences.

Thursday, August 29, 13

17. NOT KNOWING THE FURNITURE

• Designers, architects should be aware of common elements

• Check blog post from Chapter Three:http://tinyurl.com/yape9rb

Thursday, August 29, 13

16. TARGETING TOO SPECIFIC CLASSES AND IDS

• Drupal outputs a LOT of markup with specific HTML classes and ids. Knowing which class is appropriate to target is the key.

• IDs are usually unique identifiers for blocks/nodes/views. Avoid using IDs in CSS.

• Views have classes with view name and display name separated. Can be used to reuse CSS code.

• .items-list, .content, .view-content etc. are used all over your Drupal site, be careful targeting those classes.

Thursday, August 29, 13

15. NOT FAMILIAR WITH DEBUGGING TOOLS• When you would usually use

print_r() to get the content of a array or object to your browser, Drupal has Devel (http://drupal.org/project/devel):

• dpm($variable) – prints content of variable in human friendly way

• You can also store info to a log: http://drupal.org/project/object_log

• Can’t find the right template? Use Devel Themer (http://drupal.org/project/devel_themer)

Thursday, August 29, 13

14. ORPHANED MODULES• Clean your environment, or even better, test modules on other

installations!

• Leaving old, unused modules can confuse you latter on, not to mention how confused other developers can get.

Thursday, August 29, 13

13. FORGETTING ABOUT BACK-END UX

• Drupal is criticized for having a bad user experience for end users. Don’t blame Dries, its your fault!

• Drupal is a framework, back end should be part of developer’s efforts when building a website.

Thursday, August 29, 13

12. NOT KEEPING TRACK OF DRUPAL DEVELOPMENT

• Know when the next version of core/module is crucial for god strategic decisions.

• Keep track of interesting / new modules:

• Lullabot Module Monday

• theweeklydrop.com

• http://drupal.org/project/modules

• twitter: @alldrupal

Thursday, August 29, 13

11. USING DEFAULT BLOCK SYSTEM

• Use default blocks system only if project is very very simple.

• A couple of alternatives were made to improve block system, I bet on the following two:

• Context, which is block system on steroids

• Panels, introduces new block-like concept

Thursday, August 29, 13

10. CODING SPECIFIC PAGE TEMPLATES FOR EACH SUB-PAGE

• Try to omit page--xxx.tpl.php templates. It duplicates the code, and makes maintenance difficult.

• Try using Context Layout or Panels if variations of markup are needed.

Panels have a drag’n’drop interface that can replace coding own page.tpl-s

Thursday, August 29, 13

9. NOT RESPECTING THE CODING STANDARDS

• Different approaches and coding styles make code less organized and makes the job for other developers more difficult.

• two spaces indentation

• $var = foo($bar, $baz, $quux);

• $some_array = array('hello', 'world', 'foo' => 'bar');

• <?php print $title; ?>

• http://drupal.org/coding-standards

Thursday, August 29, 13

8. NOT USING DRUPAL API

• Drupal comes with some very handy functions, we should use them

• l() and url() - in contrast of hardcoded relative URL address can outputs aliased URL path

• base_path(), returns base URL of the Drupal installation

• theme() functions

Thursday, August 29, 13

7. CHOOSING LESS OR UNSUPPORTED MODULES

• Check the usage/download counter, last update, open issues counter, all that can give a idea about the module status.

• Read the description, in many cases authors let the people know that module will be deprecated in favor of some other more comprehensive module.

Thursday, August 29, 13

6. WRONG FOLDER STRUCTURE

• If using single site installation (one Drupal core, one website) put:

• themes in /sites/default/themes

• modules from drupal.org in /sites/default/modules/contrib

• custom modules in /sites/default/modules/custom

• Do not put themes and modules in the folder on the root level. Never. You can use “all” folder instead of “default” – your call.

• More about this: http://drupal.org/node/120641

Thursday, August 29, 13

5. PUTTING LOGIC IN TEMPLATE FILES

• SQL queries and logical operations don't belong in the template layer.

• Basic logic code can be placed in the preprocess function in template.php file.

• About process & preprocess: http://drupal.org/node/223430

Thursday, August 29, 13

4. FORGETTING ABOUT YOUR DRUPAL WEBSITE• Drupal needs love even

after you have finished your website. Keeping core and modules updates keeps the system safe and easier to upgrade with new features.

Real time example:47 of 63 modules need update

Thursday, August 29, 13

3. CODING

• There is a 80% possibility that what you want to build can be build with a combination of modules.

• Usual suspects:

• Queries: Views

• Bulk operating on content/users: views_bulk_operations

• Trigger based operations: Rules

• Advance structure, variants: Panels

• Advance field/multifield structure: Field collection

Thursday, August 29, 13

2. PUTTING CONTENT / PHP CODE IN BLOCKS

• Default blocks allow user generated content, but you can't set permissions for editing each blocks

• Bean, you can add fields to different blocks types, which have separate permissions (like content types do)

• Boxes, blocks with a unique machine names

Thursday, August 29, 13

1. HACKING CONTRIBUTED AND CORE CODE

• If you decided to use a theme from core or from drupal.org, there is no need to go and edit its code. Make a sub-theme

• more about creating sub-theme: http://drupal.org/node/225125

Thursday, August 29, 13

1. HACKING CONTRIBUTED AND CORE CODE

• Fixing code directly in the module files makes the website impossible to update. Instead Drupal provides hooks and preprocess functions which can alter functionality/data without breaking the original code.

• More about hooks:http://api.drupal.org/api/drupal/includes!module.inc/group/hooks/7

Thursday, August 29, 13

13. - 14. April 2013, Ljubljana, Slovenia

www.DrupalAlpeAdria.org

International event with 150 attendees.25 sessions in English.

Affordable flights from London.Nice time of year to visit Ljubljana.Early birds price 15€ (t-shirt, lunch

follow: @dcAlpeAdria

Thursday, August 29, 13

Q / A

• Twitter: @iztok

• IRC: iztok

• Skype: iztok.smolic

• Email: iztok@agiledrop.com

Thursday, August 29, 13