5 Tips and Tricks

1. Use http://drushmake.me/ to generate a decent base make file for new projects.

This is also a handy way to see popular modules and libraries that have somehow been beneath your radar.

2. Patch your modules with Drush.

The syntax is fairly straightforward. You can also chain patches by applying one and then applying the next.

projects[project name][patch][] = "url to patch"

For example, to patch the CAS module for using SSL/TLSv1 you would do the following: projects[cas][patch][] = "http://drupal.org/files/enforce_tlsv1_0.patch"

3. Download your custom modules via git.

To do this you need to tell Drush make to use git and then you simply provide the public repository URL.

projects[wwuzen_gsa][download][type] = "git"
projects[wwuzen_gsa][download][url] = "https://bitbucket.org/wwuweb/wwu-google-search-appliance.git"
projects[wwuzen_gsa][type] = "module"

Unlike normal make projects you download you do not need to provide a version, but you do need to state that it is a git project and provide the URL. Whatever you put in the [] after the word projects is what the directory will be created as.

4. Move sub-directories within libraries to their proper location.

Often, external libraries do not extract from a tar or zip with the file your Drupal module is looking for. It might be buried inside of a sub-directory. With Drush 5 we can move them upon the build.This is an example from the CAS library.

libraries[CAS][download][subtree] = CAS-1.3.2/

With the subtree identified, Drush make will dowload and extract the library like normal, and then move the contents of the sub-directory CAS-1.3.2 into the main directory CAS. It might take a few attempts to figure out whether you need a / in front of the directory or not but the end result is a library extracted properly.

5. Move libraries upon install anywhere you would like.

The feeds module loves to have the Simple Pie XML parser library inside of it's own module directory. What a pain. However, Drush make can move it for us.

libraries[simplepie][destination] = "sites/all/modules/feeds/libraries"

Just plop in the destination you would like to have the library moved to and the script makes it so. (Pun intended).

I had one criteria for a successful solution; my users should not have to do anything to make their table responsive. I did not want them to right click on the table and add a class, I didn't want them to have to build all of their tables with views, just plop in a ckEditor table and hit save.

A secondary criteria was that the solution should be lightweight since it is primarily to be used by users on mobile devices and we don't all have 4G LTE in our offices and living rooms as of yet. All of the solutions mentioned above use some sort of CSS hook to indicate that the table needs to become responsive at certain breakpoints. The lightest weight solution for me turned out to be Zurb's approach.

To automate the insertion in the HTML of a CSS class I turned to the Flexifilter module. Not enough people use this module but what it allows you to do is to create a Drupal input filter, so really an output filter, on anything that is formatted, like your WYSIWYG output.

After enabling the module you need to go to Structure -> Flexifilters -> Add New Flexifilter.

Configuring a filter.

Inside of a filter you have several options but the Pattern Based Text Replacement widget works with regex. Once a filter is configured, you have to enable it. Once enabled, head over to your text format configuration screen and enable your new filter.

Configuration -> Content Authoring -> Text Formats -> Full HTML. I put the filter as the last item to be ran so that I can ensure the class I want added is actually added.

Enable the text filter and place it as the last filter to run.

So now we have a class called responsive being added to tables folks create. How does this help us? We need to leverage Zurb's great work to answer that. You can grab the source from their GitHub project page. We want two of the files, responsive-tables.css and  responsive-tables.js. You can discard the rest. Place the css file in your theme/css directory and the js file in your theme/js directory.

Open up your theme.info file and tell Drupal about these two new files. In a Zen sub-theme it looks like this:

stylesheets[all][] = css/responsive-tables.css
; Optionally add some JavaScripts to your theme.
scripts[] = js/responsive-tables.js

Next, open up the responsive-tables.js file as we need to wrap it in a Drupal safe closure. At the very top of the file add

(function ($, Drupal, window, document, undefined) {

and at the very bottom add

})(jQuery, Drupal, this, this.document);

This allows the code that the Zurb folks wrote to run without conflict with the other jQuery that Drupal executes. That is pretty much it. Save those files. Go to Structure -> Appearance to reload the info file and your table should now be responsive at small window sizes.

Zurb style responsive table in Drupal 7.20.

On a recent project I had to have a div slide to the left when a link was clicked. I thought that would be easy as Drupal 7 has the jQuery UI packaged by default. So I coded up a bit of jQuery that used a .slide() function but nothing happened when clicking the link. Looking at the FireFox JavaScript console I saw an error stating that slide was not available.

Why not?

It turns out that even though jQuery UI is shipped with Drupal none of the UI effects are turned on by default. That is a good thing as most folks, myself included, will not use many if any of the packaged enhancements.

The Solution:

