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.
For a recent project I was tasked with migrating the old Twitter 1.0 API widget to the new Twitter embedded timeline functionality.
The original field was a simple 255 character textfield:
On a recent large Drupal project we were finding that the variable table was holding around 4 MB of data. The issue of course with this is that this is loaded into memory on each page request regardless of whether or not you use it. Another issue is that the variable table holds serialized data, and there is an additional CPU overhead of actually de-serializing the data as well.
How to cleanly remove the statistics
There are a number of ways you can remove page views from Google Analytics, for example:
The code below is pretty standard Drupal code. It sets up a couple of menu items, and a couple of pages. One page displays a link "Click to load" and upon clicking on that link you are taken to a page that has a list of links to some common search engines. Pretty straight forward.