Video: http://www.youtube.com/watch?v=8ocFBRpoGTs
Working as a Drupal theming/development consultant on many "rescue mission" projects I seen many different mistakes web developers do when facing with Drupal for the first time. This presentations points out those mistakes and gives solutions for them.
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Top 20 Drupal Mistakes newbies make
1. TOP 20 DRUPAL MISTAKES
NEWBIES MAKE
Iztok Smolič, Drupal Camp London, Mar 2013
Thursday, August 29, 13
2. 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
4. 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
5. 19. TRYING TO BEND
DRUPAL TO BEHAVE LIKE...
• Can we make it work/look/behave like Joomla,
Wordpress, Typo3 etc.
Thursday, August 29, 13
6. 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
7. 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
8. 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
9. 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
10. 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
11. 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. 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
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
14. 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
15. 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
16. 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
17. 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
18. 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
19. 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
20. 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
21. 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
22. 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
23. 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
24. 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
25. 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
26. Q / A
• Twitter: @iztok
• IRC: iztok
• Skype: iztok.smolic
• Email: iztok@agiledrop.com
Thursday, August 29, 13