Using my trusty Google skills it didn't take long to find a great post by Andy Carter detailing how to include effects from the UI library in Drupal 7. One caveat that his post and others do not explicitly state is that the system library includes the ui and the effects array. For a short while I was trying to include the slide effect like so.

  drupal_add_library('system','ui.slide');

This does not work. I needed to use the effects.slide. The key is to look at what is inside of $libraries[''] and using that in your call. All of the available libraries provided by the system can be found on the system_library page.

Here is a complete example of what ended up being included in template.tpl.php.

function wwuzen_preprocess_page(&$variables, $hook) {
   //Add the slide effect for our search box
  drupal_add_library('system','effects.slide');
}

Notice that I use effects.slide rather than ui.slide. With that change in place my expected behavior executed properly.

require_once(/home/WWU/bronsem/cmssites/test/sites/wcedev.atus.wwu.edu/modules/entity/includes/entity.inc):[warning]
failed to open stream: No such file or directory bootstrap.inc:3066
PHP Fatal error:  require_once(): Failed opening required '/home/WWU/bronsem/cmssites/test/sites/wcedev.atus.wwu.edu/modules/entity/includes/entity.inc' (include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in /srv/www/campusweb/cmssites/test/includes/bootstrap.inc on line 3066
Drush command terminated abnormally due to an unrecoverable error.   [error]
Error: require_once(): Failed opening required
'/home/WWU/bronsem/cmssites/test/sites/wcedev.atus.wwu.edu/modules/entity/includes/entity.inc'
(include_path='.:/usr/share/php5:/usr/share/php5/PEAR') in
/srv/www/campusweb/cmssites/test/includes/bootstrap.inc, line 3066

That is a pretty gross error. When that error occurs it can be nigh impossible to get your site running. Awhile ago a colleague, Vid @ Developments, mentioned the drush rr command which is not built into drush. Go to http://drupal.org/project/registry_rebuild and get it. It is super simple, cleans up random cruft like above. Often those types of messages occur when you are removing a module from your sites/sitename/module folder when you want to use the version in sites/all/modules. If you run into errors, give drush rr a whirl.

Steps to install

1. Navigate to a location where you can run drush commands. For most of us our home directory is fine.
2. Type "drush dl registry_rebuild" without the quotes and hit enter. Now it is installed. You should see something like: Project registry_rebuild (7.x-1.9) downloaded to /home/WWU/bronsem/.drush/registry_rebuild.                    [success]
   Project registry_rebuild contains 0 modules: .
3. Now navigate to the site that is causing you issues and run drush rr.

Supposedly you can run the command from a URL as well. That might be useful if you are on a box that doesn't allow you access to the command line. For full documentation check out the project page.

Wicked cool utility that makes drush even more awesome. Thank you omega8cc, rfay, and  q0rban.

It works great in OS 10.8.2.

Thank you Peter and Lance!

Direct Link to Peter's write-up: http://peterdowns.com/posts/open-iterm-finder-service.html

I am primarily a Drupal developer these days and during the start of the talk I kept nodding my head and telling myself, Drupal can do that. While Drupal can accomplish this it can be a fairly poor user experience. Each piece of structured content is basically a form field and for a small piece of content like a blog post, there could be 5-10 fields. To solve this we can try to help the user by pre-populating the date, time, location, etc... She goes onto present three key points of what a CMS should do in the future.

1. The CMS should help content editors make good decisions.
2. The CMS allows the designer to make semantic decisions so the editor doesn’t have to.
3. The CMS protects the design and architecture decisions made for the site.

I would like to say that a properly constructed Drupal 7 site very nearly presents the future CMS now. However, Jeff Eaton of Lullabot just published an interesting article, Inline Editing and the Cost of Leaky Abstractions. How will structured content survive inline editing?

"Structured content is not a silver bullet."

Jeff's article and Rachel's talk both emphasize a careful balance. The colleague who sent me the talk and I discussed this as well and balance is the actual hard part. We can structure everything as unique fields and attach metadata behind the scenes, etc... but it then borders on insanity as you look at the form. Again we abstract some of the complexity and hide it from our user, that is part of our job but for complex data a big form is overwhelming. Big forms are nothing new and many strategies exist to solve them, and using contextual overlays we can break the forms down in Drupal into manageable chunks. This is not yet the norm.

"Avoid directly inserting HTML into content."

I applaud Rachel for discussing this topic. I do not agree that markdown is an answer, mainly because I have always had a hard time with it. I like the idea of using a WYSIWYG type entry system for users where they can highlight some text and italicize or bold a word. Not because it is familiar for users but because it is fast. However, this again comes back to a balance. If I strip all HTML or do not give a user a chance to emphasize text in anyway, I must ensure the design accounts for this. Perhaps the only bold text is the subheading for the title of the page. The only text that is italicized is the image caption. I think this is brilliant but difficult for me to achieve.

Here is to the future CMS!

Thank you Rachel for discussing the issues above. While it may be difficult for me to achieve the balance I have discussed, we all need to struggle to find answers to these issues. The web will be a better place for it.

Monitoring one or two Drupal sites can be done by logging into the status report every few days and reviewing settings, looking at your watchdog log, and reading the emails the sites send you. However, as you run more and more sites that process becomes overwhelming and can take up a large amount of time. A few services exist to help monitor all of your sites in one place, Droptor, Drupal Monitor, and Acquia all provide really slick solutions. However, if you want to roll your own due to cost, corporate security, etc... the Drupal community has developed several tools leveraging Nagios.

I wanted to set this up to monitor the sites I manage and chose to use Icinga, a fork of Nagios and openSUSE 12.2 as that is consistent with our environment. Currently I am doing this as a proof of concept project and it is running inside of VirtualBox on an older Mac. The Drupal projects that I am using are the following:

• Nagios Monitoring
• Production Check & Production Monitor

These two modules first let us talk with our Nagios server but also provide most of the stats you can find in the paid services. On initial install the results are not all that pretty to look at but I believe there are ways to fix that and I would rather have comprehensive than pretty any day.

Installation was inspired by the post at awebfactory. There is currently no write-ups on how to do the install if you are using Icinga but since it is a fork of Nagios all of the steps are quite similar. I still know very little about Nagios so if you see a goofy config file please improve upon it. The readme file that accompanies the Nagios Monitoring module is fairly comprehensive and if using Icinga use the Nagios 3 style configuration options. Here are four tips that I wish I had known while setting this up.

4 Tips

1. You must define a host in your .cfg file you create for monitoring the Drupal sites. The README assumes you have done this already but if you are creating a monitoring server from scratch this is news. Add the following at the top of the hostgroups.cfg file the instructions ask you to create.

   define host{
           use                     linux-server
           host_name               domainname.edu
           alias                   DevVM ; You will see what you put here in Icinga
           }

2. The unique string you generate for use in the module and within Icinga goes where the instructions have the words unique identifier.
3. Initially my Drupal check was not returning any results. I got an error "Service Check Timed Out." My dev server is a little pokey so I needed to edit the service_check_timeout line in icinga.cfg from 60 to 600. I chose 600 because this article uses it, very scientific, I know.
4. The SUSE Icinga package places Icinga in /etc/icinga, /etc/init.d/icinga check_verbose checks your settings in the .cfg files you have edited/created and /etc/init.d/icinga restart restarts the service.

Installing Icinga

Thankfully there is a package for Icinga in the openSUSE repositories. I installed this using the GUI tools but if I move out of a proof of concept phase I would do this with an openSUSE box run level 3 so I will try to show the command line install options rather than how to use Yast. This generally just involves following the documentation at http://docs.icinga.org/latest/en/quickstart-icinga.html.

Install the dependencies:

$ zypper install gd gd-devel libjpeg libjpeg-devel libpng libpng-devel
$ zypper install net-snmp net-snmp-devel perl-Net-SNMP

Create a user named icinga, please follow the instructions at the link above.

$ zypper install thttpd
$ sudo vi /etc/icinga/etc/objects/contacts.cfg

Change the email address associated with icingaadmin to one that you can receive email at. ESC : wq ENTER to exit.
Set the password for icingaadmin

$ htpasswd -c /usr/local/icinga/etc/htpasswd.users icingaadmin
$ sudo /etc/init.d/apache2 reload

Make sure Icinga starts when you boot.

$ chkconfig --add icinga

$ chkconfig icinga on

Verify everything is good with your initial configuration.

$ sudo /etc/init.d/icinga check_verbose

Start Icinga

$ sudo /etc/init.d/icinga start

Navigate to http://localhost/icinga/ and login with icingaadmin and the password you set earlier.

Install the Nagios Drupal Check service

The steps in the README file are correct for openSUSE. Just use the Nagios 3.x version of the commands and follow tip number 1 from above.

Final Result

A nagios alert showing issues with a site I have in dev.

I started monitoring a site I have on my devVM and it shows me a boatload of issues. Core is out of date, stuff is turned on that shouldn't be for a production site, modules need to be updated, etc... The beauty of this is that I simply need to turn the module on for each site I want to monitor, update my hostgroup definition in hostgroups.cfg and I have instant monitoring. I hope to provide further details such as NRPE on the remote host, selective alerts, and a prettier interface.

Thank you to everyone I have linked to in this article and to the developers of the fantastic Icinga, Nagios, and Drupal modules. On a happy note, Acquia itself uses Nagios to monitor their sites in the Acquia cloud.

With Drupal 7 the media module is used to handle media. No problem, however it doesn't do anything to allow for automatic captions to appear. However, it does allow us to show users when they upload an image that an alt tag is a good idea and a title tag can be used. Most auto-caption techniques rely on that title tag to be used as the caption and you show it with a bit of javascript and CSS.

My goal for the end user was to have them get captions for free but have the ability to turn them off. I do not want them to assign a special class for a caption to appear because in my use case, the majority of folks want the captions. However, to disable a caption I want a fairly straight forward method that can be accomplished in the WYSIWYG editor.

To make this work I leveraged several contrib modules and now have it working except it still will not automatically show in the WYSIWYG editor. That last issue seems to be somewhere that improvements can still be made.

Ingredients (List of Modules):

• Media Module 7-x.1.2
• Insert
• Image Caption
• WYSIWYG with the CKeditor Library
• HTML Purifier (Not needed if you allow full HTML)
• Any dependencies of the above modules, i.e. ctools, views, etc...

Configuration:

Go ahead and download the modules and install them on your site whatever your preferred method. You can enable them as well.

Now, most of these modules auto-configure themselves. For this example we will use the basic page content type but add an image field.

Basic page content type configuration screen.

Notice that we use the image widget which is augmented via the media module. The next screen we need to edit is the images field. Make sure to check the Enable Alt field and Enable Title field.

Don't forget to enable the alt and title fields.

Right below those check boxes, if you have the Insert module enabled you will see a collapsed field labeled insert. Expand it. Check the Enable Insert button check box. Choose the styles you want to make available to your users. Add the word "caption" without the quotes to the Additional CSS Classes text field. This will add the caption class to every image inserted into your nodes. This makes the caption magic happen automatically, as long as you fill out the title field with each image, because the image caption module looks for the class caption on all images.

Enable the insert button, choose some styles, and add caption to the classes field.

Make sure you have the image caption module enabled and let's make a new test node.

Go to Content -> Add Content -> Basic Page and title your new node to test the image caption.

Then go down to your image field and upload a new image or graphic. Fill in the alt field and the in the title field add the text you want for your caption. Click the insert button near the style dropdown menu and the image appears in your post.

Now, click the preview button and you will see the caption appear beneath your image. Styling the caption class is up to you.

Look ma' a caption!

Fairly awesome.

Why this approach:

OK, so why did I decide to do it this way? There are a few other modules, notably jCaption. You could also make each image a node and then attach a caption field to the image. That approach seemed unrealistic as then I would have to easily allow authors to import nodes, into their post in an easy manner. However, the author would have to create at a minimum two nodes/entities just to create a page with one image. That doesn't entice many people.

jCaption looks interesting except that you cannot turn off captions. Anything with a title attribute gets a caption. Sometimes, captions are not appropriate but people still want the contents of the title attribute to appear on mouseover. With the image caption module because the caption is controlled by a class, the user can edit the image in their WYSIWYG editor and remove the class. In the next image you can see the caption class has been removed, meaning no caption will appear. This gives control to the page creators which is a fundamental goal of CMS.

No caption class means no caption accompanying the image.

Improvements:

I am happy with this approach except for the fact that users cannot see the captions directly in the WYSIWYG. It would be fantastic if that were possible and it will require more research. Since the caption appears because of jQuery we would have to utilize a drupal behavior to fire whenever an image is inserted and then with ajax save the state of the page and add in the caption. It sounds messy.

I wish there was an easier way for users to disable the caption as well. It is not hard to go into the properties of an image but it would be great if they could just click the image and remove the caption class via a dropdown menu or contextual editor.

Overall:

This seems to be a robust approach that helps the user by minimizing the knowledge and time needed to add captions. I need to find a good way to alert them of how to remove a caption, but I am hopeful for the use of this technique.

Apparently, my little Belkin router cannot handle OS X's default 1500 Maximum Transmission Unit (MTU) setting. By altering it to 1453, a number referenced at OSX Daily, the sites once again worked.

The quick fix:
System Preferences > Network > Advanced > Hardware >  MTU: Custom -> 1453

Searching for the package with yum did not turn anything up. I did find the package at repoforge.org. We are running a 64bit install so we needed the 64bit RPM. Here are the steps to install.

$wget http://pkgs.repoforge.org/pdftk/pdftk-1.44-2.el6.rf.x86_64.rpm
rpm -K --nosignature pdftk-1.44-2.el6.rf.x86_64.rpm
sudo yum install jre-gcj
sudo rpm -Uvh pdftk-1.44-2.el6.rf.x86_64.rpm
$PATH
which pdftk

First we download the package and check that it a complete package with rpm -K --nosignature command. Then we install the dependency jre-gcj which is a Java Runtime Environment compiler. Next, we install the package using the update -U flag. Run $PATH to list our path and run the which command to verify it is installed in our path.

After that the Fill PDF module detects pdftk is installed and life is good.

RedHat's documentation on RPMs was fantastic and a big help in making sure this went smoothly.