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 rec ● Collaborative dev team football year-round We’re hiring! ● ● Email: tomm@easternstandard.com 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.

Tools: What you might need to download, but probably not. 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: 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… ...we can… ...setting up on Pantheon or Acquia, committing code, ...use Lando as a local development environment. testing, committing more code, doing more testing...

How is this faster? Instead of… ...we can… ...reading the Form API and menu docs and writing a few ...use the Drupal Console to generate a brand new hundred lines of code by hand, then reading a bunch of module, set up a new config file, create a configuration blogs about how to set up new configuration files and editing form, and set up permissions. writing a few dozen more lines of code by hand...

How is this faster? Instead of… ...we can… ...clicking around in the admin interface for a while to ...use the Drupal Console to stub out a new user role and create roles and a new user... a new user, right from the command line.

How is this faster? Instead of… ...we can… ...choosing a password, writing it down or putting it in a ...use Drush and a private browsing window to log in as password manager, and cluttering up your brain... that new user without worrying what the password was.

How is this faster? Instead of… ...we can… ...dropping a bunch of var_dump(); die(); ...use a free and powerful IDE, along with a proper statements everywhere, or, if you want to get really debugging tool, to quickly inspect variables while our elegant, installing the debug module and using kint() code was running, letting us get some insight into Drupal everywhere, both of which require reloading the page was doing “under the hood.” 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!)

How is this faster? Instead of… ...we can… ...doing something silly like making a custom route that ...use Drush’s PHP REPL to quickly test out some inputs exists solely to run one statement and print the output to against a Drupal utility method without having to guess or the screen (which I’ve done) or blindly hammering away go the long way around. at a method until you find the right variable to pass...

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