The process of debugging can be a difficult one, and the process of troubleshooting performance even more so. Luckily there are some great tools out there to help with improving the performance of web applications. Previously I wrote about generating flamegraphs from XHProf to visual stacktraces and identify bottlenecks. Flamegraphs are very helpful, but still require you to setup XHProf, download the tools for making the flamegraph SVG, and appropriately change your code to save the XHProf data.
I've been working on a Docker tool for local environments and one of the tools is setting up the ability to easily generate flamegraphs. I figure the best test run would be to dive into some basic info on the performance of a front page load for a typical Drupal Commerce site. There's no magic solution presented here, just some knowledge on what the build process looks depending on caches.
iPhones 4 and up store images in landscape mode and use EXIF data to provide proper rotation when viewed. This is a bit quirky as not all desktop browsers provide fixes, or they may not be streamlined. I remember my old project manager telling me their images were showing up "flipped to the side" during mobile QA testing. Sure enough when the image was embedded in HTML it was cocked to the side - however when viewed directly in the browser or desktop it was fine. What?
The Features module has become a de facto tool in configuration management in Drupal 7. In fact, most Drupal distributions now utilize Features to export configuration and handle updates to the configuration. There is one pitfall - Features was meant to be a way to export a feature set. Features takes a set of configurations and its job is to ensure those are in place. That means customizations to defaults are at risk of preventing incoming changes or loss when updating. That’s not good!
I've been a fan of Platform.sh since it came out, even before I started at Commerce Guys. I'm a fan of using builder tools for constructing projects - Composer or Drush make (latter for Drupal) - instead of putting extra code into version control. However, this post is not about a PHP project, but one of my AngularJS projects.
Recently I presented at the Drupal 414 user group in Milwaukee on "Drupal Commerce, Deconstructed" to break down what makes Drupal Commerce and better explain some of its inner workings. The goal isn't to blow the minds of advanced users, but to sell it to all on its flexibility and help users understand why certain things are how they are. I've also submitted it as a session to DrupalCamp WI 2015.
I don't use the built in update functionality provided by the Update module for updating code. I like to use it for reminders and push back statistics of modules used for Drupal.org. However, someone people do use it. Sometimes this piece of functionality can fail and throw an interesting message which doesn't seem to have many answers despite the best Google-fu.
Drupal Commerce entities all make use of the "data" attribute. The data attribute is a blob that contain just about anything you would like - for example, Commerce Shipping utilizes this for shipping line items. Recently there was a StackExchange question on the documentation of this attribute.
If there's one thing we've all grown to encounter in Drupal it has, and probably will always be, configuration management. Drupal 8 is looking to solve a lot of that. However a lot of us don't live in the Drupal 8 world and can't sit and wait for that "magical" day. Features gives us a lot of functionality, but after a certain point Features either breaks down or becomes too cumbersome to manage.