Drush sql-sanitize cleanses the core user information, but what about all those profile fields you added?
Many Drupal sites use Google Analytics to capture statistics on page views, but often, that's as far as it goes. That's fine if the only events that you're interested in are page loads, but what about all the other user interactions that happen on pages? With a bit of extra work, we can capture statistics on those too using the custom events feature built into the Analytics API.
Many site owners use Google Analytics to capture user statistics. Usually people look at page views, number of pages visited, bounce and exit rates. Google also tells you the time users spent on a page, but what about all the other user interactions that happen on single pages?
At Code Enigma, most of our Jenkins builds post a git log into one of our IRC channels on completion. This helps the ops team to keep an eye on what's going on and to quickly spot any build failures. It also gives us a chance to see the commit messages that people are posting.
Our own developers are pretty well behaved when it comes to making meaningful commit messages (they know they’ll be teased mercilessly if they do anything daft!), but for some hosting-only clients, we have seen some classic examples of meaningless commit messages.
Drupal performance testing: A scenario where memcache can actually impair performance
We were recently asked to investigate poor performance on a Drupal 6 site. Memcache was enabled, but a siege test was still showing poor results.
Massaging Drupal 6 data into Drupal 7
One of our clients is redeveloping the front-end of their site and wanted to take the opportunity to upgrade from Drupal 6 in the process.
I recently passed the 5 year mark on drupal.org. It got me thinking about all the different communities that helped me along the way.
Back at the start of 2008, I was in a major rut. I was stuck in a job that I didn't much care for, and had been for almost 13 years.