Fri, 07/26/2019 – 01:47
Sometimes we just want to see if a thing works
Recently I ran into a situation while building out the Watson/Silverpop Webform Parser where I just wanted to test and see if a few things worked without having to reload and bootstrap Drupal every time I refreshed a page. I also wanted to utilize some of the classes and methods made available from Symfony and Drupal. Can you feel my dilemma?
Let’s be honest, running
drush cr and refreshing a page takes time, and I’m an impatient person, so I wanted to see if there was a way to use some of these things without going through the pain of waiting for a Drupal bootstrap. Turns out, the solution wasn’t that difficult and it made development on many methods of my module more pleasant than it could have been.
Here’s the scenario
I wanted to test a few things that didn’t require the database connection. Specifically,
DrupalCoreSerializationYaml to parse an array that I was building into YAML. So, what I did was stubbed out what would become my class
WatsonFormEntityForm in a file in my docroot that I creatively named
test.php. Now I was able to navigate to
local.docksal/test.php on my local machine and see things working.
Get to the good stuff, already!
I got to a point in my development where I was able to convert the submitted HTML, in this case from a call to
file_get_contents('./test.html'); into an array that I could work with. Xdebug was going great, and so was the module, but I wanted to see if I could convert it into YAML using a native Drupal method. The solution came with one single line of code.
$autoloader = require_once 'autoload.php';
This tells PHP, “Hey, we got a file here that wants to use some of the methods and classes in the Autoloader. Let’s go ahead and let it!” This variable doesn’t need to be called anywhere in the file. It just needs to exist. Now I was able to update the file with a few friendly
use statements from within the Drupal and Symfony ecosystem without having to wait for all the database connections to happen.
The end result was:
It sped up development, and it made it so I didn’t have to wonder if something wasn’t working because I forgot to
drush cr all the things or if it was just because I made some mistakes.
Be sure that any code you’re running doesn’t rely on database calls or the container. For instance, if you try to run
$nodes = Drupal::entityTypeManager()->getStorage('node')->loadMultiple(); is going to throw a painful error.
Also, this is mainly for rapid prototyping or proving concepts. I don’t recommend writing an entire module in procedural code and then trying to refactor later. Maybe take it one function at a time just to make sure it’s doing what you want it to do.
Let me know if this helped you out or if you have better suggestions for rapidly testing some Drupal stuff without having to rely on a full bootstrap. As always, feel free to reach out to me on the Drupal Slack, where I’m always Dorf and always willing to help if I can.