1. Modernize Your Drupal Development
Chris Tankersley
php[world] 2014

2. 2
Who Am I?
● A PHP Developer for 10 Years
● Drupal Dev for 4 years
● Lots of projects no one uses, and a few
some do
● https://github.com/dragonmantank

3. 3
We've got a lot to cover
● Development Environments
● Version Control
● drush
● Coding Standards
● Building Better Modules
● Moving Out of the Database
● Putting it all together

4. 4
Development Environments

5. 5
Local Stack
● Run everything off of your local
machine!
● Most performant of the options

6. 6
Local Stack
● Not very portable
● More junk on your PC to maintain
● Probably not at all like Production

7. 7
Don't use Portable *AMP stacks

8. 8
If you have to...
● Acquia Dev Desktop
● Zend Server

9. 9
Acquia Dev Desktop
● Pre-built *AMP Stack
● Available for Drupal 6 or 7
● Install and Ready to Go

10. 10
Acquia Dev Desktop
● Not built for multiple installs
● Can’t use for existing sites
● Only for Windows and Mac

11. 11
Zend Server
● Uses OS's server
● Has some cool tools like Z-Ray
● Mostly a wrapper around the local stack
● Support!
● Has a Development and Production
version

12. 12
Zend Server
● Weird issues with permissions
● Works best with other Zend tools
● Pricey

13. 13
How it looks
Your OS
Applications
Your App
Web Server DB Server

14. 14
docker
● Containers for applications
● Makes deployment very easy
● Very easy to get set up
● Way more performant than VMs

15. 15
docker
● If you're not on Linux, think really hard
about using
● Mostly a deployment fixer

16. 16
How it looks - Linux
Your OS
Applications
Your App
Web Server DB Server

17. 17
How it looks – Everywhere Else
Your App
Web Server DB Server
Virtualized OS
Applications Virtualization Layer
Your OS

18. 18
vagrant
● Full server to run code
● Self contained and can be replicated
● Most modern machines can do VM

19. 19
vagrant
● Uses more resources
● Easier to break
● When it breaks, it breaks hard

20. 20
How it looks
Your App
Web Server DB Server
Virtualized OS
Applications Virtualization Layer
Your OS

21. 21
A quick demo

22. 22
Considerations
● How special is my Production environment?
● What resources do my dev machines have?
● How many things am I working on?
● What's the tech level of my coworkers?
● What's the tech level of my clients?

23. 23
Version Control

24. 24
What is version control?
● Some system that keeps track of
changes to source code

25. 25
Many different systems
● Git
● Subversions
● Mercurial

26. 26
It doesn't matter which one you use

27. 27
A Quick Demo

28. 28
Workflows
● Github/Pull Request
● Gitflow
● Rebase

29. 29
GitHub Workflow

30. 30
For more info...
https://guides.github.com/introduction/flow/index.html

31. 31
Rebase Workflow

32. 32
For more info...
http://randyfay.com/content/rebase-workflow-git

33. 33
gitflow

34. 34
develop master
Tag: 0.9.2
blog_rework staff_page v0.9
Tag: 1.0.0
v1.0
Tag: 0.9.3

35. 35
For more info...
http://nvie.com/posts/a-successful-git-branching-model/

36. 36
Jeff Carouth's „Git and Github – Working
Effectively on a Team“
https://speakerdeck.com/jcarouth/git-and-github-
working-effectively-on-a-team-at-php-tek-
2014

37. 37
Any questions?

38. 38
Are we finally ready for some actual Drupal?

39. 39

40. 40
drush

41. 41
What is drush?

42. 42
What is drush?
● Command line interface for (much of)
Drupal
● Allows modules to be CLI driven
● Much, much quicker than the GUI

43. 43
How does it work?

44. 44
Common Commands

45. 45
Download Drupal
$ drush dl drupal --drupal-project-rename="drupal"
Project drupal (7.32) downloaded to /vagrant/drupal-7.32.
[success]
Project drupal contains:
[success]
- 3 profiles: testing, standard, minimal
- 4 themes: stark, seven, garland, bartik
- 47 modules: drupal_system_listing_incompatible_test,
drupal_system_listing_compatible_test, user, update, trigger, translation, tracker,
toolbar, taxonomy, system, syslog, statistics, simpletest, shortcut, search, rdf, profile,
poll, php, path,
overlay, openid, node, menu, locale, image, help, forum, filter, file, field_ui, text,
options, number, list, field_sql_storage, field, dblog, dashboard, contextual, contact,
comment, color, book, blog, block, aggregator

46. 46
Install Drupal
$ drush site-install standard -y --db-url=mysql://drupal:DrupalR0cks@localhost/drupaldb
--account-name=admin --account-pass=admin --site-name="My Drupal Site" --site-mail=
youremail@domain.com

47. 47
Run a development server
$ drush runserver 8080
$ drush runserver 0.0.0.0:8080

48. 48
Watching the Watchdog
// Show the last 10 messages
$ drush watchdog-show
// Show the last 50 messages
$ drush watchdog-show --count=50
// Show only entries of a specific severity
$ drush watchdog-show --severity=notice
// Search for a specific message
$ drush watchdog-show "cron run successful"

49. 49
Viewing Watchdog Entries
$ drush watchdog-show 54
ID : 54
Date : 30/Jan 22:10
Type : system
Severity : info
Message : overlay module disabled.

50. 50
Cleaning Up After the (Watch)dog
// Destroy it all!
$ drush watchdog-delete all
// Delete a specific one to hide an error you generated that no one can know about
$ drush watchdog-delete 50
// Delete all messages containing a string
$ drush watchdog-delete "cron run successfull"
// Delete everything of a specific severity
$ drush watchdog-delete --severity=debug

