Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Flcamp2015 - R.E.A.D: Four steps for selecting the right modules

288 views

Published on

One of the most crucial and important steps in building any Drupal project is determing which modules to use. When you are reviewing your functionality needs you may ask yourself:

Where and how can I find the modules I need?
Will this module I found solve my functionality needs?
Will I need to patch this module?
Should I just write my own custom module?
To quickly and correctly answer these questions, there are four simple steps you should follow. It's as simple as learning how to R.E.A.D.

This session goes over the four steps of R.E.A.D, which can help you to quickly and correctly identify which module fits your functionality needs, if you should patch a contrib module or if you should write your own custom module.

This session will use real world examples of using the steps of R.E.A.D to make module decisions. We will also cover the basics and best practices of writing patches and custom modules and how to contribute them back to the Drupal community.

This session is geared towrds developer, site builders and functionality decision makers who consider themselves new to Drupal. This session can also prove to be beneficial to experienced drupalists who want to validate/improve habits they have developed.

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Flcamp2015 - R.E.A.D: Four steps for selecting the right modules

  1. 1. R.E.A.D How to select the right modules https://2015.midcamp.org/node/1106 Florida Drupal Camp 2015 #fldc15
  2. 2. Who You Are New to Drupal. Want to improve habits. Session curious.
  3. 3. Your Role A Drupal developer. A site architect. Functionality decision maker.
  4. 4. What it is all About How to quickly make smart, informed functionality decisions.
  5. 5. What we will Cover Steps to decide between a contrib, patched or custom module. Real world examples of R.E.AD Basics of a patch & Basics of a custom module.
  6. 6. Michael Miles From: Boston, MA Work:   @WeAreGenuine(.com)Genuine Exp: Working with Drupal since 2008. Recently named an Acquia M.V.P Twitter: @mikemiles86 Drupal.org: mikemiles86  All the Places: mikemiles86
  7. 7. R.E.A.D Research what exists. Evaluate the options. Analyze the gap. Determine amount of change.
  8. 8. Research What Exists
  9. 9. Isolate Keywords Read documentation, specs, etc... Pay attention to unique nouns and verbs. Ask questions!
  10. 10. Perform Searches 30k+ Modules available. Favorite search engine "Drupal [keyword]". Search on Drupal.org
  11. 11. Utilize the Community Use IRC: #drupal, #drupal­support. Use Stack Exchange:  . Social Networks: G+, Facebook, LinkedIn. Even reddit!  . drupal.stackexchange.com reddit.com/r/drupal
  12. 12. Isolate Keywords. Perform Searches. Utilize Community.
  13. 13. Evaluate the Options
  14. 14. Read the Description What does the module do? What does the module not do? What does the module depend on?
  15. 15. Community Adoption Downloads vs. Installs vs. Age. Activity of issue queue. Issues are good, not bad!
  16. 16. Maintainer Activity Participate in issue queue? Accepting of feedback? Regular commits and/or releases?
  17. 17. Read the description. Check community adoption. Check maintainer activity.
  18. 18. Analyze the Gap
  19. 19. Download and Test the Module Gain a better understanding. Use a sandbox:  . What is offered out of the box? simplytest.me
  20. 20. Discover Missing Functionality What does it not do? Missing 80%? Missing 20%? Bigger gap = Bigger effort.
  21. 21. Check for Community Solutions Look at the issue queue. Search "Drupal [module] [functionality]". Ask questions!
  22. 22. Download and test the module. Discover missing functionality. Check for comunity solutions.
  23. 23. Determine Change
  24. 24. Review the Module Code Does it follow coding standards? Is it extendable? Can you figure out what does what?
  25. 25. Estimate Effort How much code to rewrite? How much code to add? How much time is there?
  26. 26. Extend or Alter Adding functionality? Changing functionality? Changing the modules goal?
  27. 27. Review module code. Estimate effort. Extend or alter?
  28. 28. Examples
  29. 29. Scenario #1
  30. 30. The Requirements WHEN SAVING A FILE ENTITY AND IT IS A JPEG IMAGE THEN THE EXIF META DATA NEEDS TO BE CAPTURED AND MAPPED TO CUSTOM FIELDS AND THESE MAPPINGS NEED TO BE EXPORTABLE USING FEATURES
  31. 31. Research What Exists
  32. 32. Isolate Keywords WHEN SAVING A FILE ENTITY AND IT IS A JPEG IMAGE THEN THE EXIF META DATA NEEDS TO BE CAPTURED AND MAPPED TO CUSTOM FIELDS AND THESE MAPPINGS NEED TO BE EXPORTABLE USING FEATURES
  33. 33. Perform Search We will focus on the keyword "Exif"
  34. 34. Search Google
  35. 35. Utilize the Community
  36. 36. Evaluate the Options Exif custom seems like best fit.
  37. 37. Read the Module Description
  38. 38. Look at Community Adoption
  39. 39. Look at Maintainer Activity
  40. 40. Analyze the Gap
  41. 41. Download and Test the Module
  42. 42. Discover Missing Functionality
  43. 43. Check for Solutions
  44. 44. Determine Change
  45. 45. Review Code
  46. 46. Estimate Effort Add Features integration. Alter primary key for mappings. Time is minimal.
  47. 47. Extend or Alter Adding features support. Not changing what module does. Extending.
  48. 48. Which Path to Choose Use module as is. Patch module. Write own module.
  49. 49. Patch! Module meets 90% of needs. Small gap, small effort. Extends module.
  50. 50. What is a Patch? . A structured list of changes to files. Re­appliable to files. Focused on a single change. drupal.org/patch
  51. 51. Creating a Patch
  52. 52. Clone and branch module git repo.
  53. 53. Make changes to code.
  54. 54. Test your changes.
  55. 55. Generate patch file.
  56. 56. diff --git a/exif_custom.features.inc b/exif_custom.features.inc new file mode 100644 index 0000000..243bbe2 --- /dev/null +++ b/exif_custom.features.inc @@ -0,0 +1,158 @@ +<?php +/** + * @file + * Features file for the exif_custom module. + */ + +/** + * Implements hook_features_api(). + */ +function exif_custom_features_api() { + return array( + 'exif_custom' => array( + 'name' => t('EXIF Custom mappings'), + 'default_hook' => 'exif_custom_export_maps', + 'feature_source' => TRUE, + 'default_file' => FEATURES_DEFAULTS_INCLUDED, + 'file' => drupal_get_path('module', 'exif_custom') . '/exif_cus + ), + ); +} +...
  57. 57. Submitting a Patch
  58. 58. Create/comment on issue queue.
  59. 59. Attach your patch. Follow patch naming standards [module]­[description]­[issue­number]­[comment­number].patch
  60. 60. Watch for feedback.
  61. 61. Wait for merge. (hopefully)
  62. 62. Giving back to the community
  63. 63. Scenario #2
  64. 64. The Requirements WHEN SITE USES WORKBENCH TO MODERATE CONTENT THEN CAN CREATE MULTIPLE TRANSITIONS BETWEEN STATES AND TRANSITIONS ARE EXPORTABLE USING FEATURES WHEN EDITNG A CONTENT REVISION THEN CAN SCHEDULE A TRANSITION AND CAN SELECT DATE FOR FIRST STATE AND CAN SELECT DATE FOR SECOND STATE
  65. 65. Research What Exists
  66. 66. Isolate Keywords WHEN SITE USES WORKBENCH TO MODERATE CONTENT THEN CAN CREATE MULTIPLE TRANSITIONS BETWEEN STATES AND TRANSITIONS ARE EXPORTABLE USING FEATURES WHEN EDITNG A CONTENT REVISION THEN CAN SCHEDULE A TRANSITION AND CAN SELECT DATE FOR FIRST STATE AND CAN SELECT DATE FOR SECOND STATE
  67. 67. Search for Existing Modules We will focus on the keywords "workbench schedule"
  68. 68. Search Drupal
  69. 69. Evaluate the Options Look at Scheduler Workbench Integration.
  70. 70. Read the Module Description
  71. 71. Look at Community Adoption
  72. 72. Look at Maintainer Activity
  73. 73. Analyze the Gap
  74. 74. Download and Test the Module
  75. 75. Discover Missing Functionality Unable to create different transitions per type. Unable to select per revision. No features support.
  76. 76. Determine Change
  77. 77. Review Code
  78. 78. Estimate Effort Refactor creating schedules & transitions. Decouple transitions from content types. Add Features integration. Will take time.
  79. 79. Extend or Alter Changing how transitions/schedules are created. Changing purpose of module. Altering.
  80. 80. Which path to choose? Use module as is. Patch module. Write own module.
  81. 81. Build a custom module! Too big/complicated to be a patch. Would alter module goals. No other module exists to support use cases.
  82. 82. Writing a Module . Follow Drupal coding standards. Make use of hooks and APIs. Test your code! drupal.org/developing/modules
  83. 83. Contributing a Module Ask yourself: Could others use this? Seriously, is it abstracted enough?
  84. 84. Name module appropriately. Namespace based on dependencies. Be clear, not clever. Should indicate what module does.
  85. 85. Provide a detailed description. Explain what module does and does not do. Outline any dependencies. Help fellow R.E.A.D­ers.
  86. 86. Be a good maintainer. Bugs are badges not bruises. Participate in the issue queue. Update, release and improve.
  87. 87. Let's review
  88. 88. Remember to R.E.A.D Research what exists. Evaluate the options. Analyze the gap. Determine amount of change.
  89. 89. Slides & Notes bit.ly/fldcREAD bit.ly/fldcREADslides bit.ly/drupalREAD
  90. 90. Feedback @mikemiles86 #fldc15
  91. 91.  #fldc15 R.E.A.D /  Michael Miles Thank You!

×