In certain situations, you may need to have a deep look at the result of some process (deep as in at the DB level); one such situation is when you perform a mass update of data and verifying all went correctly would be relatively easy by diffing the before/after states, then splitting the removals/additions and doing some matching from one group to the other. Not all cases fall under this description, but when they do it's best to have some tooling to avoid spending lots of time and risking human error. Let's take a look at the script I wrote for that very purpose.
After years of hearing about DrupalCon Sprints but not having the actual experience myself (I'm one of those avid consumers of DrupalCon video recordings), DrupalCon LatinAmerica 2015 put the event almost literally in my front door (just a couple kilometers away). Let's share the awesome experience of teaming up with three Sprint-mates to get a D8 ticket closed (the first one for all of us, AFAIK).
A couple years ago I was gladly surprised by the Quickstart project, a prebuilt development environment for Drupal; after finding it extremely useful for speeding up my workflow I was sold on the idea of doing my dev work on a dedicated VM. Fast forward to now and I've been using Vagrant + Puppet for almost a year; after lots of iteration and little adjustments here and there I found myself having a very reliable env for my daily needs; also, I switched to a fully CLI-based workflow, which I've enjoyed so much. I think it's good enough to share with the community, so let's do just that.
Development tasks often require for the developer to compare how a given page looks on different environments. Even though the manual task of editing the URL is not a hard task, it's way better to have a quick way to do it. The mere act of stopping to think on how to adjust the URL affects the focus your mind has on the real dev task at hand. Let's see the bookmarklet I wrote to solve that.
Using Vagrant VMs for Drupal development is quite useful and offers many advantages. Since a very common tool for doing dev tasks is phpMyAdmin, it's a good idea to set it up with auto-login when provisioning the dev VM. Since I didn't find this explicitly done anywhere on the net, I worked a bit on getting it done and found a method that should be relatively easy to implement.
Since I found the Screencast Keys addon, I had a very strong feeling that there were a few aspects on which to improve it. Initially I just added a fade-out for the text and included a basic mouse widget. But I kept thinking it could be improved even more. After seeing what it has become after many additions, I concluded it had become very cluttered; thus, I decided to work on redesigning it, and that redesign just ended in an almost full rewrite.
XML Sitemap is a very useful module to get a proper sitemap.xml file for a Drupal site. Configuration is quite straightforward and usage is very intuitive, but there is a catch: moving custom links from dev to stage/prod is not as easy as exporting with Features. Let's take a look at a method for doing it in Drupal 7 by leveraging hook_update_N().
A few years back I started considering switching my daily tasks to Ubuntu, mostly after finding out how beautiful and usable is the Linux desktop when using Compiz (and configuring it properly). Personally, I like the minimalism of Gnome, so I just like vanilla Ubuntu.
But! as I started checking every aspect of the desktop experience to see if it matched my preferences, I found out that there were some issues that I would need to solve before being really able to switch and enjoy the experience. From the basic checks that I could do my daily chores to the adjustment of some details, I found a few things to work on. Today I'll share the way I found to get the sound effects I'm used to in the Windows desktop.
One of the good practices a Drupal developer must adhere to is keeping backups of a site, even if it's just a dev site. Since the advent of drush archive-dump much of this task is already automated; but there is still a missing piece to get it working seamlessly: purging old backups and keeping only recent ones. For this very need I just wrote a simple bash script that you can set up and use very easily.
The sole idea of having to set up an isolated site, download the module to be patched, enable it, perform the necessary changes, test them, create the patch and get it into an issue queue on drupal.org makes many people (including me) feel unwilling to do such a thing.
But the good news is that with a few tools it is possible to be contributing back to the community in a matter of minutes, yes minutes.