Controlling Comments on Image Pages in Twenty Eleven

I’ve been having problems with comment spam on the site. Strangely enough, they always seemed to come from one of the images on my very first gallery post, even though the post itself  doesn’t have a comment form (I have comments set to automatically close after three days).

Unwanted Comments on Image Attachment Pages

It turns out that image attachment pages don’t respect the site’s comment settings, at least not in the Twenty Eleven theme that I’m using as a parent. After another spam comment the other day, I found that Anthony Hortin, of Maddison Designs had solved the problem for the previous default WordPress theme, Twenty Ten. The solution involves adding a check to see if the attachment’s parent post still allows comments.

The Fix:

Change this:
<?php comments_template(); ?>
To this:
<?php if (comments_open($post->post_parent)) {
// Only show the Comments Form if the parent post has comments open
} ?>

The code is the same as Anthony’s; the only difference is that in Twenty Eleven, the file to modify is image.php, not attachment.php as it is in Twenty Ten. Since I’m already running a child theme, I made a copy of image.php and put it in my child theme folder, rather than modifying the parent theme file. This is the recommended way of making changes; but it does mean that if WordPress makes a change to the parent file, I won’t see the update. Hopefully, they’ll address the issue at some point.

Update, June 2012:

I’ve discovered there’s a significant drawback to this fix: Any comments posted during the open period are also hidden when comments closed. See this post for a further discussion and revised fix.

New Year, New Look

Just in time for the new year, I’ve revamped the appearance of the site. This is something I’ve been wanting to do since I first set up the site, but I had the notion that I needed to create a whole new theme, and was very slowly working my way through a WordPress book.

As it turns out, that wasn’t necessary. WordPress supports child themes–it isn’t necessary to create a whole new theme, you can simply override the parts of an existing theme that you want to. In this case, I’m basing my theme on the default TwentyEleven theme I was already using.

I’d fallen in love with the theme’s header image feature, and had already created some really nice banners from some of my pictures. But I wanted more color, I wanted to play with web fonts, and I wanted an appearance that was mine.


The fonts I’m now using are Museo Slab for the titles and Museo Sans for the main body text. Right now, I’m using TypeKit to provide them. One thing I’m less than crazy about is that you need to add a script to bring them in, and they’re hosted by TypeKit. I need to look into self-hosting them.


The main blue background is a PNG gradient applied to the HTML (root) element, with the “words” as a repeating PNG image applied to the BODY element. I’m of two minds about this background, from an accessibility standpoint. On the one hand, they’re meant to denote some of my interests, which would indicate that that some programmatically determinable method should be available. On the other hand, they’re meant to be decorative and kind of subliminal, and not to be really read. They’re not in a meaningful order, and in fact, you can’t see them all. They’re almost just texture. In the end, this is the line of thought I’ve followed.

The other gradients are created via CSS, using code based on ColorZilla’s Ultimate CSS Gradient Generator.

HTML Changes

Most of the generated HTML is still straight TwentyEleven. During development, I had to replace the stylesheet link with a hard coded link to my development site– WordPress is absolutely bloody-minded about using absolute links, which makes things needlessly complicated when you’re developing on a development domain. The one HTML change I’ve made so far is to add a little markup to facilitate the “posted on” calendar, which I implemented via a filter in my child theme.

One other change I want to implement in the future (hopefully, near future) is to provide alternative text for the header image. Surprisingly, the stock theme only provides an empty alt attribute with no easy way to add alternative text, and from what little I saw on the support forums last night, this was a design decision–I gather the feeling is that they regard the header image as being strictly decorative, and want to head off keyword stuffing. I can see that, but I can also see a site creating header images that include text, which would need alternative text. In my case, I’d like to add alternative text indicating what the header is a picture of, and it would even be nice to add a little visible caption with that information.

Browser Support

The site looks great in Safari, Opera, Chrome, and current Mozilla browsers like Firefox or Camino. I’ve looked at it in IE 7 and 8, and it looks good in those browsers too, though it’s missing some of the niceties like text embossing and rounded corners.  I haven’t seen it yet in IE 9. I am aware of an issue in older Mozilla browsers — the typography is missing, as is the gray background at the top, due to a bug in the way those browsers dealt with unknown elements. (The site uses some of the new HTML 5 features). The site is still readable, though, and the work-around– serving the site to Mozilla as text/xml– is risky, since one misplaced entity or malformed comment or post would blow the page out of the water. In the end, I’ve decided to accept that older Gecko based browsers won’t see as nice a presentation of the site. Fortunately, usage of these browsers is well under 1%.

Update 1/4/12:

