Life and Death questions: Where to write the copyright in an image tag? In the Alt or in the Title attribute?

One of the important questions in my life is where to write the copyright statement in an Image tag. It's sometimes keeps me awake at night. It is one of those daunting questions which are not answered by one google query. For lots of use cases adding the copyright statement as a caption under the image is not an option.

ALT
The alt attribute should contain a description, in 150 characters or fewer,  preferably a description in the context of the embedding page, of the visual content of the image. This is the part that mr. Google indexes. So it is the SEO part of the image as well as the visually impaired part, targeted at screenreaders and the like.

TITLE
The title contains the text that appears in the tooltip when you move your mouse over the image. It should contain additional info, like if the image is linked, where the link will lead you.


The Answer: The Title attribute
As the copyright is not a visual description of the image, you should therefore add it to the title attribute. This is also suggested by w3c.

But
But on the other hand, as you probably would like to buzz the photographers name around on the internet, and would like the search engines to find all the images belonging to a certain copyright holder, the alt attribute is also used for the copyright statement by lots of sites.  The alt text should never begin with the copyright statement, but it is used a lot.
I do not know if there are any accessibility rules targeting the credit statement specifically for this matter.
Reading all information I suppose that from the viewpoint of accessibility it is a bad solution, but from the viewpoint of the search engines, it is a good solution.

Drupal 7 - specifying different output per role type in a template

Lot's of time I want content or links hidden for unauthenticated users but shown to the site administrators or other user roles. As I always forget how I do it, and then search in old code or ask my old friend mister Google, here's a little blog about how to:

In the template, for instance a field template for a field in a view, add this code.

// load the global user object

global $user;

// Check if  user has (f.i.) the 'administrator' or 'contributor' role.
if (in_array('administrator', $user->roles)||in_array('contributor', $user->roles)) {   

    // do something
} else {

   // do something else

}

NB! I use this on small sites. It is fast and easy.

For larger sites solution you should define these things using permissions, otherwise the site will in time become unmaintainable.  Adding a permission to another role might then mean changing twenty template files or so.

  // user_access default takes the current logged in user as user object
  if (user_access('permission x')) { 

    // do something

  } else  {

   // do something else

  }




Because setting up the normal permissions may become very complex, you can also add custom permissions with this module https://drupal.org/project/config_perms and use them in your template file for this kind of functionality.

National Library of the Netherlands - Migrating multilingual xHTML from a shoe-box to Drupal 7

In fact I am a very lazy person. That's why I studied theoretical physics. In school I simply compared the number and thickness of the books for the different studies, and concluded that physics must be the one where this laziness would prosper most.

Feynman diagrams

The thing is, as soon as you understand a part of physics, you can stop reading. Not so with history, not so with all other subjects. They require hard mental labour.
(I have to find some apology for studying philosopy lateron, so any suggestions are welcome....)

Hail Laziness
Laziness is one of the least respected human inclinations.  If there where no lazy people, no one would have invented the car, the combine, the phone et cetera. We would all be working our asses off all day in the fields, pushing little grains out of their stalks one by one. Books would have no indexes. Skyscrapers no elevators. Chairs no legs.

Royal Library of the Netherlands
One fine day (early 2012) we got like the following request from the Royal Library.

On the left we've got twenty shoeboxes of HTML, and on the right we have a brand new core structure for the website in Drupal 7: Contenttypes, Display Suite, Views and all.
Could you please import the information from the shoeboxes into the Drupal 7 system. Thankyouverymuch and Yesterday would be fine.

Being Lazy we simply said: Yes, of course we can. There is nothing we can't do.
And then imagine the soundtrack of Jaws on the background........

Delusions of simplicity
We said so because the concept in itself is very simple.

      Here we have content A, B and C. In booklet X.
      There, on the other side, is a new booklet Y.
      Now copy A, B and C to booklet Y.

      X( A B C )         -->        Y( A B C )


What the hell were you thinking!
The source being ante-diluvian xHTML, more or less templated,  from which we had to sift images, downloads and all other digital objects, parse all content from all these different structured pages, and then load and upload everything in the totally different structured Drupal 7 system.

