There's a great module called the debug module. I'd give you the link… but it doesn't exist. Or rather, it's not a module you download. It's a module you write yourself, and write again, over and over again.
Do you ever want to inspect the result of a method call, or the data you get back from a service, the result of a query, or the result of some other procedure, without having to wade through the steps in the UI, submit forms, and so on?
This is where the debug module comes in. It's just a single page which outputs whatever code you happen to want to poke around with at the time. On Drupal 8, that page is made with:
- an info.yml file
- a routing file
- a file containing the route's callback. You could use a controller class for this, but it's easier to have the callback just be a plain old function in the module file, as there's no need to drill down a folder structure in a text editor to reach it.
(You could quickly whip this up with Module Builder!)
Here's what my router file looks like:
joachim_debug:
path: '/joachim-debug'
defaults:
_controller: 'joachim_debug_page'
options:
_admin_route: TRUE
requirements:
_access: 'TRUE'
My debug module is called 'joachim_debug'; you might want to call yours something else. Here you can see we're granting access unconditionally, so that whichever user I happen to be logged in as (or none) can see the page. That's of course completely insecure, especially as we're going to output all sorts of internals. But this module is only meant to be run on your local environment and you should on no account commit it to your repository.
I don't want to worry about access, and I want the admin theme so the site theme doesn't get in the way of debug output or affect performance.
If you sometimes want to see themed output, you can add a second route with a different path, which serves up the same content but without the admin theme option:
joachim_debug_theme:
path: '/joachim-debug-theme'
defaults:
_controller: 'joachim_debug_page'
requirements:
_access: 'TRUE'
The module file starts off looking like this:
opcache_reset();
function joachim_debug_page() {
$build = [
'#markup' => “aaaaarrrgh!!!!”,
];
/*
// ============================ TEMPLATE
return $build;
*/
return $build;
}
The commented-out section is there for me to quickly copy and paste a new section of code anytime I want to do something different. I always leave the old code in below the return, just in case I want to go back to it later on, or copy-paste snippets from it.
Back in the Drupal 6 and 7 days, the return of the callback function was merely a string. On Drupal 8, it has to be a proper render array. The return text used to be 'It's going wrong!' but these days it's the more expressive 'aaaaarrrgh'. Most of the time, the output I want will be the result of dsm() call, so the $build is there just so Drupal's routing system doesn't complain about a route callback not returning anything.
Here are some examples of the sort of code I might have in here.
// ============================ Route provider
$route_provider = \Drupal::service('router.route_provider');
$path = 'node/%/edit';
$rs = $route_provider->getRoutesByPattern($path);
dsm($rs);
return $build;
Here I wanted to see the what the route provider service returns. (I have no idea why, this is just something I found in the very long list of old code in my module's menu callback, pushed down by newer stuff.)
// ============================ order receipt email
$order = entity_load('commerce_order', 3);
$build = [
'#theme' => 'commerce_order_receipt',
'#order_entity' => $order,
'#totals' => \Drupal::service('commerce_order.order_total_summary')->buildTotals($order),
];
return $build;
I wanted to work with the order receipt emails that Commerce sends. But I don't want to have to make a purchase, complete and order, and then look in the mail logger just to see the email! But this is quicker: all I have to do is load up my debug module's page (mine is at the path 'joachim-debug', which is easy to remember for me; you might want to have yours somewhere else), and vavoom, there's the rendered email. I can tweak the template, change the order, and just reload the page to see the effect.
As you can see, it's quick and simple. There's no safety checks, so if you ever put code here that does something (such as an entity_delete(), it's useful for deleting entities in bulk quickly), be sure to comment out the code once you're done with it, or your next reload might blow up! And of course, it's only ever to be used on your local environment; never on shared development sites, and certainly never on production!
I once read something about how a crucial piece of functionality required for programming, and more specifically, for ease of learning to program with a language or a framework, is being able to see and understand the outcomes of the code you are writing. In Drupal 8 more than ever, being able to understand the systems you're working with is vital. There are tools such as debuggers and the Devel and Devel Contrib modules' information pages, but sometimes quick and dirty does the job too.