Drupal Dork - How-To

Trigger a javascript event when an autocomplete field changes

Brock — Tue, 29 Jan 2013 18:49:41 +0000

Related to my fieldset summary problem: autocomplete fields do not trigger the change event in Javascript, for some reason. I wound up stealing part of a patch I found somewhere (I would link to it if I could find it in my browser history) in order to override the autocomplete prototype function and trigger a new autocompleteSelect event when the user chooses an item in an autocomplete field. Just drop this function into a Javascript file in your module or theme:

(function ($) {
/**
 * Puts the currently highlighted suggestion into the autocomplete field.
 * Overridden from misc/autocomplete.js to add an event trigger on autocomplete
 */
if (Drupal.jsAC) {
  Drupal.jsAC.prototype.select = function (node) {
    this.input.value = $(node).data('autocompleteValue');
    // Custom: add an event trigger
    $(this.input).trigger('autocompleteSelect', [node]);
  };
}
})(jQuery);

Note that this goes inside the (function ($) {})(jQuery); block that appears in most Drupal Javascript files. If you're pasting into an existing file that already has them, you can omit the first and last line, and paste the function in between them.

Then you just bind to that event. Here's an example for the node author field on the node add/edit form:

$('input[name=name]', context).bind('autocompleteSelect', function() {
  // Value chosen in autocomplete field.
  // Do whatever you need to do.
  var chosen_value = $(this).val();
});

NOTE: After using this code for a few days I found an error. Drupal.jsAC is not defined on all pages, so an error is thrown when trying to set values on the prototype of a non-existent object. I've updated the code above to wrap it in a condition to check for Drupal.jsAC before overriding it.

One more update, from February 19, 2013:

It turns out that the select() function only runs when you click on an item in the autocomplete dropdown. If you use the arrow keys to select and item and hit enter to select it, the hidePopup() function runs instead (by way of onkeyup()), so you need to implement that one to. This is the core version, with only the autocompleteSelect trigger added:

Drupal.jsAC.prototype.hidePopup = function (keycode) {
  // Select item if the right key or mousebutton was pressed.
  if (this.selected && ((keycode && keycode != 46 && keycode != 8 && keycode != 27) || !keycode)) {
    this.input.value = $(this.selected).data('autocompleteValue');
    // Custom: add an event trigger
    $(this.input).trigger('autocompleteSelect');
  }
  // Hide popup.
  var popup = this.popup;
  if (popup) {
    this.popup = null;
    $(popup).fadeOut('fast', function () { $(popup).remove(); });
  }
  this.selected = false;
  $(this.ariaLive).empty();
};

How to force an update of the summary on field sets (in vertical tabs)

Brock — Tue, 29 Jan 2013 18:45:22 +0000

Please excuse the long title: it took me a while to figure this one out, so I want to make sure that other people can find this when they need it.

On my current project, I'm changing the node author field based on the value of a user reference field on the node type: when a content admin sets the node reference field, the node author field is changed to match that user reference field value. Since the author field is shown in a fieldset, I wanted the summary on that fieldset to update when this change was made. It took me a while to figure out how, but it's pretty simple:

// Update the field summary if vertical tabs are in use
var tab = $('fieldset.node-form-author', context).data('verticalTab');
if (tab) {
  tab.updateSummary();
}

Github: Creating Pull Requests for Existing Issues

Brock — Tue, 05 Jun 2012 19:39:06 +0000

Did a quick screencast with some coworkers today on the latest thing I love about Github. Last time, I covered how to create pull requests. This time, I explain how to create a pull request out of an existing issue. Since pull requests are basically just issues with commits attached, it's often undesirable to create a new pull request to address something reported in an existing issue, because you just wind up with two issues that address the same thing.

There isn't a way to do this through the Github interface, but the hub command line tool adds some special sauce for working with Github, and the thing I use it for most is opening pull requests for issues.

The quality is crummy, so turn up the quality to 480p.

Intro to Github Pull Requests

