Rapid Module Development Drupaldelphia, April 27, 2018 Intros Tom - - PowerPoint PPT Presentation
Rapid Module Development Drupaldelphia, April 27, 2018 Intros Tom Mount Eastern Standard Technology Lead, Eastern Standard Philadelphia-based marketing and Closet geek technology agency Hobbies include bass guitar and
Drupaldelphia, April 27, 2018
Eastern Standard
technology agency
Intros
Tom Mount
football year-round
Tools: What you probably already have
Tools: What you should download
plugins:
Note that the only plugin we’ll definitely be using here is PHP Debug. The others are nice to have and help you write beautiful and standards-compliant code quickly, but it probably won’t speed up your actual code writing.
Chances are good you already have these installed and running. But in case you don’t:
(https://github.com/drush-ops/drush-launcher)
Tools: What you might need to download, but probably not.
Tools: The One-Time Setup
To follow along, you’ll need to do the following:
(It’s been like two hours already!)
Your Module: What will it do?
Having a clear idea of what you want to accomplish with your custom module will save you time later. The Drupal module ecosystem is pretty big; maybe someone has already done what you want to do? Spending 30 minutes poking around https://drupal.org is definitely faster than spending six hours writing a custom module that someone else has already written. Efficiency isn’t necessarily about doing things quickly, it’s about being smart in your approach.
Your Module: What will it do?
Let’s create a very custom module:
In most cases, your custom module will have a lot more functionality, but this is fine for the purposes of a demo.
Create your module
Move the module
Enable the module
Generate a config file and form
Generate a config file and form
Where to go from here
We could stop here. We have a config form, and several hundred lines of code that we didn’t have to write that handle routing, configuration, and menus. But the form asks for an API URL. And it happily accepts “hello world.” Let’s fix that.
Validation, part 1: making sure XDebug works
XDebug is a fantastic PHP debugger. You can step through your code line by line, jump in and out of methods, get detailed stack traces, set conditional breakpoints...everything you need to inspect what’s happening in your module under the surface. It’s fairly easy to set up in VSCode.
Validation, part 1: making sure XDebug works
Validation, part 1: making sure XDebug works
Validation, part 1: making sure XDebug works
Validation, part 1: making sure XDebug works
Validation, part 2: figuring out how to validate
Back in the day, everyone had their own regular expression for URLs, email addresses, etc. They all had problems. Luckily, a quick Google search (“drupal 8 valid url”) landed me on the UrlHelper::isValid() documentation page. The method looks easy enough to figure out how it works, but let’s test it anyway with another great tool: the Drupal PHP REPL.
Validation, part 2: figuring out how to validate
Validation, part 3: actually validating
Validation, part 3: actually validating
Add permissions
Add permissions
Add permissions
Test permissions
Test permissions
Test permissions
Test permissions
How is this faster? Instead of…
...setting up on Pantheon or Acquia, committing code, testing, committing more code, doing more testing...
...we can…
...use Lando as a local development environment.
How is this faster? Instead of…
...reading the Form API and menu docs and writing a few hundred lines of code by hand, then reading a bunch of blogs about how to set up new configuration files and writing a few dozen more lines of code by hand...
...we can…
...use the Drupal Console to generate a brand new module, set up a new config file, create a configuration editing form, and set up permissions.
How is this faster? Instead of…
...clicking around in the admin interface for a while to create roles and a new user...
...we can…
...use the Drupal Console to stub out a new user role and a new user, right from the command line.
How is this faster? Instead of…
...choosing a password, writing it down or putting it in a password manager, and cluttering up your brain...
...we can…
...use Drush and a private browsing window to log in as that new user without worrying what the password was.
How is this faster? Instead of…
...dropping a bunch of var_dump(); die(); statements everywhere, or, if you want to get really elegant, installing the debug module and using kint() everywhere, both of which require reloading the page every time you change anything… (What you’re looking for wasn’t in the variable you kint()ed? Guess you gotta reload and try again!)
...we can…
...use a free and powerful IDE, along with a proper debugging tool, to quickly inspect variables while our code was running, letting us get some insight into Drupal was doing “under the hood.”
How is this faster? Instead of…
...doing something silly like making a custom route that exists solely to run one statement and print the output to the screen (which I’ve done) or blindly hammering away at a method until you find the right variable to pass...
...we can…
...use Drush’s PHP REPL to quickly test out some inputs against a Drupal utility method without having to guess or go the long way around.
Further Reading