Book of Hours of Simon de Varie. Paris, 1455;  Tours, c. 1455.
Vellum, 99 leaves, 116 x 85 mm. - 74 G 37a, fol. 1v-2r

We're talking repeatable fieldcollections in repeatable fieldcollections,  migrating source images to different caching formats, programmatically generating en configuring viewmodes, and showing them via the Display Suite and the Media module, which at the time was still in the development phase. And apart from that, there was still development going on the the target Drupal site.
Oh Yeah, and did I mention the multilingual part? English and Dutch.

So it's a project with a big red rubber stamped warning on the cover:

      Send project manager to 
      high altitude trainingcamp 
      before start!

Or, stated differently, in common ICT jargon: Blood, Sweat and Tears ahead.

Analysis: Dance like a butterfly...
The approach we used was the equivalent of dance like a butterfly and sting like a bee in webdevelopment. There is no way to oversee all problems in this kind of large projects concerning conversions between two totally different systems. In the quotation we made, which needed to be fixed price, we tried to include some bleeding control, but we knew beforehand that we were entering the Swamp part of our Portfolio. 
It proved for instance especially difficult to emulate the maintenance features in the old system, which was an xml based editor. There was no way we could migrate these features to the new D7 setup.  We were down to analysing every feature and  approach it from a totally different angle in D7.
Another unexpected tricky part was recalculating all internal links in the site. We had to iterate all pages aproximately twenty times before we had all link types covered. Some linkit, some entityreferences, some link fields, et cetera.
Don't get me started...
For the sake of your mental health I will not elaborate on the technical details, anyone interested can contact me directly, but it's a lot like this
    $filename2=createfilenameforimage($filenamearr);
    $file2 = file_save_data($image2, 'public://'.$filename2,FILE_EXISTS_RENAME);
    $field_collection_item->field_afbeelding=array(LANGUAGE_NONE => array('1' => (array)$file2));
    $field_collection_item->field_alttekst[LANGUAGE_NONE][0]['value'] = $animageobject->alt;
    $field_collection_item->field_titletekst[LANGUAGE_NONE][0]['value'] = $animageobject->title;

and than for days on end....
(And as for the bleeding part: Whoever thought up the idea of littering PHP code with all these dollar signs?)

5% inspiration, 99% iteration
I think we did about ten migrations. And after every migration the Royal Library checked the new site and discovered some new features or parts that weren't specified but certainly needed to be migrated as well. The Math was never right!

Never again!
And when you are finaly finished, and the site is migrated and the Royal Library is happy, the first three days you say to yourself: Never again. Behind every mountain there was another mountain, behind every tree there was a madman with an axe, behind every solution there appeared a brand new grinning unexpected problem produced by the very same solution, with five other problems stacked up his sleeve.
But on the fourth day you realise how much fun we had, how much we learnt about the internal workings of Drupal.

Geek sucks
I sometimes mind the Geeky part of my work, days of trying to get a certain piece of code right, minimal pixel adjustment feuds with the designers, that stuff. But when the subject matter itself is something like the Royal Library content, or digital heritage projects in general, I might just possibly be able to live with that.


http://www.kb.nl/en

Drupal 7 - Moving the messages text from a zone to a region in an Omega subtheme

The messages always mess up my page layout, so I usually simply want them on the top of my page content.

1. remove message from its default postion
1.a  Copy  zone--content.tpl.php to your subtheme's template directory (if you have not done that already)
1.b Remove these lines
  <?php  if ($messages): ?>
      <div id="messages" class="grid-<?php print $columns; ?>"><?php print $messages; ?></div>
    <?php endif; ?>

2. transfer the messages variable to the region template
2.a Open template.php
2.b add a preprocess functio, or modify if you alreay have one

 function THEMENAME_preprocess_region(&$vars) {
      $theme = alpha_get_theme();
     if ($vars['elements']['#region'] == 'content') {
       $vars['messages'] = $theme->page['messages'];
    }
 }


3. add the messages to the region template
Just write anywhere you want in the template
    <?php if ($messages): ?>
      <div id="messages" class="grid-<?php print $columns; ?>"><?php print $messages; ?></div>
    <?php endif; ?>