Brock — Thu, 26 Apr 2012 00:43:41 +0000

If your company is hosting code in Github, I sure hope you aren't committing directly to master. This quick screencast demonstrates how to use pull requests so that teammates can review code before it gets merged into the master branch.

Make sure you turn on HD so that the text is legible.

QuickPost Bookmarklet on Dreamhost VPS with Suhosin

Brock — Sat, 07 Apr 2012 17:00:52 +0000

This is probably the third time I've fixed this problem, so it seemed time to write down the solution.

On my personal sites, I make use of one my own modules, QuickPost Bookmarklet. The module geenrates a bookmarklet that allows you highlight text on a page and begin a new blog post on your own site from it.

My sites are hosted on a Dreamhost VPS, and once in a while, this bookmarklet stops working on me: if I select a longer piece of text, it won't pre-fill the body text area on the node add form. The title value still works, but not the body, suggesting that the server was ignoring (rather than truncating) that query value if it's too long.

The problem lies with Suhosin, which is enabled (I think?) by default. The offending setting is suhosin.get.max_value_length, which keeps getting set back to 512. I'm not exactly sure how it works, because I found that the values in the query string actually stopped working somewhere around 700 characters, but no matter.

The fix was just to add a line to my php.ini file. On my VPS, this is located at /etc/php53/php.ini.

suhosin.get.max_value_length = 10000

Restart Apache, and you're good to go.

D6: Garland Theme for Batch Processing

Brock — Fri, 30 Mar 2012 23:25:51 +0000

There's a long-running bug in the Drupal issue queue about a bug that I had to work around this week: when using the Batch API, your site theme will only be used for the first page. As the page reloads to show the progress of the job, the ugly, default Garland theme is used (well, that's not entirely true: it's actually Minnelli, but looks like Garland).

In most cases, this isn't a big deal: during a site install or when running update.php, it doesn't really matter what theme the admins see. In one client's case, though, we're using the Batch API to show progress of a multi-part donation that may take some time to process. In that case, you don't want regular site visitors seeing Minnelli: it's a jarring transition away from the site theme, and to anyone who isn't a seasoned Drupal user, it probably looks like something broke.

It took me a bit to find the solution to this problem. The issue I mentioned above is now being fixed for Drupal 8, but the menu system has changed enough that the patches posted there don't work with the older version of Drupal that I'm working with. After some digging, I found the solution: you need to override your maintenance theme.

Override the maintenance_theme variable in settings.php. Any variable that's retrieved using variable_get() can be completely overridden by setting it in the $confarray. In this case, you just need to add one line to settings.php:
$conf['maintenance_theme'] = 'my_site_theme';

Naturally, you'll need to replace my_site_theme with the name of your site theme.
Copy maintenance-page.tpl.php into your theme directory. Go into the modules/system directory at the Drupal root, find maintenance-page.tpl.php, and copy it into your theme directory—the one that matches the name you set for $conf['maintenance_theme'], that is.

Your site theme will now be used for every step in batch processing. It's important to also note that this theme will also be used if you actually do put the site in maintenance mode, since that's what you're overriding. Minnelli will still be used for update.php, though.

I'm not entirely certain that the second step is necessary, since a quick test shows that the batch process still used the site theme even when I removed maintenance-page.tpl.php from the theme directory. It may only be needed for actual maintenance mode, but the comments in settings.php say to copy it, so I copied it.

Local Settings Template

Brock — Sun, 22 Jan 2012 20:22:09 +0000

A couple months ago, I wrote about our strategy of using local settings files here at Jackson River.

I was setting up a new development site on my machine the other day, and realized that I've been consulting that blog post a couple times a week to copy over bits of code that were missing from various dev sites. It seemed like a good idea to move it into a gist:

