Drupal Best Practices

531 views
389 views

Published on

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
531
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
14
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Drupal Best Practices

  1. 1. Best Practices for development & deployment More structured, more productive, more done! Somedutta Ghosh
  2. 2. Best practices in - ★ Drupal - security, structuring, custom coding, etc. ★ Git - Version control tool ★ Deployment method ★ Drush
  3. 3. Drupal Best Practices ● NEVER. HACK. CORE.
  4. 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. 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. 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. 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. 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. 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. 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. 11. Modules - contrib and custom ● Improve structuring - move modules to separate folders under sites/all/modules/ depending on custom, contrib, features or modified.
  12. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×