venutip.com

The most common CSS hack to target Firefox is to put something like this in your stylesheet:

@-moz-document url-prefix() { h1 { color: red; } }

But if you’re using LESS.css, this is a problem, because LESS uses the ‘at’ symbol (@) for variables. When LESS parses the above declaration, since @-moz-document isn’t a variable, you get an error.

Thankfully there are other easy ways to target Firefox in CSS that allow us to continue using LESS. For instance:

body:not(:-moz-handler-blocked) #your-target-element { 
  color: red;
}

In D7, if you delete a field from a content type, the field data stays in the database. And yet if you later add that same field back to that same content type, the data does not reappear. Zuh?

It’s the new deleted field in each field_data_<field_name> table that governs this behavior. So if you accidentally delete a field and want that data back, just change the deleted field from 1 to 0.

Kinda cool I guess, though it sort of reminds me of the trash can in WordPress. As far as I can tell, though, there’s no UI for adding back deleted fields.

I work on a lot of legacy sites that were built without the Context module, and I would say that at least once on each of these legacy sites, I turn to Context when I have a very specific problem: the visibility settings for a particular block are so complex that (in Drupal 6 at least) they can only be expressed by writing code. For instance: suppose you’re using Organic Groups, and you want to show or hide a block based on whether the user is a member of that group.

I’m building some maps for a client using the GMap module and came across the following simple problem: using a GMap macro, how do you remove a default attribute?

The GMap module lets you set a number of default attributes for your maps: width, height, center position, initial zoom, and so on. If you want to change any of the default settings for a given map, you need to specify your overrides in a GMap macro, which looks something like this:

[gmap zoom=3| width=500px |height=350px]

Today I learned that if you have a Views-powered block that uses CCK fields; and the CCK fields are empty for all the returned rows; then Views doesn’t realize you’ve got an empty set and it still prints all the scaffolding for your block – the admin links, the container divs, and so on. The content of the block is empty, but the HTML still takes up space and throws off your layout.

About a month ago, I tweeted what I thought was some pithy advice on the use of .* in regular expressions:

#regex tip of the day: never, _ever_ use .* unless you are forced to do so in a #24-style 
kidnap situation. And even then, think twice.

Funny and topical! But as it turns out, I spoke too soon. Early in Chapter 5 of the superlative Mastering Regular Expressions, the author (Jeffrey Friedl) demonstrates how the judicious use of .* can actually help you to write some very efficient regular expressions.

I just started working on my first multi-lingual site in Drupal this week (woo-hoo!), and ran into a minor issue with one of my views: both the English and Spanish versions of translated nodes were appearing in the view. No good!

The first thing I noticed about running in the Vibrams (this is while I was still in the store) was that I seemed to be coming down more on the balls of my feet, instead of on my heels. I’d read that this was likely to happen, but was surprised to see the change take effect so quickly.

I started building my first WordPress site last week and almost immediately starting customizing the theme. Rather than editing the default theme directly, however, I created a child theme, basing it off one of the many theme frameworks available for WordPress. Creating the child theme was painless, and there is plenty of information on how to do so.

The latter may seem harder to understand at first, but in certain situations, the former is a nightmare, whereas the latter is a pleasant dream.