<?php
/**
 * @file
 * local.settings.php
 * 
 * This settings file is intended to contain settings specific to a local
 * development environment, by overriding options set in settings.php.
 * 
 * Include this file from your regular settings.php by including this at the
 * bottom:
 * 
 *   @include('local.settings.php');
 * 
 * Placing this at the very end of settings.php will allow you override all
 * options that are set there. Prefixing it with the @ suppresses warnings if
 * the local.settings.php file is missing, so you can commit this to your repo.
 */

// Toggle the use of memcache.
$_use_memcache = FALSE;

// Toggle the output of devel debugging/logging.
$_use_devel = FALSE;

// Path where all contrib modules can be found.
$_contrib_path = 'sites/all/modules/contrib';

// The name of the database. This will also be used as the memcache prefix.
$_db_name = 'dbname';


$db_url = 'mysqli://root:pass4Root!@localhost/' . $_db_name;

// Allow anyone to run update.php, so that you don't have to log in with uid=1
// to do so
$update_free_access = TRUE;

// Set error reporting level to ignore notices and deprecated warnings. These
// should be turned back on during development to clean up any code that
// generates them.
error_reporting(E_ALL & ~E_DEPRECATED);
// Note that these options can also be moved into index.php, so that errors
// that occur before settings.php is processed will also be reported.
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);


// Prep the $conf array.
if (!is_array($conf)) {
  $conf = array();
}

// Save email messages to the log instead of sending them out. This is to
// prevent accidental email sends from a development site.
// Make sure you adjust this value if the Devel module is located elsewhere
$_smtp_library = $_contrib_path . '/devel/devel.module';
if (is_file($_smtp_library)) {
  $conf['smtp_library'] = $_smtp_library;
}

// Disable Secure Pages and Secure Site module functionality
$conf['securepages_enable'] = 0;
$conf['securesite_enabled'] = 0;

// Use a test payment gateway to prevent real transactions
$conf['uc_payment_credit_gateway'] = 'test_gateway';

// Lower the search indexing per cron run to prevent long cron runs
$conf['search_cron_limit'] = '10';

// Disable preprocessing of CSS and JS.
$conf['preprocess_css'] = 0;
$conf['preprocess_js'] = 0;

// Use environment indicator, if available.
$conf['environment_indicator_enabled'] = TRUE;
$conf['environment_indicator_text'] = 'LOCAL DEVELOPMENT';
$conf['environment_indicator_color'] = 'dark-red';

// Use memcache if available & enabled.
$_memcache_inc = $_contrib_path . '/memcache/memcache.inc';
if ($_use_memcache && is_file($_memcache_inc)) {
  // Configure memcache locally
  $conf['memcache_servers'] = array(
    'localhost:11211' => 'default',
  );
  $conf['memcache_bins'] = array(
    'cache' => 'default',
  );
  $conf['memcache_key_prefix'] = $_db_name;
  $conf['cache_inc'] = $_memcache_inc;
}
else {
  // Revert to Drupal core caching in case settings.php
  // is configured to use Memcache.
  $conf['cache_inc'] = 'includes/cache.inc';
}

// Devel settings
if ($_use_devel) {
  $conf['dev_query'] = 1;
  $conf['devel_query_display'] = 1;
  $conf['devel_execution'] = 5;
  $conf['devel_store_queries'] = 0;
  $conf['devel_store_random'] = 1;
  $conf['devel_xhprof_enabled'] = 0;
  $conf['devel_xhprof_directory'] =  "/var/www/xhprof";
  $conf['devel_xhprof_url'] =  "http://debianvm/xhprof/xhprof_html";
  $conf['devel_redirect_page'] = 0;
  $conf['devel_query_sort'] = "0";
}

And, since I use TextExpander as much as I can, I also made a snippet to grab the contents of this gist.

#!/usr/bin/php
<?php
// Make sure to set the Content dropdown to Shell Script in TextExpander
print file_get_contents('https://raw.github.com/gist/1633790/local.settings.php');

In order for this to work, make sure you set the Content dropdown above the snippet content to use Shell Script, like this:

Now when I type "llocalsett", I get a mostly-ready local.settings.php to start with!

