Drupal Best Practices

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

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

Drupal Best Practices
● NEVER. HACK. CORE.

● 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

● 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.

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

● 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>

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.

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.

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_’

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

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

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.

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

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.

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

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.

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.

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

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.

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.

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

● 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

● 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

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

● 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

● 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

● 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/

● drush help - list of drush commands and their use; drush help [command]
gives more help information about a specific command

Drupal Best Practices

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Drupal Best Practices

Similar to Drupal Best Practices (20)

Recently uploaded

Recently uploaded (20)

Drupal Best Practices