The document discusses Drupal's transition from Drupal 7 to Drupal 8. It describes how Drupal 8 modernized by adopting PHP best practices like Composer, OOP, and external libraries. This required rewriting large parts of the codebase. The transition was challenging due to technical debt from the past and fears about change. Lessons learned include setting goals, gaining buy-in through transparency, incremental changes, and addressing fears through support. While the transition is not complete, Drupal 8 has rejoined mainstream PHP development practices.
3. What the heck are we talking
about?
• A brief intro to Drupal
• Then vs. now
• Re-writing your code base: a how-to
guide
• Lessons learned
4. Once upon a time…
…in a dorm room far away (Antwerp, Belgium)…
5. Once upon a time…
DRIES BUYTAERT
…in a dorm room far away (Antwerp, Belgium)…
6. Once upon a time…
DRIES BUYTAERT
IKEA furniture
…in a dorm room far away (Antwerp, Belgium)…
7. Once upon a time…
Chess board
DRIES BUYTAERT
IKEA furniture
…in a dorm room far away (Antwerp, Belgium)…
8. Once upon a time…
Chess board
DRIES BUYTAERT
Stamp collection
IKEA furniture
…in a dorm room far away (Antwerp, Belgium)…
9. …A domain name
registration was mis-typed…
(Fun fact: Dries meant to register 'dorp.org,' which is Dutch for village, and
accidentally found that drop.org was available.)
10. …And a project called
"Drupal" was born.
(Fun fact: "Drupal" is an Anglicization of the word "druppel" which is Dutch for "drop.")
14. A content management system
(to get you 80% there)
Turn on features
("modules")
Build content model
("entities" and "fields")
15. A content management system
(to get you 80% there)
Turn on features
("modules")
Build content model
("entities" and "fields")
Create custom listings
("views")
16. A content management system
(to get you 80% there)
Turn on features
("modules")
Build content model
("entities" and "fields")
Create custom listings
("views")
Make it purdy
("themes")
17. A content management system
(to get you 80% there)
Turn on features
("modules")
…zero lines of code.
Build content model
("entities" and "fields")
Create custom listings
("views")
Make it purdy
("themes")
18. A content management framework
(for that last ~20%)
Add/extend functionality, integrate with third-party systems
19. An awesome community!
(1.1M+ users, 35K+ developers, 2,400+ core contributors)
Lots from non-traditional backgrounds, self-taught PHP via Drupal
44. There are two sides to any
massive migration
Code People
45. There are two sides to any
massive migration
Code People
ignore this side at your GREAT peril!
46. 0. Set the stage
Pre-requisites to have in place first
47. Get your user base onto a
modern platform
(Fun fact: The GoPHP5 movement—a coalition of open source projects and hosts
to expedite dropping support for PHP4 in 2007—was founded by Drupalistas! :))
48. Add metric butt-loads of
automated test coverage
Including continuous integration, so you can fix failures before commit
(Fun fact: Drupal's 50K+ tests stayed 100% passing throughout D8's development)
49. Introduce a "taste" of the
future
db_update('example')
->condition('id', $id)
->fields(array('field2' => 10))
->execute();
Introduce concepts of OO and external libraries, get people comfortable with
basics before going all out.
50. 1. Set ambitious goals
There's going to be a lot of pain before the pay-off; make
the pay-off worth it.
51. Drupal 8 initiatives
configuration
management Mobile
AUTHORING
EXPERIENCE
Multilingual Views web services
53. The most successful initiatives had
leaders who…
• Communicated "early and often"!
• Documented decision-making
• Built a team around them!
• And genuinely valued that team
• Sought ways to "scale" themselves!
• Delegation
• Re-usable training material
http://hojtsy.hu/blog/2014-oct-17/authority-drupal-andor-open-source-general
55. Get the right people in the
right room
Web Services sprint:
• Drupal and Symfony
project leads
• Initiative leads
• Community voices
• Detractors
http://buytaert.net/the-future-is-a-restful-drupal
56. Detractors? Huh?
• "Pure" trolls rarely exist!
• But people feeling unheard,
frustrated do
• Provide outlet to air legitimate
concerns!
• Who knows; they might actually be
right!
• Build trust; remove defensiveness!
• Ownership in process can turn
detractors into advocates
57. Show your work!
(Just like in math class. :))
• Can't just come back with a
"decree" and expect people to
fall in line.!
• Folks need to understand and
trust in your thought process
• Transparency++
• "Issue queue or it didn't happen"
64. For new functionality
"Writing code should not be the first response.
Finding if shared code exists should be the
first response.
— Beth Tucker-Long, Editor-in-Chief, php[architect]
65. For existing functionality
• Refactor your app, don't replace it
• Replace your component, don't refactor it
• Especially cryptography!
• Build new code as components, share with
yourself
• However! If ain't broke, don't fix it.
70. Fear of losing investment in
platform
Particularly if it's your code that's being replaced.
71. Fear of going back to "square one"
and being unable to catch up
Especially pertinent for an aging community; hard to spend nights and
weekends learning new things with kids and a mortgage
72. Fear of the unknown
Not just OO, Symfony, but also entire toolchain;
IDE vs. simple text editor/grep
73. Fear of losing what makes
your community "you"
Will hobbyists, non-techies be able to make the transition?
74. What helps?
• Connecting: talking it out, sprints, planning meetings
• Documentation: "conceptual" overviews, detailed API
docs, books
• Training: presentations, examples, blog posts
• Tools: inspectors, scaffolding, automated code porting
• DX (Developer Experience): eliminate boilerplate code,
consistency/learnability of patterns
• Reinforce that OO practices are used everywhere,
may as well learn on a platform they already know!
76. 5 tips on handling a fork
• Resist reacting. Instead, listen.
• Dispel FUD, but take the high road
• Help existing devs accentuate the
positive
• Try and maintain relationship with forkers
• If concerns resonate, address them
77. Example:
Semantic Versioning
• Feature releases every 6 months
• Backwards compatibility preserved
• Both core devs and users working on same code base!
• Drupal 9? Not until there's enough to warrant breaking BC
79. Learn from our mistakes!
Please!
• The perfect is the enemy of the better.
• "All you can eat" gives you a tummy-ache.
• Don't be afraid to say "no."
• Make decisions early and explicitly
80. In Summary
1. Set the stage
2. Set ambitious goals
3. Major change needs major buy-in
4. Recognize that major change is scary
5. Avoid common pitfalls