Mimicking the WordPress "Press This" Bookmarklet in Drupal 7

Brock — Sun, 21 Aug 2011 22:39:18 +0000

Updated January 6, 2012: Since writing this post, I have wrapped this functionality up into the QuickPost Bookmarklet module for Drupal 7.

There was only one thing I missed after switching from WordPress to Drupal: the "Press This" bookmarklet that's available on every WordPress site. I find that I post a lot less without it, just because it made it so simple to make a quick blog post about someting I had seen online: highlight some text, click the bookmarklet, add some comments, and post.

I've finally got around to replicating this in Drupal 7, using the Prepopulate module, and I'm posting this so that others can make use of it. I'll start with the most basic version, then show you how I customized mine, and explain some gotchas to watch out for.

What does it do?

A bookmarklet is a bookmark in your browser's bookmark bar that has a javascript: URL instead of a regular one. When you click on the bookmarklet described in this post, a new window is opened to the admin page to create a new blog post on your site. The title of the post will be pre-filled with the title of the page you were viewing. If you select text on the page, this will be used for the body of your new post. Both of these can be changed, of course: they are just used as a starter so that you can quickly write a blog post about the page or article you were reading.

The Basics

First off, install the Prepopulate module on your site. This post is about Drupal 7 - I'm using the 7.x-dev version and it's working well enough for my purposes.

In order to use the methods offered below, you'll need to create a bookmark and replace the URL with one of the codes below. If you're just skimming the text here and not reading the explanations, you'll probably run into problems because there are things you need to change (but then again, you probably won't read this sentence either).

The Prepopulate version

There's a section on bookmarklets in the USAGE.txt file that's included in the Prepopulate module. The module author offers this code:

