The purpose of software testing is to reduce issues to a minimal level and to carve out optimal quality for a product. When it comes to bugs and defects, there are different schools of thought, but quality is always the main focus.
This is Part 4 of an interview with Will Eisner, Senior Director, Product at Acquia.
Now that we've covered debugging Drupal 8 in PhpStorm using local web-based approaches, let's move on to command line debugging.
As Drupal is increasingly widely used as a back end for application ecosystems, developers of wildly diverse backgrounds are now retrieving and manipulating data from Drupal in unprecedented ways. With Drupal 8 and core REST support articulating an API-first vision for the decoupled future, Drupal is eminently well-prepared to back a bevy of applications with divergent approaches. There's just one problem: non-Drupal developers don't know Drupal.
That's where Waterwheel comes in. Waterwheel is an emerging ecosystem of software development kits (SDKs) built by the Drupal community which ease and accelerate development of applications in other technologies. If you will momentarily forgive the flawed metaphor, Waterwheel helps non-PHP and non-Drupal developers "speak" Drupal.
Lots of people think that template engines like Twig cannot be interactively debugged. I heard this several times as an argument against template engine, and for using legacy php processing like phptemplate (standard in Drupal 7).
Well, it’s not entirely true.
Progressive decoupling, a concept outlined last year in Dries Buytaert’s first post about decoupled Drupal, is a compelling approach to building Drupal's front end where content editors, site assemblers, and front-end developers maintain contiguous experiences. For content editors and site assemblers, progressive decoupling allows for contextualized interfaces, content workflow, site preview, and other features to remain usable and integrated with Drupal as a whole.
At ClikFocus, we have been following and playing with Drupal 8 for more than a year.
Welcome to Post #2 in my series about debugging in Drupal 8.
Regardless of the purpose of your Drupal site, it is important that the site be reliably available and performant for your users. For those of us with limited resources at our disposal it isn’t feasible to scale up hardware indefinitely. Thankfully, Drupal provides us with a number of tools in core, and even more in the contrib community, that make caching accessible to even the least technical amongst us. Let’s walk through the basics of the Drupal cache and discuss the importance of properly configuring cache with the goal of avoiding common missteps.
Welcome to my series of blogs about debugging in Drupal 8.
The reason why I decided to create this series is that a lot of Drupalists use ”legacy” ways of non-interactive debugging based on php-native commands like
debug_print_backtrace() or commands provided by contributed modules or themes like
dump() inside of twig templates.
tl;dr: Acquia Pipelines lets you automate building, testing, and deploying sites on Acquia Cloud using tools like Composer, Sass, and Behat.
As Amazon Web Services has grown into the vast platform that it is today, it has created many opportunities for innovation: in how we interact with the products and how we fit all the pieces togeth