Spelling, Internet Explorer, and Easier Linking

Currently, we use a plugin called LinkIt to handle linking between our pages (for a discussion of how we use it, see https://blogs.lanecc.edu/webteam/2013/02/05/common-pitfall-links/). LinkIt is pretty neat, and helpful. But it was always a pain for people to link to internal pages. We’d often get a scenario where someone wanted to link to some page, say, their department contact page. So they dutifully use LinkIt, and start searching for pages with titles like ‘contact’. But since every department has a contact page, they’d get fifty results and spend forever hunting for the right page.

Not helpful.

In fact, it was so unhelpful that people were directly pasting links to their pages into the page, meaning that when page titles changed, things started to 404, and things just got nasty. So I spent some time investigating why LinkIt couldn’t just figure out if a given URL is internal, and if so look up the node number and properly insert the link like a good little plugin.

Turns out the developers had already thought of this. Right there on line 388 there was a little todo that explained our problem. Like any responsible web site, we’re forcing page edits to happen on HTTPS. But for non-administrative users, we’re serving up most pages via HTTP (so we can take advantage of the speed our Varnish server provides us). So when an editor copied a link into LinkIt, the server would check the link (for example, ‘http://www.lanecc.edu/contact’) and see if the start of that link matched the scheme and server name of the current page. Since we’re forcing https, that’d end up being something like https://www.lanecc.edu/node/1337/edit. The server name matches, but the scheme doesn’t, and LinkIt would report that this link was external.

One simple change later, and now when you paste in a link it decides not to check the scheme. So from now on, if you’re linking to an internal page, just paste your url into the top box, and you’ll see something like this:

The new LinkIt dialog, showing a box that appears when you paste an internal link in the search box

When that little green popup appears, simply click on it and LinkIt will automatically identify your node number and insert it as the target path. Click Insert Link, like normal, and you’re good to go.

The second change is that we got spell check working on Internet Explorer 9. For others with a similar problem, our issue was on Drupal 7, using TinyMCE 3.something, with the wysiwyg_spellcheck module and wysiwyg modules enabled. Turns out that when you enable the module, you also need to make some changes to wysiwyg/editors/tinymce.inc. In the function wysiwyg_tinymce_settings, you need to add add another key to the settings array:

'spellchecker_rpc_url' => '/libraries/tinymce/jscripts/tiny_mce/plugins/spellchecker/rpc.php',

You should, of course, adjust that path to whatever is appropriate for your site. One final note, the problem described with LinkIt is actually fixed in the new 7.x-3.x version. But we’re using the older, 7.x-2.x version, which is no longer in active development (and which has no migration path to 7.x-3.x)

More New Features

Two more new features to report.

First, you can now add a caption to your images. When you insert an image, as always, you’re prompted with a dialog where you can enter a title, and where you can enter a description. At the end of last week, we started automatically converting whatever you put in as the title of your image to be a caption, appearing in boldface just below the image.

It’s important that these two fields – title and description – are used correctly. When implementing this feature, we found close to two hundred images where they were exactly the same text. Imagine a screen reader comes across this picture:

A cat chewing on a monitor
A cat chewing on a monitor


Since both the alt text and the caption are the same, and it wants to make sure to read all the text to you, it’ll actually read the exact same thing to you twice! And don’t get me started with the people that used the file name (“cat123.jpg”) as the alt text, or even worse, the word “picture” as the alt text.

So what to do?

In a conversational blog post like this one, it’d be perfectly fair to make the alt text descriptive (“A cat, chewing on a monitor”), and to use an amusing title/caption (“Delicious!”). But if you have a more serious picture, say a picture of some people, you’re actually allowed to explicitly set the alt text to empty, since the description now lives on as a caption. That way the screen reader knows to skip the alt text and just read the text  (caption) surrounding the picture. So if you have a picture of two people, Alice and Bob, you could make the alt text be “” (that’s literally what’s called an ’empty string’, meaning there’s nothing inside the quotes, but the quotes are present), and the title be “Pictured, left to right, Alice and Bob.”.

The second feature we’ve implemented is FAQ questions. If your department has, or would like a FAQ page, contact us for a quick crash course in how to use the FAQ module.

Draft Mode & More Forms

Over the last year, one feature we’ve heard requested over and over again is the ability to save a draft of your content and come back to it later. This last weekend we finally got it working, using a module called Workbench Moderation.

This module actually makes some pretty significant changes for everyone, even if you never use drafts, so let’s take a look.

In order, "View Published", "New Draft", "Moderate", "Webform", "Results"

The most easily noticed changes are the tabs along the top of pages you edit. The first one, “View Published”, is the same as the old “View” tab. You’d use this tab to see the content that the world currently sees. The second tab, “New Draft”, replaces the “Edit” tab. The last change is the new “Moderate” tab, which replaces the old “Revisions” tab.

For most people, your workflow shouldn’t really change. When you want to make an edit, click “New Draft”, make your changes, enter your revision message, and click save.

But if you’d like to save your work for later, click on the “Revision Information” horizontal tab at the bottom of the page. Below the log message you’ll find a dropdown showing three states: Draft, Needs Review, and Published.

Shows a Revision Log Message box, above a dropdown for moderation state.

If you set your Moderation State to “Draft”, and click Save, Drupal will make a draft for you. Alternatively, you could set your state to “Needs Review”. This is an intermediate state – you’re no longer making changes to it, but you need someone else to take a look at it before you publish it.

You can manage the states of your page using the Moderate tab:

Shows a list of revisions to a page. The top one includes the text "This is the current revision. The current state is draft". The second one has the text "This is the published version"

This is a bit confusing at first, but it makes sense after you’re used to it. The top entry is the current revision of this node – the one that’s been saved as a draft. If you’d like to change it to Needs Review or to publish it, you can use the dropdown on the right hand side. The second entry is the currently published version – the one everyone sees.

The second big change we made was to the forms module, where we upgraded four minor versions. On the webform tabs, you’ll see some extra options for your forms, including the ability to add a progress bar on multipage forms. You should also see improved handling of unicode characters (non-latin alphabet) and better Excel exports.

If you’re a content editor, expect an email with further details soon. And, as always, if you’d like more information about forms or draft, just email Lori.