javascript:u=document.location.href;t=document.title;s=window.getSelection();void(window.open(%22http://example.com/node/add/content-web-link?edit[title]=%22+escape(t)+'&edit[body_field][body]='+escape(s)+'&edit[field_url][0][value]='+escape(u),'_blank','width=1024,height=500,status=yes,resizable=yes,scrollbars=yes'));

To use this for your own site: you'll need to replace example.com with your own domain. You may also need to change node/add/content-web-link, replacing content-web-link with the name of your blog post content type.

I found that this version did not work for me: the name used for the body field (edit[body_field][body]) was not working on my site. I'm not sure, but this might be because I upgraded from Drupal 6. I had to use edit[body][und][0][value] instead, as you'll see below. If you use this version, you may need to make the same change.

My version

This is the URL I used for my Quick Post bookmarklet:

javascript: var siteURL='www.drupaldork.com', nodeType='post', d=document, w=window, e=w.getSelection, k=d.getSelection, x=d.selection, s=(e?e():(k)?k():(x?x.createRange().text:0)), l=d.location, e=encodeURIComponent, url='http://'+siteURL+'/node/add/'+nodeType+'?edit[title]='+e(d.title); if(s) { s='<blockquote>'+s+'</blockquote>'; s+='\n\nfrom <a href="'+l+'">'+d.title+'</a>'; url+='&edit[body][und][0][value]='+e(s);} a=function(){if(!w.open(url,'quickpost','toolbar=0,resizable=1,scrollbars=1,status=1,width=1024,height=570')) l.href=url;}; if (/Firefox/.test(navigator.userAgent)) setTimeout(a, 0); else a();void(0)

I actually took the code that WordPress uses for the Press This bookmarklet and re-purposed it for use with the Prepopulate module, then made some tweaks of my own:

Put the site URL and node type in variables at the very beginning, so that they're easier to change.
If any text on the page is selected, put it in a blockquote, and put a link back to the page at the bottom.

As noted in the previous section, the default name for the body field in Prepopulate, edit[body_field][body], did not work on my site, and I had to use edit[body][und][0][value].

To use this for your own site: Update the values of the siteURL and nodeType variables. You may also need to replace edit[body][und][0][value] with edit[body_field][body]. You can check this by selecting text on a page before clicking the bookmarklet: if the selected text does NOT appear in the body field, you probably need to use the other version.

Expanded Javascript

If you want to make some of your own customizations, here's the expanded version of the Javascript. Just make your changes, then remove all the comments and line breaks to make a minimized version that can be used for your bookmarklet.

javascript: var siteURL='www.drupaldork.com', nodeType='post', d=document, w=window, e=w.getSelection, k=d.getSelection, x=d.selection, s=(e?e():(k)?k():(x?x.createRange().text:0)), l=d.location, // All text from the page needs to be encoded in the URL e=encodeURIComponent, url='http://'+siteURL+'/node/add/'+nodeType+'?edit[title]='+e(d.title); // If text was selected on the page, wrap it in a blockquote and add it to the URL if(s) { s='<blockquote>'+s+'</blockquote>'; s+='\n\nfrom <a href="'+l+'">'+d.title+'</a>'; url+='&edit[body][und][0][value]='+e(s); } a=function(){ if(!w.open(url,'quickpost','toolbar=0,resizable=1,scrollbars=1,status=1,width=1024,height=570')) l.href=url; }; if (/Firefox/.test(navigator.userAgent)) setTimeout(a, 0); else a();void(0)

How I Manage My Generic Drupal Dev Sites

Brock — Sat, 02 Jul 2011 06:33:37 +0000

On my machine, I have two local sites I use for developing and testing modules and patches: http://d6.local and http://d7.local. After manually wiping and re-creating these sites several times in between some tests, I realized I was doing it wrong and wrote bash scripts to do it for me.

Now, I have templates for each of these sites. Whenever I want to start with a fresh dev site with some basic modules installed (like Admin Menu, Admin Role, and Devel), I run a quick bash script that drops and re-creates the database, imports a SQL file, and replaces the entire webroot directory with the contents of a tarball. I did have to manually setup the site, create my admin user, and enable the modules when I first set all this up. Now, I can easily update that template when I need to - for example, when there's a new versions of the Drupal core released.

Here's my setup:

The webroot for the each version of Drupal are in ~/Sites/. I've got ~/Sites/d6.local and ~/Sites/d7.local, specifically.
My two bash scripts, deploy and recreate, both live in ~/src/templates.
Alse in ~/src/templates, I have a sub-directory for each version of Drupal: d6 and d7.
Within those version-specific sub-dirs are db.sql and files.tar, which are used as the template.

When it's time to refresh my dev site, I go into ~/src/templates and run deploy with the version I want to refresh, like so: ./deploy 6. Running this script will execute this process:

Drop and re-create the database. This is to make sure that I don't wind up with stray tables left behind by modules I had been working on before.
Import db.sql from the subdirectory for the version specific (in this case, d6).
Remove the webroot directory (in this case, ~/Sites/d6.local).
Re-create the webroot directory by expanding files.tar, also found in the version-specific subdirectory.
Use Drush to clear all the caches, just to be on the safe side.

Now I've got a fresh dev site at http://d6.local. As I mentioned, I created the admin user and enabled some modules when I first setup the site, so after deploying from the template the site is ready to go.

As of tonight, I can also re-create these templates from the database and file structure. My recreate bash script is similar to deploy, but in reverse: it will take a snapshot of the site that's currenly running at http://d6.local and save that as the template for future deploys. Running ./recreate 6 will execute this process:

Move the existing files.tar and db.sql into a backup directory, just in case.
Use Drush to clear all the caches.
Dump the database to db.sql.
Tar up the webroot directory into files.tar.

When new versions of the core or contrib modules come out, I just update my local copy of the site and run the recreate script.

It's a pretty handy setup, and would be easy for other people to repurpose. If you want to use these scripts (the code is below), you may need to adjust the code to fit your own setup because of assumptions I made. These were the assumptions I worked with (using Drupal 6 as the version for these examples):

Webroot is ~/Sites/d6.local.
Templates are stored in ~/src/templates/d6.
Database is named dev_d6.
Drush alias is named @d6.local, just like the webroot subdirectory.

You'll also need to modify the code to set the MySQL username and password for each line that runs MySQL.

And now for the code:

deploy

#!/bin/bash
if [ -z "$1" ]; then
	echo "Usage: ./deploy drupal_version, for example: ./deploy 6"
else
	versionname=d$1
	deploydir=~/src/templates/$versionname
	sitesdir=$versionname.local
	sitesfullpath=~/Sites/$sitesdir
	dbname=dev_$versionname
	
	if [ -d "$deploydir" ]; then
		echo "Re-deploying from site template"
		echo "STICK AROUND - there's a sudo call in here so we need your password"
		
		echo "Re-create the DB, so no stray tables are left behind"
		mysql -uuser -ppass -e "DROP DATABASE $dbname"
		mysql -user -ppass -e "CREATE DATABASE $dbname"
		
		echo "Import DB"
		mysql -uuser -ppass $dbname < $deploydir/db.sql
		
		echo "Untar files"
		cd ~/Sites
		sudo rm -rf $sitesdir
		tar xfz $deploydir/files.tar
		
		echo "Clear caches"
		drush @$sitesdir cache-clear all
	else
		echo "The deploy directory can't be found: $deploydir"
	fi
fi

recreate

#!/bin/bash
if [ -z "$1" ]; then
	echo "Usage: ./recreate drupal_version, for example: ./recreate 6"
else
	# Prep a bunch of vars
	versionname=d$1
	deploydir=~/src/templates/$versionname
	sitesdir=$versionname.local
	sitesfullpath=~/Sites/$sitesdir
	dbname=dev_$versionname
	backupdir=$deploydir/backup
	timestamp=`date +%Y.%m.%d-%H.%M`
	
	# Only continue if the given version number corresponds to a site directory
	if [ -d "$sitesfullpath" ]; then
		echo "Re-creating template files"
		
		echo "Backup previous save"
		# Make sure the backup directory exists
		if [ ! -d "$backupdir" ]; then
			mkdir $backupdir
		fi
		mv $deploydir/db.sql $backupdir/db-$timestamp.sql
		mv $deploydir/files.tar $backupdir/files-$timestamp.tar
		
		echo "Clear caches"
		drush @$sitesdir cache-clear all
		
		echo "Dump DB"
		# Dump DB
		mysqldump --opt -uuser -ppass $dbname > $deploydir/db.sql
		
		echo "Tar files"
		# Change into Sites dir and re-tar the dir
		cd ~/Sites
		tar -pczf $deploydir/files.tar $sitesdir/
		
		echo "All done!"
	else
		echo "The sites directory can't be found: $sitesfullpath"
	fi
fi

Drush with Homebrew & MAMP Pro

Brock — Wed, 12 Jan 2011 13:57:01 +0000

Sometime over the past few weeks, Drush stopped working for me. I could run drush st just fine, but anything that actually touched the database (like drush cc or drush up) gave me the dreaded "Drush was not able to start (bootstrap) the Drupal database" error. And since I'm always tweaking and changing settings on my system, I had no idea what I had done to break it.

My first thought was that I had killed it with Homebrew. I recently nuked my manual install of Drush so I could use Homebrew to update it every now and then. Once you install Homebrew, you can have Drush installed and configured really easily: brew install drush The same command will update it, too. But that wasn't the problem.

I'm also using MAMP Pro for local development, so that was the next culprit. I'm really not sure what happened - or for that matter, why I was able to run MAMP at all - but the php binary was no longer executable (or maybe, never had been?). This didn't seem at all like it would be the problem: after all, Drush was executing, and claimed to have a problem accessing the database. Still, changing the permissions on that binary did the trick:


sudo chmod a+x /Applications/MAMP/bin/php5.2/bin/php
sudo chmod a+x /Applications/MAMP/bin/php5.3/bin/php

Since I sometimes have to switch between PHP 5.2 and 5.3 for testing, I made sure to hit both versions.