I’ve now seen it in IE 9, and of course, IE Is Being IE. Earlier versions of Internet Explorer don’t support rounded corners, but IE 9 does. Unfortunately, since I was using an IE filter style to provide the top gray gradient, there were square corners poking out of the header. Apparently, it can’t clip the rounded corners when using older filter styles. I’ve replaced that gradient with an image; which took care of the problem.

Future Plans

As I stated above, I’d like to add alternative text/captioning to the header images, and I may add a little control to the home page enabling the user so rotate through the images without reloading the page. I also need to look into a widget to display tweets (I’m @ShutterAperture on Twitter). I will be adding an About page, and uploading and providing links to some of my older static pages that I was hosting either on Comcast when I was using them, or MobileMe. And in two weeks, I’ll be heading to Bonaire for a week of diving, and am looking forward to blogging about that.

Happy New Year, everyone.


CFQuery and Temporary Tables

I wrote a gateway function at work a couple of weeks ago that aggregates a bunch of data, then returns a paged query. The user interface for this functionality shows a set of contexts, each of which can have an indefinite number of sub-records. Each of the contexts that match the search criteria needs to be numbered, because if there are many of them, we need to paginate the results, and give back contexts 1 -25, then 26 – 50, and so on.

My first pass at a solution involved a CTE (Common Table Expression), where you define a subtable and query that, and this was a great improvement over the initial straight query. Unfortunately, it wasn’t enough of an improvement… the next day I noticed that the query was taking about 14 seconds to run.

I ended up using a temporary table for the method. This was only the second time I’d used a temporary table, and the first time I used one to return results; the first time was used simply to mass insert data.

In the method, I create a unique name for the temporary table, then in the SQL, define the table. It’s important to note that when defining a locally scoped table you need to prefix the name with a pound sign, and since this is ColdFusion, you need to double up the pound sign.

So I created the table, and inserted the data into it from my base query. One of the nice side benefits of using a temporary table was that I was able to simply create a primary key with identity for the context number, which simplified things a bit. I then selected from the temporary table, joining to one of our standing tables to fill out the rest of the data. After getting the data, the query drops the temporary table.

[Queryname] is undefined

This worked out great in SQL Studio; it was much faster than the CTE approach– 300ms as opposed to 14 seconds, so I got the go ahead to replace the existing query with the new version. I replaced the old SQL with the new, and — crash. I got that lovely grey and blue screen of death, stating that “GetData [the query name] was undefined. Whaaaat?!?!? It’s right there in front of me!


I did some Googling, and found the key. I added SET NOCOUNT ON before the rest of the SQL, and SET NOCOUNT OFF at the end, and ColdFusion was happy. In hindsight, it may be because either I was performing multiple operations in the one query, or possibly because the SELECT was not the last operation, because I had to drop the temporary table after I was finished with it.

On Being “Programmatically Determined”

I’ve been dealing a bit with the WCAG accessibility guidelines at work, and one of the concepts that keeps recurring is that various kinds of information about the page is supposed to “be programmatically determined”. But what does that mean, and why is it important?

The thing is, when you can look at at a web page, the human brain is very good at figuring out the relationships between the parts of the page based just on their visual presentation. See some bold faced type? Must be there for emphasis. Those bigger runs of text? Must be headings and subheadings. And tables make sense when you can run your eyes up and down the columns, and across the rows.

HTML was originally designed as a way to mark up text documents semantically for the scientific community. But as the web became more popular, more and more presentational elements were added, and the focus of of web development turned to how pages look. For example,  I distinctly remember my then-current copy of the The Non-Designer’s Web Book recommending that you create headings by using the <font> tag to bump up the font size, and using a <br> tag to separate it from the text body, because browsers made headings too big and put too much white space around headings, and it couldn’t be adjusted.

That’s all great if you can see the page, but pretty useless if you can’t. And many people can’t, so they have to rely on software to read the pages to them. Making sure that information about your page can be “programmatically determined” just means using the features of HTML to embed information about the page in the markup so software can figure it out.

Examples of making things able to be “programmatically determined”

Let’s start with headings and subheadings. If you just use font sizing and a break tag to denote a heading, like we used to, it looks like just a part of the paragraph to a screen reader. On the other hand, if you use one of the heading elements, like an <h3>, the screen reader can recognize it, and indicate it to the listener.

Form controls are another problem. Typically, the labels for the controls are recognizable because visually they’re right next to the control. Not so easy for the screen reader — it doesn’t know which words are tied to which control, and if a table is used to lay out the form, the label might not even be adjacent to the control in the HTML source. This is solved by wrapping the label text in the <label> element, and using its “for” attribute to indicate which control it’s associated with. The software can now determine the relationships programmatically.

