We've all figured out by now that the future of the web is for the sites we build to be accessible on as wide a variety of platforms as possible. The magic of responsive design means that one single web page can be viewed on a large range of devices. All of this works very well when we have the time to build our site from the ground up with this in mind, but how can an existing site be adapted to be more responsive? In particular, it's relatively easy to get Drupal to render image fields differently for different screen sizes, but how can existing IMG tags in inline content be displayed at different sizes, and how can a user place images on the page with a WYSIWYG editor without using separate image fields and still have them display correctly? Fortunately, there's an easy answer to this.
There have been previous attempts to fork Drupal, but apart from Pressflow, I can't think of any that gained any traction. Even there, the performance enhancements in Pressflow are mostly merged into core for the next version of Drupal. But its goal is to be a drop-in replacement, and is thus almost fully compatible with contrib modules. We use it ourselves as the core of many kPlatforms.
I recently had a problem with both devel and devel themer: neither were printing any messages to the page. When I called dpm() my debugging messages didn't show up, and when I enabled the devel themer module the "Themer info" popup wasn't appearing on any page.
Recently two clients wanted to have a left-column navigation menu which the user could hide or display using a link in the primary menu, one on a site with a theme based on Omega, and another using a theme based on AdaptiveTheme. It wasn't enough to call the jQuery function .toggle(), however, since by the time the page has been loaded the Omega base theme has already determined that the Sidebar First region has content and the width of the rest of the page elements have been determined accordingly. Fortunately, the Omega and AdaptiveTheme base themes use CSS classes to indicate which theme regions are active, and set the width of each region based on those classes. So, all we had to do was to swap the appropriate classes each time the we toggled the display of the menu.
The sysadmins here were doing some software upgrades the other day and asked me which versions of Tomcat and Apache Solr they should install on our shared Drupal hosting servers. The answer is a little complex, so I finally just drew them a diagram.
Note that in Drupal 7 there are two completely unrelated modules which can talk to Apache Solr: Apache Solr Search Integration, which has existed since Drupal 6 and is primarily developed by Acquia, and Search API Solr search, which uses Drupal 7's Search API family of modules. Both have their advantages and disadvantages, but overall the Search API approach provides more flexibility because it provides a standardized way for module authors to customize the results from several different search backends. With Search API you can also switch search engines with relative ease, should you ever choose to do so.
Here's the chart (click for a larger, more readable version):
Simpletest is great for unit and functional tests for your Drupal modules; you can also use Simpletest to automatically test your module updates and upgrade path. The process is similar in Drupal 7 and Drupal 8, and this article will show you how to do it, and include some simple example modules.