dirtystylus

Drupal’s Ctools Object Cache

Not sure why (there are so many things I don’t know about Drupal, frankly) but occasionally when creating/cloning a View, I’ll get the following error message when saving:

PDOException : SQLSTATE[23000]: Integrity constraint violation:

I’ve taken to using a workaround gleaned from this thread on drupal.org. I examine the database using Sequel Pro, find the ctools_object_cache table, and find the row entry for the View I’m trying to create. Deleting that row and attempting to save again usually does the trick. My guess is that the operation creates the temporary entry in the Ctools object cache, but when saving fails you still have the entry in that table. So attempting to re-save results in a collision with that cached object.

Adobe and Typekit

When the news first hit that Adobe was acquiring Typekit, I thought it was a joke. And there were plenty of jokes made on Twitter, mostly born of users’ fears that Adobe would ruin a good thing. To me it was akin to hearing that one of my favorite underground bands was suddenly scooped up by a major label: things could get bigger and better, but it could also mean a loss of vision and direction. The last thing I wanted was for one of my favorite services to turn into just another marketing bullet point for the latest Creative Suite release (Adobe CS Ocho: Now With More Typekit!).

Once I got over the initial shock, however, I wrote this on Twitter:

I think the @typekit acquisition says more about @adobe changing than the reverse.

I started to see this as a sign that Adobe had stopped living in the past and was starting to move to where its users were already headed. For the past several years it has seemed like Adobe had stopped innovating: content to make incremental changes (I was going to write “upgrades” but there’s folks who would disagree with that) to their core products, while seemingly blind to the rapid change that was taking place all around them. The explosion of mobile platforms was marked by a very public Apple/Adobe back-and-forth over why Flash wasn’t allowed on iOS. That war of words obscured the simple fact that Adobe plain missed the boat with mobile.

With this Typekit move, however, Adobe seems to have realized that they needed to start innovating again, or do the next best thing: find someone who will innovate and partner with them. I say “partner” because that’s what it sounds like. From the Typekit blog post on the acquisition (emphasis mine):

If you’re one of our customers, this announcement means things will only get better. Typekit will remain a standalone product, as well as become a vital part of Adobe’s Creative Cloud. Our team will stay together, and we’re excited to start working on even easier ways to integrate web fonts into your workflow.

Those two bits I highlighted are what give me hope that this thing could work. The Typekit team includes some very forward-thinking folks that I admire: Jeffrey Veen, Mandy Brown, Jason Santa Maria, among others. I heard Jeffrey Veen speak at An Event Apart this past year, and my overriding impression was this: the guy is extremely focused on his users. The Typekit team has their users’ trust, something they’ve built not just with the service itself but with years of giving to the web design community. I find it hard to believe that they would make a move that was either cynical or naive. I just think they’re smart people who care too much to let that happen.

This move alone doesn’t address the other nagging issues I have with Adobe, but it does show that someone over there understands where things are headed. As for the effect it might have on Typekit, I’m hoping that with Adobe’s clout we’ll see more and more type foundries add their fonts to Typekit, and also see Typekit integrated into more and more platforms.

Finally, there’s this: a lot of designers still don’t know about Typekit, but you’d be hard pressed to find a designer that doesn’t know Adobe. If this acquisition does nothing more than expose a whole slew of designers to the new opportunities afforded by web fonts, then that’s good enough for me.

Changing the Default Avatar in WordPress

This post by Nikhil Misai cleared up some confusion I had yesterday. I had added a filter to override the avatar default with a local file in my template’s images directory, but every how-to I read neglected to mention the final step of setting the default avatar in the the Settings > Discussion settings. I had (incorrectly) assumed that the filter would override any avatar setting when rendering the final output, but it appears that the filter merely makes a new default available in the settings.

Styling the WordPress 3 Comment Form

WordPress 3 brought a few changes to the comment form template. It appears that the fields and text can be modified by applying filters before the comment_form() method executes. For more details check out this link and this link.

One thing that wasn’t readily obvious from the examples was how to maintain the logic of the required fields. So make sure you have the following line in your code block where you override the html output for the name/email/url fields:

$req = get_option( 'require_name_email' );

Adaptive Web Design by Aaron Gustafson

For the tl;dr crowd: Just get the book. Short enough to finish in an afternoon, but packed to the gills with information you’ll use moving forward.

Until last fall, I spent most of the last ten years primarily building sites using Flash. Since moving to Philadelphia to join 160over90, I’ve spent most of my time building sites using HTML/CSS. It’s been a lot of fun, but one of the things I had to do was get up to speed with current standards-based web design. I picked up Aaron Gustafson’s Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement on a whim, largely because Veerle Pieters showed the cover design as part of her talk at An Event Apart Boston. However, it’s quickly become my essential grab-bag guide to the state of the art in web design. Its focus on progressive enhancement through HTML markup, CSS, and JavaScript was exactly what I needed: an overview of today’s best practices. Even if the detail in this book isn’t as comprehensive as its scope (intentionally so), it has enough detail and practical examples to point me in the right direction to dig deeper.

Progressive Enhancement vs Graceful Degradation

Chapter 1 defines progressive enhancement this way:

Progressive enhancement is a philosophy aimed at crafting experiences that serve your users by giving them access to content without technological restrictions.

It draws a contrast between that philosophy and the blind alley of “graceful degradation”. Here’s one of my absolute favorite lines from the book:

Graceful degradation was the philosophical equivalent of fault tolerance’s superficial, image-obsessed sister who is fixated on the latest fashions and only hangs out with the cool kids.

Ouch. So that hits a little close to home. But it’s a message that rings true, and thankfully there seems to be no shortage of enthusiasm these days for a content and user-centric approach to web design.

Stacking it Up

With the purpose clear, the rest of the book devotes one chapter apiece to HTML markup, CSS, JavaScript, and finally Accessibility. I’ll just list a few of the highlights for me:

• In the HTML chapter I came to a deeper understanding of semantic markup, learned about microformats, and the advancements introduced by HTML5.

• In the CSS chapter I finally learned about the rules governing selector specificity. I can’t tell you how many times I’ve wished for a concise explanation of how CSS determines which rule is given precedence.

• The JavaScript chapter introduced me to the concept of unobtrusive JavaScript, meaning that essential functionality on the page can be accomplished without JavaScript. In this situation JavaScript improves the experience, but its absence doesn’t cripple the page. I was also introduced to the novel (for me) concept of using JavaScript to generate any additional markup it might need to function correctly. I’ve already used that in some code I’m writing today.

• The Accessibility chapter taught me about ARIA roles, and it’s already changed the way I write my markup.

Check it Off

I love lists and checking things off, so I was delighted to find that the last chapter is a Progressive Enhancement Checklist broken down into the four major categories of the book. Right now there’s still quite a few unchecked boxes, but hopefully I’ll be checking off more items with each successive site that I build.

To sum up: I found Adaptive Web Design to be funny, informative, and—most importantly—useful. I was able to funnel what I learned directly into my current (and upcoming) projects. I can’t recommend it enough.