Best practices in Drupal make individual developers more productive which makes the entire team more productive. This was presented by Somedutta Ghosh in Drupal Camp Kolkata. #drupalcampkolkata

1. Best Practices for
development & deployment
More structured, more productive, more
done!
Somedutta Ghosh

2. Best practices in -
★ Drupal - security, structuring, custom coding,
etc.
★ Git - Version control tool
★ Deployment method
★ Drush

3. Drupal Best Practices
● NEVER. HACK. CORE.

4. Drupal Best Practices
● No development on live.
● Disable development modules on production/live environment.
○ views_ui
○ field_ui
○ devel
● All drupal level logging should be on only on non-production
environments; only server level logging on live.
○ dblog off - syslog on

5. Drupal Best Practices
● Preferable to use server level logging instead of
drupal logging, as this will remove unnecessary
database writing for the application.
● Choosing Syslog over Drupal watchdog
● Enable logging of slow queries in mysql.

6. Drupal Best Practices
● Files and directory ownership and permissions,
○ group should include web server, and
○ only owner and group should be given permissions.

7. Drupal Best Practices
● JS, CSS should not be present in database (css inside the element
can be present as we could have with wysiwyg text editor)
○ no jss/css in node content
○ no jss/css in block content
<script type="text/javascript" >
jQuery(window).load(function() {
jQuery('.pics').cycle({
fx: 'scrollLeft',
next: '#right',
delay: 2000 ,
});
});
</script>
<style>
.pics {
width: 100%;
margin: 10px;
}
</style>

8. Writing Custom Code
● Add helpful documentations for
all modules. Always add a
README.txt file in all custom
modules.
● Add documentation for functions
and inline comments for
understanding the code.

9. Writing Custom Code
● Before writing custom, look for contrib.
● Make sure you use the extensive drupal API instead of
writing custom functions/code.
● Use drupal database API for making db calls.
● Use drupal form API for creating forms.
● Use theme functions like theme_image, theme_links
instead of writing raw html.
● To show any text always use the t() function.
● For creating links always use l() function instead of a tags.

10. Writing Custom Code
● Try to avoid writing functionality related code in theme.
● Follow naming conventions for easier management.
● all features can be prepended by ‘feature_’
● all custom modules and theme can be prepended by the
initials of the sitename. eg. for site ‘Alpha’ use ‘a_’ or
‘alpha_’

11. Modules - contrib and custom
● Improve structuring - move modules to separate folders
under sites/all/modules/ depending on custom, contrib,
features or modified.

12. Modules - contrib and custom
● Often we need to apply patches or modify contrib
modules. In such a case,
○ create another folder under modules - patches
○ store all applied patch inside this
○ keep a README.txt file in /patch folder to record
patches applied, the module they were applied on and
their purpose
○ when modifying modules, create a patch from them
and treat those patches same as other patches

13. Make your modules Modular!
● Separate functionalities should go into separate modules.
● Use small functions, where each function performs a
specific part of a big functionality. Try making these
functions as general as possible and use arguments
instead of hardcoding, such that they can be used multiple
times and with different data.
● For long and heavy operations, use batch process.

14. Custom modules
● Use the theme layer for printing HTML. Use tpl files for
large amounts of HTML code. Small html code could go into
non-tpm files like .module files.
● CSS/JS for specific pages should not be added on every
page
○ if adding css/js to every page through hook init move
them to theme’s info file
○ add these files through page callbacks

15. Theme
● PHP should be present in tpl files for either conditions or
printing variables; all calculations should be done in template.
php file.
● CSS/JS should not be present in template.php; add them
through files and included via theme’s info file.

16. Git Best Practices
Essential to use version control. The greatest plus points of git
are -
● branching - multiple functionalities can be kept separate
● distributed - multiple developers can work on the same
codebase at the same time, and git smoothly merges the
code
● different versions of the same file - with extensive options
of viewing log of changes, one can see when a file or a line
of code was added

17. Git Best Practices
● Keep individual functionalities in individual branches
● When on a feature branch, merge with the base branch often
● Branch out from development branch for new functionality.
● Branch out from master(production) branch for production bug
fixes.