51. 51
Working with modules
$ drush pm-download backup_migrate
$ drush pm-enable backup_migrate
$ drush pm-update

52. 52
drush Aliases
● Allows you to tell drush where an
external site is located at
● Requires drush on the other end, and
shell access

53. 53
Creating an alias
// sites/all/drush/prod.alias.drushrc.php
$aliases['prod'] = array(
'uri' => 'mysite.com',
'root' => '/public_html/',
'remote-host' => '10.0.2.2',
'remote-user' => 'mysite',
);

54. 54
Using an alias
$ drush @prod status
PHP configuration : /Applications/acquia-drupal/php5_3/bin/php.ini
Drush version : 5.7
Drush configuration :

55. 55
Common uses for aliases
$ drush rsync sites/default/files/ @prod:sites/default/files
$ drush sql-sync @prod @self
$ drush @prod site-install standard [...]

56. 56
Deploying code with drush
$ drush rsync @self @prod
You will destroy data from ctankersley@10.0.2.2:'~/Sites/deploy/' and
replace with data from /vagrant/
Do you really want to continue? (y/n): y

57. 57
Questions?

58. 58
Coding Standards

59. 59
Huh?
Coding standards are a list of rules regarding
the layout and structure of source code.

60. 60
What?
● Two space indents
● Spaces between casts
– $id = (int) $_POST['id'];
● Not using else if, using elseif
● Always using curly braces on control
structures

61. 61
Why?
● Makes it easy to read code
● Makes it easy to merge code
● You're on a team, act like it
● If you want your code on drupal.org, you're
going to need to follow it
● If you want to contribute, you'll need to follow it

62. 62
For the nitty-gritty...
● https://www.drupal.org/coding-standards

63. 63
Tools
● Code Sniffer with Drupal rules
● Coder
● PAReview
● Grammer Parser

64. 64
Code Sniffer
● Compares your code to some coding
standard
● General PHP tool, not specific to Drupal
● CLI

65. 65
Code Sniffer
https://www.drupal.org/node/1419988

66. 66
Demo Time

67. 67
Coder
● GUI to check your code against coding
standards
● https://www.drupal.org/project/coder

68. 68
Demo Time

69. 69
PAReview
● Project Application Review
● First line of defense against bad
modules
● Online code sniffer for drupal.org

70. 70
Self Hosted
● Add the Drupal, DrupalSecure,
DrupalPractice, and Codespell
standards to CodeSniffer
● Download the bash script from Github

71. 71
Install DrupalPractice
$ git clone https://github.com/klausi/drupalpractice.git ~/.drush/drupalpractice
$ ln -sv ~/.drush/drupalpractice/DrupalPractice
~/.composer/vendor/squizlabs/php_codesniffer/CodeSniffer/Standards/

72. 72
Quick Demo

73. 73
Questions?

74. 74
Building Better Modules

75. 75
Drupal supplies a lot of things for you
● Form API
● Schema API
● Theme Layer
● Unit Testing
● Entities

76. 76
Unit Testing

77. 77
How Test Driven Development works
● Write your tests before your code
● Watch it fail
● Write code to make your test pass
● Feel better! (and refactor)

78. 78
TDD In Drupal
● Drupal ships with SimpleTest baked in
● Supports unit testing and functional testing
● Unit tests are done by extending
DrupalUnitTestCase
● Functional tests are done by extending
DrupalWebTestCase

79. 79
Unit Tests vs Functional Tests
● Unit tests should focus on testing an
individual piece of code
● Functional tests should focus on testing
output/pages

80. 80
Unit Tests vs Functional Tests
● Unit tests do not bootstrap Drupal, so
are very quick
● Functional tests do bootstrap Drupal, so
are very slow

81. 81
Downsides to TDD in Drupal
● The GUI is an AJAX runner, which breaks a lot
– Use drush for a better experience
● Debugging can be very hard, since the
environment is created and destroyed each
test
– Use $this->verbose() or debug()

82. 82
Let's build a test

83. 83
Let's build a test

84. 84
Caching and Asset Aggregation
● Drupal has a caching layer
● Drupal has a basic asset pipeline

85. 85
Turn it on on Performance

86. 86
Turn it on on Performance

87. 87
Caching
● Caching saves a chunk of the render
array to the DB
● Caching still requires a DB hit

88. 88
Two Different Caches
● Page caching for full output
● Block caching for dynamic content

89. 89
Asset Aggregation
● Groups CSS and JS together, reducing
HTTP calls
● Will minify the CSS, reducing the
transmission size

90. 90
Easy to take advantage of
● Let Drupal know about your files
– drupal_add_js()
– drupal_add_css()
– Through #attached
– Add it to your .info file
● Don't just add straight to templates

91. 91
Adding JS

92. 92
Using #attached

93. 93
Entities
● Basic building blocks of 'things' in
Drupal
● You already use them
● Entity API provides an interface for
making your own

94. 94
Why use them?
● Drupal takes care of a lot of scaffolding
● Allows site builders to extend them

95. 95
What is an entity?
● A [Drupalized] thing
● Series of classes and functions that tell
Drupal how to deal with your thing

96. 96
What do we need?
● A dependency on the Entities module

97. 97
A place to store things...

98. 98
And now we create a class for our entity

99. 99
And now we tell Drupal about it

100. 100
Let's create an admin form

101. 101
Now let's use it!

102. 102
Moving Out of the Database

103. 103
The Database Sucks
● Drupal stores a lot of things in the
database
● Databases are hard to version
● Database info is hard to move

104. 104
Features!
● Features allow you to package up stuff
into modules
● Makes deploying code much easier

105. 105
Bundle things together

106. 106
Bundle lots of things

107. 107

108. 108
Questions?

109. 109
Thanks!
● http://joind.in/talk/view/11901
● @dragonmantank
● chris@ctankersley.com