Drupal Best Practices
-
Upload
mukesh-agarwal -
Category
Technology
-
view
140 -
download
0
description
Transcript of 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.
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
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.
Drupal Best Practices● Files and directory ownership and permissions,
○ group should include web server, and ○ only owner and group should be given permissions.
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>
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 PracticesEssential 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
branch
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 - 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
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
Drush - do less, get moreDrush 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
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
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
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 @[email protected]
● 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 - do less, get more
● drush help - list of drush commands and their use; drush help [command] gives more help information about a specific command