As you'd be aware by now - Drupal 8 features lots of refactoring of form procedural code to object-oriented.
One such refactoring was the way forms are build, validated and executed.
One cool side-effect of this is that you can now build and test a form with a single class.
Yep that's right, the form and the test are one and the same - read on to find out more.
As part of our code review process for a current project, it was suggested that rather than calling the static Drupal formBuilder function to insert a form into a custom block, we actually inject the *Form Builder service* directly into the module, and for bonus points also inject the renderer service. I'd previously had exposure to dependency injection earlier on the same project but hadn’t exactly grokked the concept fully and so with a few pointers in the right direction, I set about refactoring the code I’d written using dependency injection and Drupal services.
Drupal's Batch API is great, it allows you to easily perform long running processes with feedback to the user.
But during Drupal 8's development processes it was one of the remaining systems that didn't get the full object oriented, service-based architecture.
Much of the batch API is largely unchanged from Drupal 7.
But that doesn't mean you can't write unit-testable callbacks.
Let's get started.
This one tripped me up on a recent Drupal 8 project.
Easy to miss when you're working in a development oriented environment with things like JavaScript preprocessing turned off.
A JavaScript file was being added just fine with aggregation turned off, but not getting added with it turned on.
On a recent Drupal 8 client project our client was building listing pages using views exposed filters and adding these to the menu.
This resulted in several menu URLs pointing to the same base path, but with the query arguments determining the difference.
However Drupal 8's default menu-trail calculation was resulting in the menu highlighting all instances when one of them was viewed.
Luckily the active trail calculation is done in a service and it was simple to modify the default behaviour.
Read on to see how we did it.
Drupal 8 includes a datetime field type and widget out of the box.
The widget uses the HTML5 date element on supported browsers, providing a polyfill to a text field with jQuery UI's datepicker for browsers that don't yet support HTML5 date inputs.
However - HTML5 date formats always work in ISO8601 format - ie YYYY-MM-DD - which isn't very user-friendly for those using Firefox and Internet Explorer.
Luckily, with a few tweaks you can easily swap this into DD/MM/YYYY format for those browsers and then switch it back server side into the format Drupal expects.
PHPStorm has a lot of built in test runners, but it doesn't support Drupal's Simpletest test runner. In this blog post we'll see how we can execute Drupal tests inside PHPStorm using Drupal test runner.
Whilst working on a Drupal 8 project, we found that cache tags for a Block Content entity embedded in the footer weren't bubbling up to the page cache.
Read on to find out how we debugged this and how you can ensure this doesn't happen to you too.
typey has just turned 1.0, so I thought it would be a great time to show off some of its features.
Recently, I have been working on a site with a big multi-step form that is using a lot of custom form elements, custom auto-completes, custom form api states and ajax based sub-forms. It is all built using Drupal form api. The best thing about this form is that all the fields and sub-forms map to a data model.