Drupal 7

In Drupal 7, Views allows you to easily create exposed filters and alter a lot of the logic involved.  However, sometimes you get requests to add text to the form or position things in ways that the Views UI does not allow for.

I've got two solutions that are arguably not as Drupal-like as I would like, but I've run into some dead ends on occasion with trying to fullfill requests with only Drupal-like alterations.  And of course if there are better ways to do it, I am open to them.

Using Search API you have lots of choices for indexing fields in a search index like Solr. However sometimes you need more than can be accomplished by using 'aggregate fields' in the Search API User Interface. Sometimes you need to create a new field (that does not actually become part of the entity and then do some processing on it to give it a value when indexed by the Search API.

First, declare the new field:

In Drupal 7, if you use Views in combination with a search index from Search API, and you try to use the Global: Result summary in the header or footer of the View, you may find that the total number of results matches the number of items on the page, not the total number of items in the search index.

To correct this issue, hook_views_pre_execute will make everything work as you would expect.

If you have used a Feature and removed a field from the Feature and reverted, only to find the field still present in your content type, this update is for you. Hook Update Deploy Tools now has a method (as of version 7.x-1.6) to remove a field instance from the content type. The method gives feedback as to the removal of the field, checks to see that it was removed, and reports whether it was the only instance of the field or not.

If you are already using hook_update_N() in your custom deploy module or within a Feature to make related database changes across your development and production environments, it is an easy step to just use variable_set() to make settings changes without locking them into a Feature with strongarm.  The problem is, variable_set() runs silent.

If you are using a deploy workflow with your Drupal website you may be reverting your Features through code.  One approach is to make the Feature take care of itself by adding an .install file to the Feature and then adding a hook_update_N() to the install.  This has some nice advantages of keeping your changes compartmentalized.  Translation: fewer merge conflicts on your custom_deploy.install.

After working on several sites that were using hook_update_N() in install files to handle continuous site deployment by enabling modules, reverting features, updating menus and setting variables, we (CivicActions) built a handful of methods to more safely support that and issue better feedback when running `drush updb` or using update.php. 

I use these commands to see drupal data, but not often enough to remember them when I need them.

Get the number of rows in a table:

When using Features module to move changes from one  development environment to the next, it can be tricky to track which Feature ought to be 'reverted' in order make the new code be incontrol.  Sure you can revert them all in one shot with `drush features-revert-all`, but that is pretty intensive to do especially on a production site and can lead to some race conditions.

This is a video introduction to the Drupal module Codit: Crons.

Codit: Crons uses the Codit framework to make the development of multiple cron jobs easy.  In most cases it ends up being both more flexible, and safer than custom coding hook_cron() in a custom module or Feature for a site.

Why should I consider using Codit: Crons?