To use a contrib (community) module, patch a contrib module or write a custom module, that is the question. With over 25,000 community contributed modules available for download it is rare to find one that does not offer the functionality you are looking for. However, when you cannot find a module that fits your needs you are then faced with a choice. Do you patch an existing contrib module? Or write a custom one? To figure out the answer to the answer you just need to remember to R.E.A.D. In this session we will go over the four steps of R.E.A.D that help you decide which path you should follow and how you can quickly and correctly identify if you should patch a contrib module or write your own custom module. We will use some real world examples to demo straight how these steps were utilized to make the correct decision. We will also talk about the basics and best practices of writing and contributing a patch, and the best practices to follow if you decide to pursue writing a custom module and how to contribute it back to the Drupal community. This session is geared to 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 validation on habits they have developed over time.

1. To Patch or Custom
How to select the right path.
#PatchOrCustom, #justREAD

2. Who You Are.
• Site Builder
• Developer
• Decision Maker
• New to Drupal
!
• Want to re-enforce habits

3. What’s it all about.
How to quickly make smart, informed decisions.

4. Michael Miles
• Associate Director of PHP @ Genuine Interactive.
• Drank the Drupal Kool-aid in 2008. (it’s grape flavored)
!
• Twitter: @mikemiles86
• D.o: mikemiles86
@WeAreGenuine

5. A lover of memes.

6. How to R.E.A.D!
(yay acr!onyms!)

7. R.E.A.D
• Research what exists.
• Evaluate the options.
• Analyze the gap.
• Determine amount of effort.
#justREAD

8. Research what exists.

9. Research what exists.
• Isolate key functionality needs.
• Search for existing modules.
• Use the community.

11. Evaluate the options.

12. Evaluate the options.
• Read the module description.
• Look at community adoption.
• Look at maintainer activity.

14. Analyze the gap.

15. Analyze the gap.
• Download and test the module.
• Discover missing functionality.
• Check issue queue for solutions.

16. Patch not found.

17. Determine amount of effort.

18. Determine amount of effort.
• Review the module code.
• Estimate how much has to be changed.
• Do changes extend or alter module?

19. Let’s review.
Like developers…

20. Research.!
Find modules?
Evaluate.!
find best
fit?
Analyze.!
is there a
gap?
Use community solutions.
Determine.!
big change?
Build a custom module.
Use existing module.
Community
solutions
exist?
Patch.
YES YES YES
YES
NO NO
NO NO
YES
NO
…Flow Chart FTW!

21. Examples.

22. Scenario #1.

23. The Requirements.
WHEN SAVING A FILE
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
!

24. WHEN SAVING A FILE
Research what exists.
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.
!
Isolate key functionality needs.

25. Research what exists.
Search for existing modules.

26. Research what exists.
Find possible existing solutions
• The Exif module
• The Exif custom module

27. Evaluate the options
Read the module description.

28. Evaluate the options
Look at community adoption.
Exif
Exif Custom

29. Evaluate the options
Look at maintainer activity.

30. Evaluate the options
Determine best fit.

31. Analyze the gap.
Download and test the module.

32. Analyze the gap.
Discover missing functionality.

33. Analyze the gap.
Check issue queue for solutions.

34. Which path to choose?
• Patch Exif Custom module
!
• Write own Exif module

35. PATCH!

36. What is a Patch?
• drupal.org/patch
• A structured list of changes to a file.
• Used to re-create changes to a files.
• Focus on a single change.

37. How to submit a Patch.
• Create/Comment on an issue.
• Attach the patch.
• [description]-[issue-number]-[comment-number].patch
• Revise based on testing/reviews.

38. Contributed a Patch

40. Scenario #2.

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

42. Research what exists.
Isolate key functionality needs.
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

43. Research what exists.
Search for existing modules.

44. Evaluate the options
Read the module description.

45. Analyze the gap.
Download and test the module.

46. Analyze the gap.
Discover missing functionality.
• Unable to create different transition schedules
• Unable to select different transitions for revisions
• No features integration.

47. Determine amount of effort.
Estimate how much has to be changed.
• Will need to change how schedules are created.
• Will need to change how schedules are stored.
• Will need to add features integration.

48. Which path to choose?
• Patch Scheduler workbench module
!
• Write own scheduler module

49. CUSTOM MODULE!

50. Module Writing Guidelines.
• drupal.org/developing/modules
• Follow Drupal coding standards.
• Make use of hooks and APIs.
• Test your code.

51. Contributing a module.
• Is it functionality other could use?
• Name appropriately.
• Provide accurate description.
• Be an active maintainer.

52. Wrote a custom module.

53. Be an active maintainer.

55. Remember R.E.A.D.
• Research what exists.
• Evaluate the options.
• Analyze the gap.
• Determine amount of effort.
#justREAD

56. Thank You!
@mikemiles86