Embed Size (px)
Citation preview
Rapid Module DevelopmentDrupaldelphia, April 27, 2018
Eastern Standard
● Philadelphia-based marketing and
technology agency
● Collaborative dev team
● We’re hiring!
Intros
Tom Mount
● Technology Lead, Eastern Standard
● Closet geek
● Hobbies include bass guitar and rec
football year-round
● Email: [email protected]
● Drupal: https://www.drupal.org/u/tmountjr
Cliche alert: “Work smarter, not harder.”
The Not-So-Rapid Setup
Tools: What you probably already have
● A CLI/terminal/command prompt● A Drupal 8 project, one that’s either set up somewhere already, or at least the zipped version of Drupal Core 8.5.72.
Tools: What you should download
● VSCode (https://code.visualstudio.com/), available for Windows, OS X, and Linux (.rpm and .deb), along with some plugins:● PHP Debug (https://github.com/felixfbecker/vscode-php-debug)● EditorConfig (https://github.com/editorconfig/editorconfig-vscode)● PHP DocBlocker (https://github.com/neild3r/vscode-php-docblocker)● PHP CS (https://github.com/ikappas/vscode-phpcs)● PHP CS Fixer (https://github.com/junstyle/vscode-php-cs-fixer)
● Drupal Console (https://drupalconsole.com/)● Docker (https://www.docker.com/)● Lando (https://docs.devwithlando.io/)
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:
● Git● Composer● Drush (https://www.drush.org/)
● Drush 8 may already be installed globally (http://docs.drush.org/en/8.x/install/)● Drush 9 may already be installed in the project and can be accessed with Drush Launcher
(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:
● Install VSCode and all the extensions.● Install Docker.● Install Lando.● Install Drupal Console Launcher.
Now can we get to developing?(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:
● Should store its configuration the way other modules store Drupal configuration.● Should include a form to edit those config values.● Should include a menu link to that form.● Should include some level of permission control that site owners can set if they so desire.
In most cases, your custom module will have a lot more functionality, but this is fine for the purposes of a demo.
Step 0: Set up a new/existing local Drupal site.
Set up a new/existing local Drupal site
Set up a new/existing local Drupal site
Step 1: Create your module.
Create your module
(Optional) Step 1.5: Move the module.
Move the module
Step 2: Enable the module.
Enable the module
Step 3: Generate a config file and form.
Generate a config file and form
Generate a config file and form
Step 4: Verify config is being saved.
Verify config is being saved
The end! …?
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.
Step 5: Add validation.
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
Step 6: Add permissions.
Add permissions
Add permissions
Add permissions
Add permissions
Test permissions
Test permissions
Test permissions
Test permissions
Recap
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
Further Reading
● XDebug: https://deliciousbrains.com/xdebug-advanced-php-debugging/● Docksal, similar to Lando, might be easier if you already know Docker pretty well: https://docksal.io/● All the Drupal Console commands: https://docs.drupalconsole.com/en/commands/available-commands.html● All the Drush 8 commands: https://drushcommands.com/
Conclusion
Questions