18. Git Best Practices
● Have intuitive branch names - eg. each
feature/functionality branch prepended with feat_ or each
bugfix branch prepended with bugfix_
● production, stage, dev - different instances in the
development tree - deploy a different branch on each
instance - master, stage, dev respectively.

19. Git Best Practices
● Commit early. Commit often.
● Commit messages should be useful, insightful and
descriptive
● Make a habit of git commit instead of git commit -m
“[message]”. This opens an editor where you can write a
more descriptive commit message
● Set up a .gitignore file - to exclude configuration files that
are server environment dependent and large binary files
● Do not add settings.php and files folder in git repository
● After completing a feature from local to production, delete the

20. Deployment Best Practices
● 3 environments should be used - production, staging and
development.
● dev - any new code is first deployed and tested here. work from all
developers will be tested here
● stage/test - the content will be same as the live instance and
updated code from dev will be tested here
● production/live - it is the live instance. New code/functionality after
passing tests on the stage environment, can be moved to live.

21. Deployment Best Practices
● All changes should always go through dev and staging
before production so that the changes can be extensively
tested.
● Version control tool should be used since it makes moving
code between environments very easy and especially
useful when multiple people are working on the same code.
● Use features and strongarm to move database changes
between environments - reduces configuration times on
different environments.

22. Drush - do less, get more
● drush cc all - clear all cache
● drush dl [project_name] - download modules
● drush en -y [project_name] - enable modules
● drush dis -y [project_name] - disable modules
● drush pm-uninstall -y [project_name] - uninstalll modules
● drush pm-list - show list of modules with their status, enabled,
disabled, not installed

23. Drush - do less, get more
● drush fl - to list all features and show their state, overridden or not
● drush fd [feature_name] - show overrides in feature; you will need
module diff for using this command
● drush fu -y [feature_name] - updates the feature(db to code)
● drush fr -y [feature_name] - reverts the feature(code to db)
● creating feature using drush
○ drush fe [feature-name] [feature-component(s)] - export/create or
update a feature with one or more components
○ drush fc - show a list of feature components that can be exported
into features

24. Drush - do less, get more
● drush updb - running update.php from drush
● drush cron - run cron from drush
● drush ws - show list of latest 10(default count, can be increased with
option in command) messages messages
● drush upwd - Reset the password for an user account that has the
given username(username to be specified in command)
● drush sqlq “[sql-query]” - run any db query from drush
● drush sql-dump - take a sql dump of the current site’s database

25. Drush - do less, get more
Drush alias -
● an alias is basically a short name for a drupal installation. It is a set
of options that collectively define that installation.
● its biggest advantage is super easy syncing with remote servers and
running drush commands on remote servers locally

26. Drush - do less, get more
● create a drush alias file - sitename.alias.drushrc.php, eg alpha.alias.
drushrc.php
● place it in either of -
○ ~/.drush
○ sites/all/drush
● the simplest content of an alias file could be
<?php
$aliases[local] = array(
'root' => '/var/www/alpha'
);
● now you can access your local environment for drush through -
drush @alpha.local status

27. Drush - do less, get more
● for adding a remote configuration, eg. dev on a remote server, add
following to above alias file
$aliases[dev] = array(
'root' => '/home/alpha/public_html',
'remote-host' => 'alpha.dev.com',
'remote-user' => alpha',
);
● if ssh requires password authentication, add this to alias config of the
remote - 'ssh-options' => '-o PasswordAuthentication=yes' - this will
prompt for password every time you use drush with the remote’s
alias

28. Drush - do less, get more
● we now have 2 aliases for the site alpha
* drush @alpha.local * drush @alpha.dev
● syncing local database with remote with single command
○ drush sql-sync [source] [destination]
○ drush sql-sync @alpha.dev@alpha.local
● syncing local files folder with remote with single command and
drush alias
○ drush rsync [source]:sites/default/files/ [destination]:
sites/default/files/
○ drush rsync @alpha.dev:sites/default/files/ @alpha.local:
sites/default/files/

29. Drush - do less, get more
● drush help - list of drush commands and their use; drush help [command]
gives more help information about a specific command