Another problem with forms is organization. Forms can get pretty big, and hard to comprehend. You can indicate relationships between form fields by using the <fieldset> and <legend> elements to group sections of the form; this also has the benefit of grouping elements visually. Assistive technology can now recognize the organization, because it’s in the structure of the page.

Emphasis can also be indicated structurally. <em> tags indicate emphasis, and  are generally rendered in italic, while <strong> elements indicate strong emphasis and are generally rendered in bold. Screen readers can pick up on these cues, and add the proper inflection.

On the other hand, the <b> and <i> tags have no intrinsic meaning — they just indicate bold face and italic text. The recommendation is to use <em> and <strong> if you want to convey emphasis, and a span element with a style declaration for a presentational effect.

Here I differ a little from the recommendation; if my intent is strictly presentational, I’m willing to use <i> since my intent is just presentation. For example, <p>I <em>loved</em> visiting the USS <i>Constitution</i>.</p>, which would be rendered as:

I loved visiting the USS Constitution.

The difference is that “loved” is emphasized, whereas the italic on “Constitution” is just a typographic convention.

Finally, there are tables. Back in Ye Olde Netscape 4 days, we used to use make table headings by setting the color and background of the first row of cells, and maybe making the text bold. This is fine if you can scan up and down the rows, but sucks if the you’re listening to the table cell by cell. The right way is to use the <th> (table header) element to mark up headers. Even better is to use the scope attribute on the <th> element to indicate if it’s a header for a row or a column, and to use the <thead>, <tfoot> and <tbody> elements to indicate sections of the table. With this markup in place, software can then decipher the relationships between cells and communicate them to the user.

Don’t abuse semantic elements

A last part of making sure that information about your document can be “programmatically determined” is to recognize semantic elements for what they are, and to not pollute your document for their presentational side effects. The biggest offender here is the <blockquote> element, abused far and wide because it has indented sides. Well, dummy, it’s intended to convey the fact that the enclosed text is a quotation, and if it isn’t, you’re saying something about the text that isn’t correct, and can confuse software that’s trying to figure out your content programmatically. If all you want to do is indent text, use styles to do so. Other elements that tend to get misused for their presentational effects are the list elements <ul>, <ol>, <dl> <dd><dt>.

But Why Should I Care?

Making information about your content “programmatically available” benefits more than screen readers. It makes your content more accessible to software generally — and that includes search engines as well.


Puttering Around

I’m finally starting to get some ideas of how I want this thing to look. I started messing around some in Photoshop and BBEdit tonight to play with an idea I had for the look of the site, which is rather different from the way I normally put a site together at work.

At work, I’m almost always handed a finished Photoshop document, and asked to make the site look as close to the Photoshop document as I can. With a static site, I can generally come pretty close, and do my best to execute the design as closely as I can. With a dynamic site, I do what I can, but the software often places constraints on what you can do– if the HTML structure output by the software, which is pre-written– doesn’t match the design, there’s not much you can do. It’s also been my experience that some designers include features that the software doesn’t support.

For this site, I’m starting to get a sense of what I want to look like, and I’m mocking it up statically on my local machine. Instead of creating the whole design in Photoshop, I’m just creating bits and bobs, then trying out the CSS directly in BBEdit, locally. There’s nothing here on the site to see yet.

The other consideration is making the thing work with WordPress. I have a lot of experience at work, skinning dynamic systems, but that has been on systems that I did a lot of work on myself, and in ColdFusion. I’m going to have to learn how to do things The WordPress Way, and I’m going to have to pick up a little PHP too. And part of the process is going to be to find out what kinds of goodies I have to play around with in this environment. But that’s part of the attraction too.

Hidden fields don’t have a defaultValue property

I discovered the hard way that hidden HTML form fields don’t have a defaultValue property that you can read. I suppose the presumption is that since the user can’t get at them (without special tools) there was no need.

Here’s what was going on. I recently built an AJAX based admin interface at work. The interface consists of a form, a set of tab links , and a set of divs within the form that individual tab sections would be loaded into, and a hidden field to track what the default mode of the form would be — normally either “insert” or “update” to save the record, but some of the tabs have additional controls to do other things, which work by changing the mode field, and then submitting. Once the action completes, I needed to reset the mode field back to its default value so that a future action would do what it was supposed to.

Except that it wasn’t. The mode field was staying set to whatever state the script had set it to. I’d implemented it by reading the defaultValue of the mode field and setting its value back to that. It had worked great during the earlier part of development, when I had made the mode field a text type input so I could see what was going on. And it worked fine when I changed it back to a text type, but stubbornly refused when it was a hidden type. Even more maddening was that there were no errors… it just didn’t change.

I finally did some searching, and found that the property isn’t available to hidden fields. I ended up using a custom data attribute on the field to track the default value, and read that instead.