As a course of developing for larger Drupal sites, you typically find yourself having multiple environments, one for development, one or more for staging or user acceptance testing, and another for production (and perhaps disaster recovery).
One thing that always comes up is making Drupal "environment" aware, so it knows how it should behave, what modules should be turned on (or off) and what servers it should be talking to for instance.
What is Dashing
Dashing is a Sinatra (think ruby but not rails) based framework that lets you build dashboards. It was originally made by the guys at Shopify for displaying custom dashboards on TVs around the office.
Why use Dashing
Dashing makes your life easier, freeing you up to focus on more inportant things - like what data you are looking to display, and what time of widget you want to use.
Features of dashing:
So Google Analytics has a new version of Google Analytics dubbed "Universal Analytics", which has a bunch of new features, that could be handy for your website. I would dive into exactly what they are here, as you can read about them on Google's own website.
In this post I will go through the steps to upgrade the Google Analytics 7.x-1.x module to the new 7.x-2.x version that supports Universal Analytics.
As of the 28 February 2014, Drupal 8 now requires a minimum PHP version of 5.4.2. For background information read the drupal.org issue.
This places everyone running Ubuntu 12.04 LTS in an awkward situation as the PHP version bundled with this release is PHP 5.3.10.
Luckily there are options to solve this:
As your site grows with the number of modules, the amount of memory and SQL queries required to perform a full bootstrap grows. Even though your AJAX callback might only need to perform a single SQL SELECT query, sometimes Drupal spends a lot of time loading and executing code that will never be used.
As part of the series of blog posts on the top 10 OWASP web application security risks and how to defend against them in Drupal 7, here is the first post in the series. This post deals with the top security hole - classified as "injection".
From the OWASP top 10 security risks:
Being able to work out when an issue started occurring an what impact it is having on real people using your site is critical business information that too often gets overlooked.
Existing (core) modules that can help
Drupal core ships with a few modules that go some way as to helping you track down application errors:
Throughout the course of building large complex Drupal sites, you invariably end up writing a suite of custom modules and features to produce the required functionality and behaviour for the site.
One issue is that when you do create these custom modules, the core update status page attempts to find new versions of your custom modules on the Drupal.org update server. Of course this check fails, but it takes up precious time to work that the module is not on drupal.org and also the grey box looks kind of ugly.
How to install the Backbone module on the Drupal 7 platform from a standard installation. This tutorial takes you through the steps from a vanilla install to having the backbone_example sub-module working.
Drupal.org has this information, but it is largely scattered around on these URLs:
It can be hard to find a real life example on how to update your contributed modules with the new Drupal 8 architecture.