Drupal 7 - Adding multiple javascript files to an Omega subtheme

Adding a javascript to an Omega subtheme is a bit complex.
I'd rather use  scripts[] = js/chr.js in the info file, which works by the way, but for some reason you first need to add the js file as a library, and then enable it in the settings.
(see https://drupal.org/node/1416128 and https://drupal.org/node/1205984)
I this example I add one library containing two javascript files.

0. Add your javascript files in the js folder of your theme
(in this example I use files chr.js and chr2.js)

1. Add some code like this to your theme's info file
libraries[chromega][name] = CHR KHR main javascript
libraries[chromega][description] = Quirqks and Jeeeequery fun for th CHR website
libraries[chromega][js][0][file] = chr.js
libraries[chromega][js][0][options][weight] = 1
libraries[chromega][js][1][file] = chr2.js
libraries[chromega][js][1][options][weight] = 2
(you can use any name where I use chromega)

2. Go to your theme's settings page

3. Select tab toggle libraries and add your custom library

4. Clear you cache  

5. and then GO javascripting (I always forget the structure for the D7 javascript files so thats why I add this wonderfull example)

// JavaScript Document
// http://drupal.org/node/756722
(function ($) {
 //////////////////////////////////////////////////////////////////////////////////////// All code here
   $(document).ready(function() {
     // maak op d ehomepage beide blokken even lang
     dotherightthing();   
  });
  function dotherightthing(){
      alert('Do the right thing!');
  }
 ////////////////////////////////////////////////////////////////////////////////////////  end of all code
}(jQuery));


        ---

Nota bene
For some reason this (lazy) way of adding the javascript in the template file does not work

function themename_preprocess_page(&$variables) {
  drupal_add_js(path_to_theme() . '/js/chr.js');
}

Drupal 7 - Adding captcha to a webform

Another thing I always have to lookup while it is so simple....
1. install the captcha and image captcha module
https://drupal.org/project/captcha

2. go to configuration > people > captcha

3. Add form id
Add the form id of the forms to which you want to add a captcha challenge on the bottom of this page and select the captcha type

You can find the id by opening the form an looking in the HTML. There you find an id like: webform-client-form-75

<form accept-charset="UTF-8" id="webform-client-form-75" method="post" action="/en/order" enctype="multipart/form-data" class="webform-client-form">

NB! Replace all hyphens by underscores!

webform-client-form-75    ->    webform_client_form_75

4. Translation
If you have a multilingual site and want to translate the description, you have to do this partly on the capcha configuration page, partly via the normal Drupa interface translation.
(which is rather stupid)

captcha config
For instance, as I am Dutch (although also half Frysian) I always translate
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
To a bit archaic
Deze vraag wordt gebruikt om te testen indien u een menselijke bezoeker bent teneinde spam-inzendingen te vermijden.

Interface translation
What code is in the image? *To
Welke code ziet u in de afbeelding?: *
Enter the characters shown in the image.
Which is more or less a useless repetition of the previous sentence I think, to
Vul bovenstaande code in.

5. State of Bliss
And then, your webform will contain a captcha. Rejoice!















For Drupal 8: see this post

Drupal 7 - Changing the default file type icons without hacking core

A lot of time the designers want the icons just a little bit different than they are in drupal core. So, being lazy, I always just replaced the icons in core with the designer icons ad made a remark in my upgrade doc for that particular site.

A better way to achieve this is to just change the file icon path in your theme and put the modified icons somewehere outside the drupal core, so as being ably to upgrade your site and modules without any extra configuration steps.

function THEMENAME_file_icon($vars) {
  $file = $vars['file'];
  $icon_directory = drupal_get_path('theme', 'THEMENAME') . '/images/file_icons';
  $mime = check_plain($file->filemime);
  $icon_url = file_icon_url($file, $icon_directory);
  return '<img alt="" class="file-icon" src="' . $icon_url . '" title="' . $mime . '" />';
}

Copy the map modules/file/icons to a the images directory in your theme.
Rename the map file_icons
Change any image in this map to your (or your beloved designers) liking and you're set.