Red Hot Chilli Project

The inclusion of jQuery in a custom Drupal theme seems to cause a lot of confusion to people new to Drupal. There is, of course, a proper way of doing it and it's not that difficult once you know how.

Drupal 7 comes packaged with both jQuery and jQuery UI. It uses these two JavaScript libraries to drive parts of its own user interfaces like the admin overlay screens and improvements to content tables etc.. However, the way Drupal works requires it to know that the page being rendered contains JavaScript that will require one or both of these libraries in order for it to be included.

If you're using the Fivestar module for Drupal you'll probably at some point want to use your ratings within a View. Assuming you're enabling the Fivestar rating against the content type as opposed to via a CCK field then you'll need to include it in your View via a relationship in order to display it with the associated node. The following instructions are for achieving this in Drupal 6 (I expect the process is similar in Drupal 7, but I haven't yet tried this).

The Drupal 7 Media module seems like a step in a really good direction for handling media files and providing an improved user-interface. However, it feels unfinished to me. The format options provided by the module in a WYSIWYG editor like CKEditor don't appear to be very customisable.

In an attempt to try and get my head around how the Media module format options work I recently sat down and tried to work my way through the media setup from a minimal Drupal 7 install. I thought I'd post my notes here for future reference. Perhaps they'll help others understand things, or maybe someone out there can shed further light on things.

• Currently there doesn't appear to be a way of controlling the options in the format options list
• Link, preview and large are defined by the image file display options (File types > Manage file display); from a minimal Drupal install with the Media module enabled these are set as:
  • Link (no display)
  • Preview (image display using the square thumbnail image style)
  • Large (image display using the large image style)
  • Original (image display in the original format)
• Changes to the image file display options are reflected in the output of media from the Media module (although the format options list is fixed to link, preview, large and original); so to make the link format work, from the display options set link to output something, for example "URL to file"
• Changes to the file display types may need the cache to be cleared to be seen on the site
• The difference between file types display and image styles is that file types decide how to display a file whereas image styles manipulate an image for display based on the file types display

Hope this helps some of you and removes some of the mystery surrounding the Media module. Hopefully there will be some further development on the module and things will start to work better soon.

I've finally gotten round to releasing a couple of updates to the arc_youtube plugin for Textpattern.

arc_youtube v1.0 sees some relatively big changes to the way the plugin works; mainly due to the move from the old Youtube embed code to the new iFrame version. As a result a load of parameters for the plugin have been dropped and new ones added according to what is available. The new embed code no longer allows for the player's colours to be fully customisable so color1 and color2 parameters have been dropped and the new color and theme parameters have been added. Other new parameters include start that lets you specify the starting point of the video.

Anyone wishing for a simpler upgrade can install v0.4 which includes some bug fixes. The old parameters remain the same (see the plugin's help documentation).

Both versions now support Youtube's youtu.be short URLs as the video parameter and now will be auto-enabled on install.

You can get the latest releases from the plugin's page.

A quick Drupal 7 tip for anyone trying to use the Drupal teaser break (<!--break-->) with an input format other than full HTML: to ensure that the teaser break is observed HTML comments need to be included in the allowed HTML tags so that they are not filtered out of the content. You can do this by adding <!--> to the allowed tags of your input format (Configuration > Text formats).

Once this is in place whenever the "teaser" display is used only content upto the teaser break will be output and Drupal will include the standard "read more" link to the node.

TXP Tweet 3 is now available for Textpattern and includes arc_twitter v3 and a new extension plugin, arc_twitter_intents.

arc_twitter_intents adds four new tags that output Twitter web intents widgets integrated with arc_twitter. Using arc_twitter_intents you can let people favourite, retweet and reply to your articles' tweets. With search engines increasingly taking social sharing into account for rankings these should help a little towards sites' SEO. arc_twitter_intents also includes the follow web intent.

arc_twitter v3 now includes a tag for outputting a Twitter follow button, similar to the tweet button introduced in the version 2 release.

Other changes include support for multisite setups (so people having difficulties connecting the plugin to their Twitter account should now be fine), the "Update Twitter" radio state is remembered while on the "Write" tab, the tweet suffix is now included in the plugin options, and native URL shortening support.

Due to changes with the way Twitter handles URLs the URL shortening features of this plugin look to become redundant in the near future so this may be their last outing.

Upgrading from v2.x to v3

The <txp:arc_twitter_retweet /> tag is being deprecated and replaced by the <txp:arc_twitter_tweet_button /> tag. You can continue using the old tag, but it will be removed from version 4 of the plugin. The change is to help clarify any differences between this tag and the new <txp:arc_twitter_intent_retweet /> tag.

Documentation

You can now find extensive documentation for this plugin on the TXP Tweet wiki on GitHub. People are welcome to help improve the documenation by contributing to it.

There are lots of arguments over whether or not to create a mobile version of a website or to just make a responsive design that adapts to the device it's being viewed on. If you do go for the former option please make it responsive too!

When so many people share links on social networks there is no guarantee what device someone is going to follow the link on. It can be very frustrating when you're taken to a mobile version of a site when you're using a desktop computer. In my experience, the majority of mobile websites apply no restriction on the width of the page like we tend to do with desktop aimed sites. The result is a very readable page on the small screen of a mobile; and excessively long lines of text on a full screen desktop browser that are difficult to read.

There is a simple solution: use the responsive design technique ignored in favour of the mobile site to make it adapt to the large screen. It doesn't need to be anything fancy. Just applying a maximum width on the content when the screen size increases above a certain width will suffice.

Remember responsive design works both ways!

Early 2010 I was chatting with a colleague about how useful it would be to have variables in CSS. I was working with some stylesheets that I'd inherited that were being used to theme a number of microsites. It had occurred to me that if variables had been used throughout to define the various colours then it would have been a lot quicker to tweak and produce new versions of the CSS when preparing a new theme. This all basically led to me discovering Less CSS, a CSS extension that adds dynamic behaviour.

I've been asked over on the Textpattern forums whether arc_twitter supports Twitter Intents. At the moment no, but I began putting the code in place a couple of months ago. Obviously people want it, so I'm going to try and get things sorted for a new release sooner rather than later.

I spend much of my time at work designing user interfaces and developing forms for the web. As a result I've found myself becoming increasingly aware of other form implementations on websites and web apps. There are many things that equally surprise and irritate me about the way some people put there forms together, but one is particularly frustrating: not correctly labelling form elements.

It's really quite simple. Each form input—a text field, checkbox, radio button, etc.—should have a label to explain what it is. These labels should be linked to the relevant input. So each label's for attribute should match the input's id attribute. This is not difficult.

Yet I keep finding forms where label attributes haven't been used or have but linked to the wrong field (for example, clicking on a poll option only to find you've selected a different one because of poor markup).

There are many reasons for labelling forms correctly. It will make your forms more accessible and more user-friendly. It helps ensure people can identify what is being asked for and makes selecting inputs easier. Checkboxes and radio buttons particularly benefit from this as these elements tend to take up a small amount of space making them trickier to click (clickable labels increase this area); remember we're not necessarily clicking on elements with a cursor anymore, think fingers on small mobile phone screens!

Forms are very interactive components of sites, so usability is key! A well designed form is one that functions well.

So next time you place an input field in your markup, make sure there's a label (even if you do end up hiding it in the stylesheets, although this should be justified).